This page is part of the BugReports series. Please go there to submit a new bug or to see the list of all existing reports.

Pages "Disappear" When Using Authentication

aanand: Since I installed a custom authentication plugin, newly edited pages disappear from all plugin pages (WikiNews, PageIndex, everything). They are still accessible normally, and viewing their histories also displays correctly (i.e. all the edits show up, in order).

I can assure you that my authentication plugin isn't messing with the database whatsoever - I'll post the source if it's helpful.

(My test Wiki's at http://extra-life.org.uk/ewiki.test/ - you can't edit, but if you click "Utilities" then "Page History" you can see the correct page history, and "Recent Updates" will take you to the incorrect list of recent updates)

UPDATE: I've noticed that the same disappearing pages also have "errFLAGS(notype)" next to their names in the "Remove Pages" admin tool's list. And that if I set the READONLY flag on a page it suffers the same fate.

UPDATE 2: Found the source. Pages are being written without the TEXT flag set, which is causing them to be treated as problem pages. This seems to happen MOST, but not ALL of the time. And I have no idea why.

milky: Sorry for responding late. All the plugins were changed to honor some of the page flags recently (for the ewiki_db::GETALL calls result object ->get() function). It's likely that it could screw things up in some circumstance - we had somewhen a feature _PROTECTED_MODE_HIDING that can prevent pages from being seen, if you need authentication to access them.

I however have no idea, how and why the _TEXT flag could get removed from pages. As a quick fix, I'd recommend you simply hack the ewiki_db::WRITE call and set it always then (as fallback):

  if (($hash["flags"] & EWIKI_DB_F_TYPE) == 0) {
     $hash["flags"] += EWIKI_DB_F_TEXT;
  }

We haven't worked on the auth system for a long time, but would you allow me a peek into your custom auth extension module?

aanand: Thanks for that, I'll give it a try. Other than that I'm highly impressed with eWiki - you seem to be the only people prepared to deal with the concept of people already having a user database and/or authentication system.

My authentication plugin is for integration with Beehive. I'll put the source here: auth_perm_beehive

milky: We're not exactly the only one trying to make it work that way, PhpWiki developers for example lately also started a real authentication framework - I haven't looked into it, but it should be possible to do something similar (they also introduced some PageFlags now, ... it's only senseful to have such). For us it always was a major goal to allow people to integrate ewiki with different other systems, we try hard, even it is not possible in every aspect.

I have to look a bit closer into it, your code looks nice (and other people here can benefit from it now). Since you have integrated the login procedure (a form) and user database with it (perfectly fine), I think one of our login plugins may have some undocumented code inside, which always made it work better with ewiki_auth() so the {flags} never got garbaged in our tests.

Could you please also post a list of the plugins you are using? If simply the {flags} got cleared, the error code also hide in one of our edit/-hooked plugins.

aanand: Sure, here's the list:

• email_protect
• spages
• mpi/mpi
• jump
• notify
• patchsaving
• feature/imgresize_gd2
• feature/imgfile_naming
• page/powersearch
• page/pageindex
• page/wordindex
• page/orphanedpages
• page/imagegallery
• page/interwikimap
• page/aboutplugins
• page/textupload
• page/wikidump
• page/wikinews
• page/randompage
• page/recentchanges
• action/like_pages
• action/diff
• action/info_qdiff
• action/translation
• lib/feed
• markup/css
• markup/rescuehtml
• markup/naturallists
• markup/abbr
• markup/braceabbr
• markup/timestamp
• markup/definitionlinks
• markup/htmltable
• markup/table_rowspan
• linking/linkdatabase
• linking/link_css
• linking/shortwiki
• linking/link_target_blank
• appearance/fancy_list_dict
• appearance/listpages_ul
• filter/search_highlight
• aview/backlinks
• lib/subpages
• edit/templates
• edit/spam_deface
• auth/auth_perm_beehive

milky: I found a possible error source in ewiki.php around line #1470. The $set_flags may be to greedy in flag removal, or the *EWIKI_DB_F_COPYMASK could be set incorrectly. However, this snippet would also explain, why the _TEXT flag seemed to got removed randomly only - the code snippet only activates if/or not auxilary flags were set before. I'm not sure, that this was really the problem, but I didn't found anything better right now ;)

Don't remember the exact fix, but you could simply inject

$set_flags=$data["flags"];

or get the latest version of the CoreScript from CVS.