Extension talk:PageAfterAndBefore

Any ideas on how to link to the previous or next page? When I surround a –  command in , it somehow displays as a heading:


 * you could try the latest version; get it here. Jean-Lou Dupont 23:59, 23 August 2007 (UTC)

Trouble with usage
Could you give an example of how to insert this into a wiki page? I don't understand the instructions. I've tried:

And all I get is the final page within that category. Help?
 * The brackets  mean optional parameters.
 * Some examples:
 * Jean-Lou Dupont 11:44, 15 November 2007 (UTC)
 * Jean-Lou Dupont 11:44, 15 November 2007 (UTC)
 * Jean-Lou Dupont 11:44, 15 November 2007 (UTC)

MySQL problem with apostrophes (RESOLVED)
Whenever I try to use this extension on an article that has an apostrophe in the title, the saved page displays the following error message:


 * A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:


 * (SQL query hidden)


 * from within function "". MySQL returned error "1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '[title of article after the apostrophe]')=-1 AND `wiki_categorylinks`.cl_to = 'Tran' at line 1 (mysql.[my database])".

Do you know how this can be fixed?

Thanks.
 * Many thanks to you! I had forgotten to 'escape' properly the parameters before passing them to the DB layer -> potential for SQL injection attacks. I have fixed the issue in v1.0.2. Just do pear upgrade mediawiki/pageafterandbefore (assuming you are using PEAR). Jean-Lou Dupont 16:36, 20 November 2007 (UTC)

filtercurrent?
After looking through the code (although I am not fluent in PHP) and what documentation there is, I am baffled as to the actual functionality of the filtercurrent parameter.

If I set filtercurrent=yes in a call to firstpage on the first page of the category, it has the same behavior as if filtercurrent is not set.

It appears that filtercurrent is supposed cause firstpage to do nothing if it is called on the first page of the set. Instead, it always returns the name of the first article in the set, no matter what.

What am I not understanding? —Twisted86 08:08, 21 December 2007 (UTC)
 * I have added some clarifications text on the main page. Hope this helps. Jean-Lou Dupont 14:03, 21 December 2007 (UTC)

Thanks for the clarification. So, filtercurrent is supposed to do what I thought it was supposed to. Unfortunately, if I call #firstpage on the first page of the set, it returns the name of the article regardless of what filtercurrent is set to be.

A bug perhaps? Thanks. —Twisted86 22:15, 21 December 2007 (UTC)
 * Somewhat ;-) The format of the article title was the database one (i.e. with the underscores instead of the spaces). I have changed this to the normal article title format. Please try it out in version 1.0.3. Jean-Lou Dupont 00:44, 22 December 2007 (UTC)
 * Oooppss... I think I broke something in the process... please wait for my signal before trying 1.0.3. Sorry! Jean-Lou Dupont 01:19, 22 December 2007 (UTC)

DEFAULTSORT
The extension gets confused when there is a page with a magic word in use. The page in question behaves just fine, but the next page after it does not link properly. —Twisted86 09:54, 21 December 2007 (UTC)


 * I've looked succinctly at the MediaWiki parser code but I can't really figure out (in two minutes) what would be the expected behavior if I were to add support for DEFAULTSORT; what would be yours? Jean-Lou Dupont 14:08, 21 December 2007 (UTC)

Fair enough. I would expect PAAB to respect DEFAULTSORT, so that articles in a given category would be ordered by PAAB as follows:

What presently happens is that Bar nexts to Fubar and Foobar prevs to Fubar, but calling #pagebefore or #pagenext in Fubar returns immediately with no article name (#firstpage and #lastpage work just fine).

Thanks for the speedy reply. —Twisted86 22:01, 21 December 2007 (UTC)
 * I am still unclear on how I am going to address this limitation (if at all). It seems to me I would need to perform more processing on the database on each call to the parser function. If I get sufficient demand for this feature, I'll consider implementing it. Jean-Lou Dupont 00:47, 22 December 2007 (UTC)

If I knew more about PHP programming and MySQL, I'd make an intelligent suggestion. I think I can come up with a wiki-kluge in the meanwhile. Thanks. —Twisted86 01:52, 22 December 2007 (UTC)

apostrophes and parentheses
I hate to be the squeaky wheel, but calls to #pageafter and #pagebefore where the article has an apostrophe ( ' ) in the title or where the article has parentheses in the title return empty.

The calls are in a template that is transcluded into the page in question. The page name is being passed to #pagebefore/after using. —Twisted86 22:42, 21 December 2007 (UTC)
 * I believe I have addressed this bug in version 1.0.3 available right now in SVN/PEAR. Please try it out and let me know. Jean-Lou Dupont 00:45, 22 December 2007 (UTC)
 * Oooppss... I think I broke something in the process... please wait for my signal before trying 1.0.3. Sorry! Jean-Lou Dupont 01:20, 22 December 2007 (UTC)

Okay. Just post here when you're ready. Thanks! —Twisted86 05:58, 23 December 2007 (UTC)
 * Could you try upgrading to the latest v1.0.7 and let me know. Jean-Lou Dupont 01:48, 3 January 2008 (UTC)

not getting expected output
i created three pages and put them all in a category 'download instructions' on each page, i put the following: the firstpage and lastpage do not work at all. they seem to be pulling the first and last page of all the pages in the wiki. the pagebefore works as expected, but the pageafter works only until i get to the last page in the series, and then as far as i can tell, it is a random page.

i am not certain what i am doing wrong. ..
 * have you tried with underscores replacing the spaces e.g. download_instructions ? Jean-Lou Dupont 22:42, 28 January 2008 (UTC)

i thought that might have been the problem so i tested it with another group 'downloadinstructions'. i have also tried it with 'download_instructions' but the behaviour is still incorrect.
 * How silly of me! I forgot to mention that you need to specify category=download_instructions ! Jean-Lou Dupont 01:27, 29 January 2008 (UTC)

okay, now i have the following: unfortunately this totally kills it, and the links appear on the page like so: the bottom of each of the pages has the following [that has been the case all along]:

Error whilst upgrading Semantic Mediawiki store
Hi Jean-Lou. I've just upgraded my SMW to version 1.2.1. When I run the database refresh scripts I get the following errors:

PHP Fatal error: Call to a member function getNamespace on a non-object in C: \www\webapps\mediawiki\extensions\PageAfterAndBefore\PageAfterAndBefore.body.php on line 101 Fatal error: Call to a member function getNamespace on a non-object in C:\www\ webapps\mediawiki\extensions\PageAfterAndBefore\PageAfterAndBefore.body.php on l ine 101

Any idea what this might be? Thanks. User:Mitchelln 12:27, 13 August 2008 (UTC)
 * Hi - I am unfortunately not knowledgeable on SMW. Sorry. Jean-Lou Dupont 12:49, 13 August 2008 (UTC)
 * No problem. Do you know happen to know if getNamespace is a php library function or a mediwiki function? Thanks. User:Mitchelln 09:13, 14 August 2008 (UTC)
 * It is a method from the Mediawiki class title. Jean-Lou Dupont 10:21, 14 August 2008 (UTC)
 * Thanks Jean-Lou. I'll see if I can work out why it's failing. User:Mitchelln 15:01, 14 August 2008 (UTC)

error: "unexpected T_PAAMAYIM_NEKUDOTAYIM" (PHP 5.3 Namespace issue)
I don't know if anyone aside from me still uses this extension, but just in case:

After upgrading to PHP 5.3, pages using the PageAfterAndBefore extension would not load, and I got this error in /var/log/httpd/error_log:


 * PHP Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM, expecting T_NS_SEPARATOR in $PATHTOWIKI/extensions/PageAfterAndBefore/PageAfterAndBefore.body.php on line 103, referer: $MYWIKIURL

After some googling, I learned that PHP 5.3 added support for namespaces, and so reserved the keyword "Namespace". This is a problem because older versions of MediaWiki had a class named Namespace, and this extension uses it. I was able to resolve the issue pretty simply by doing the following (though I barely know any PHP, so caveat emptor):


 * 1) Install the latest MediaWiki (the crucial change is listed in the changelog for 1.13)
 * 2) Change every reference in   to the   class (though not every use of the string "Namespace") to   (there should be 4: on lines 103, 136, 145, and 164&mdash;I've put up the modified code here for reference)

After that everything worked again.