Hi,
I have been trying to create a maintainable way of grouping pages together and allowing readers to page through them in sequence. Most samples I've seen use templates that require you to supply the 'previous' and 'next' page. This however results in three page edits to insert a new page between two existing pages and does not guarantee that your prev-sequence is identical to the next-sequence...
Being a programmer, that is way too much duplicate and error-prone work for me ;-) There must be a better way to do this and I was hoping to solve it with a plain MW installation (with ParserFunctions and DynamicPageList at the moment).
Given an 'index' page that holds a list of all page titles in the preferred order, isn't it possible to create a template that selects the correct previous and next page title given the current page title?
I get stuck in getting the correct lines from the index page. DPL can select based on section name (= page title), but then the contents of that index section must be the prev/next links themselves:
=First Page= Prev [[Second Page|Next]] =Second Page= [[First Page|Prev]] [[Third Page|Next]] =Third Page= .. etc.
This works, except that it is still a lot of duplication of page names (but the edits are contained in a single page, big plus).
I hoped to simplify the index page by creating a template that writes the section header and prev/next links, but then DPL no longer recognizes the sections :-( Apparently DPL 'sees' the page text before the templates are called ({{Page|Prev page|Page title|Next page}}:
{{Page||First Page|Second Page}} {{Page|First Page|Second Page|Third Page}} {{Page|Second Page|Third Page|Fourth Page}}
Basically my questions are: 1. Am I completely off track here? 2. Can DPL be coerced to evaluate templates before looking at the page 3. Can DPL (or another extension) select the text from a section before/after a matched section? 4. Is it possible to determine the section sequence number given the section name (so 'Second Page' results in 2, allowing me to use DPL to retrieve the name of section 2 -/- 1 and 2 + 1 to create the prev/next links?
Apologies for the long post, hopefully someone can point me to some good resources (I've been to Meta, Wikibooks, Medawiki.org but could very well have overlooked something there as the amount of info is a bit overwhelming and it is difficult to judge how up to date it is).
You could probably make a template like
[[{{#include:index|prev-{{{PAGENAME}}}}}|Prev]] [[{{#include:index|next-{{{PAGENAME}}}}}|Next]]
Then supress the links at the end by making the first & last pages link back to themselves, and avoid duplicate names by indexing the name in multiple sections, i.e.
<section begin="next-First Page"/><section begin="prev-Third Page"/>Second Page....
http://www.mediawiki.org/wiki/Extension:Labeled_Section_Transclusion
On Mon, 14 Sep 2009 23:10:55 +0200, Jean-Marc van Leerdam wrote:
Hi,
I have been trying to create a maintainable way of grouping pages together and allowing readers to page through them in sequence. Most samples I've seen use templates that require you to supply the 'previous' and 'next' page. This however results in three page edits to insert a new page between two existing pages and does not guarantee that your prev-sequence is identical to the next-sequence...
Being a programmer, that is way too much duplicate and error-prone work for me ;-) There must be a better way to do this and I was hoping to solve it with a plain MW installation (with ParserFunctions and DynamicPageList at the moment).
Given an 'index' page that holds a list of all page titles in the preferred order, isn't it possible to create a template that selects the correct previous and next page title given the current page title?
I get stuck in getting the correct lines from the index page. DPL can select based on section name (= page title), but then the contents of that index section must be the prev/next links themselves:
=First Page= Prev [[Second Page|Next]] =Second Page= [[First Page|Prev]] [[Third Page|Next]] =Third Page= .. etc.
This works, except that it is still a lot of duplication of page names (but the edits are contained in a single page, big plus).
I hoped to simplify the index page by creating a template that writes the section header and prev/next links, but then DPL no longer recognizes the sections :-( Apparently DPL 'sees' the page text before the templates are called ({{Page|Prev page|Page title|Next page}}:
{{Page||First Page|Second Page}} {{Page|First Page|Second Page|Third Page}} {{Page|Second Page|Third Page|Fourth Page}}
Basically my questions are:
- Am I completely off track here?
- Can DPL be coerced to evaluate templates before looking at the page 3.
Can DPL (or another extension) select the text from a section before/after a matched section? 4. Is it possible to determine the section sequence number given the section name (so 'Second Page' results in 2, allowing me to use DPL to retrieve the name of section 2 -/- 1 and 2 + 1 to create the prev/next links?
Apologies for the long post, hopefully someone can point me to some good resources (I've been to Meta, Wikibooks, Medawiki.org but could very well have overlooked something there as the amount of info is a bit overwhelming and it is difficult to judge how up to date it is).
Hi Steve,
2009/9/14 Steve Sanbeg ssanbeg@ask.com:
You could probably make a template like
[[{{#include:index|prev-{{{PAGENAME}}}}}|Prev]] [[{{#include:index|next-{{{PAGENAME}}}}}|Next]]
Then supress the links at the end by making the first & last pages link back to themselves, and avoid duplicate names by indexing the name in multiple sections, i.e.
<section begin="next-First Page"/><section begin="prev-Third Page"/>Second Page....
Good suggestion, will try that!
Have you considered organizing pages by Category, and using the Category Tree extension? The Category Tree can be loaded to the sidebar, as a table of contents.
Evelyn http://AppsWhisperer.com
-----Original Message----- From: mediawiki-l-bounces@lists.wikimedia.org [mailto:mediawiki-l-bounces@lists.wikimedia.org] On Behalf Of Jean-Marc van Leerdam Sent: Monday, September 14, 2009 2:11 PM To: MediaWiki announcements and site admin list Subject: [Mediawiki-l] Easy creation of page sequences
Hi,
I have been trying to create a maintainable way of grouping pages together and allowing readers to page through them in sequence. Most samples I've seen use templates that require you to supply the 'previous' and 'next' page. This however results in three page edits to insert a new page between two existing pages and does not guarantee that your prev-sequence is identical to the next-sequence...
Being a programmer, that is way too much duplicate and error-prone work for me ;-) There must be a better way to do this and I was hoping to solve it with a plain MW installation (with ParserFunctions and DynamicPageList at the moment).
Given an 'index' page that holds a list of all page titles in the preferred order, isn't it possible to create a template that selects the correct previous and next page title given the current page title?
I get stuck in getting the correct lines from the index page. DPL can select based on section name (= page title), but then the contents of that index section must be the prev/next links themselves:
=First Page= Prev [[Second Page|Next]] =Second Page= [[First Page|Prev]] [[Third Page|Next]] =Third Page= .. etc.
This works, except that it is still a lot of duplication of page names (but the edits are contained in a single page, big plus).
I hoped to simplify the index page by creating a template that writes the section header and prev/next links, but then DPL no longer recognizes the sections :-( Apparently DPL 'sees' the page text before the templates are called ({{Page|Prev page|Page title|Next page}}:
{{Page||First Page|Second Page}} {{Page|First Page|Second Page|Third Page}} {{Page|Second Page|Third Page|Fourth Page}}
Basically my questions are: 1. Am I completely off track here? 2. Can DPL be coerced to evaluate templates before looking at the page 3. Can DPL (or another extension) select the text from a section before/after a matched section? 4. Is it possible to determine the section sequence number given the section name (so 'Second Page' results in 2, allowing me to use DPL to retrieve the name of section 2 -/- 1 and 2 + 1 to create the prev/next links?
Apologies for the long post, hopefully someone can point me to some good resources (I've been to Meta, Wikibooks, Medawiki.org but could very well have overlooked something there as the amount of info is a bit overwhelming and it is difficult to judge how up to date it is).
-- Regards,
Jean-Marc
_______________________________________________ MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Hi Evelyn,
2009/9/15 Evelyn Yoder eyoder@gmail.com:
Have you considered organizing pages by Category, and using the Category Tree extension? The Category Tree can be loaded to the sidebar, as a table of contents.
Yes, I considered that, but then the order of the pages still depends on the page title doesn't it?
I am looking for a means to make multiple cross-sections of a collection of pages.
Jean-Marc -
Yes, that's true, unless you take advantage of the "pipe" trick, which allows me to define the index order for pages in categories.
Reference: http://en.wikipedia.org/wiki/Help:Pipe_trick
http://en.wikipedia.org/wiki/Wikipedia:Categorization#Sort_order
I'm a big fan of using Categories to organize MW, because it "wants" every page to be part of some category.
For more than you ever wanted to know about my experience, find secnarios and additional examples here:
The typical action is to add a category to each page. For example, to create a category called "myIndex", use: [[Category:myIndex]]
i.e, add [[Category:myIndex]] to the bottom of each page: First Page, Second Page, etc.
In the resulting ".../wiki/Category:myIndex" page, the categories would be listed alphabetically, and each section would have the Alpha heading:
"F" "S" "T" - Fifth Page - Second Page - Third Page - First Page - Fourth Page
Instead, try adding categories with the pipe and index number like this: (the SPACE after the pipe is important):
- First Page [[Category:myIndex| 1]] - Second Page [[Category:myIndex| 2]] - Third Page [[Category:myIndex| 3]] - Fourth Page [[Category:myIndex| 4]] - Fifth Page [[Category:myIndex| 5]]
The only downside to the pipe trick is that numbering is 0-9, however, decimals can be applied, so with a little planning, it works.
A more complex example...
- First Page [[Category:myIndex| 1.0]] // Each of the added pages are - another page-z [[Category:myIndex| 1.1]] // sorted by number in the Category - another Page-b [[Category:myIndex| 1.3]] - another Page-c [[Category:myIndex| 1.7]] - Second Page-g [[Category:myIndex| 2]] // When the same index number is added to - Second Page-r [[Category:myIndex| 2]] // several categories, they are sorted - Second Page-a [[Category:myIndex| 2]] // alphabetically by page name - Second Page-c [[Category:myIndex| 2]] - Third Page [[Category:myIndex| 2.2]]
...Results in this category page:
- First Page - Second Page-a - Third Page - another page-z - Second Page-c - another Page-b - Second Page-g - another Page-c - Second Page-r
This is a real-life example of the category tree, in our online help site: http://platformatyourservice.com
This online help site is built on MW, and supports www.longjump.com, where I am tech writer. The "Setup" link is a good example of how we forced the index in the page http://lj.platformatyourservice.com/~platfor1/wiki/index.php?title=Category: Setup
Best of luck, Evelyn
-----Original Message----- From: mediawiki-l-bounces@lists.wikimedia.org [mailto:mediawiki-l-bounces@lists.wikimedia.org] On Behalf Of Jean-Marc van Leerdam Sent: Monday, September 14, 2009 10:34 PM To: MediaWiki announcements and site admin list Subject: Re: [Mediawiki-l] Easy creation of page sequences
Hi Evelyn,
2009/9/15 Evelyn Yoder eyoder@gmail.com:
Have you considered organizing pages by Category, and using the Category Tree extension? The Category Tree can be loaded to the sidebar, as a table of contents.
Yes, I considered that, but then the order of the pages still depends on the page title doesn't it?
I am looking for a means to make multiple cross-sections of a collection of pages.
-- Regards,
Jean-Marc -- . ___ . @@ // \ "De Chelonian Mobile" . (_,/ _/ \ TortoiseSVN . \ _/__/> The coolest Interface to (Sub)Version Control . /_/ _\ http://tortoisesvn.net
_______________________________________________ MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Hi,
I have a wiki where the users have to login to be able to access it. In the wiki, I upload files (like PDF file) and users click on a link to open the files...
When they click on a link to a file (PDF, DOC... etc...), the address in the address bar looks like: http://wikiname/.....some_stuff/images/a/7/file.pdf
All is normal... (as for I'm concern...)
Now : if I copy this address and send it to a user that IS NOT loggued on the wiki, he's able to open the file. He have direct access to the file, without login to the wiki.
!!!!! I'm surprise of this behavior, as it skips all the security I have put in the LocalSettings.php... I missed something ??? It's related to some rights on the IMAGES directory ?
(PS sorry for my English, I speak french)
Thanks in advance !
Pierre
On Wed, Sep 16, 2009 at 3:53 PM, Pierre Labrecque pierre.labrecque@live.cawrote:
Now : if I copy this address and send it to a user that IS NOT loggued on the wiki, he's able to open the file. He have direct access to the file, without login to the wiki.
This is MediaWiki's standard behavior. If you want to restrict access to files, you will need to use img_auth.php < http://www.mediawiki.org/wiki/Manual:Image_Authorization%3E.
Great! Thanks you for the information. I appreciate! Bye !
-----Original Message----- From: mediawiki-l-bounces@lists.wikimedia.org [mailto:mediawiki-l-bounces@lists.wikimedia.org] On Behalf Of Benjamin Lees Sent: Wednesday, September 16, 2009 4:57 PM To: MediaWiki announcements and site admin list Subject: Re: [Mediawiki-l] : Security, Login and Files in Images directory
On Wed, Sep 16, 2009 at 3:53 PM, Pierre Labrecque pierre.labrecque@live.cawrote:
Now : if I copy this address and send it to a user that IS NOT loggued on the wiki, he's able to open the file. He have direct access to the file, without login to the wiki.
This is MediaWiki's standard behavior. If you want to restrict access to files, you will need to use img_auth.php < http://www.mediawiki.org/wiki/Manual:Image_Authorization%3E. _______________________________________________ MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Pierre,
If you need restrictions, you may want to look at:
http://www.mediawiki.org/wiki/Extension:Lockdown (name space based protection) http://www.mediawiki.org/wiki/Extension:NSFileRepo (protection for files, based on namespace)
Also, please note the disclaimers at the top of each.
Jack
-----Original Message----- From: mediawiki-l-bounces@lists.wikimedia.org [mailto:mediawiki-l-bounces@lists.wikimedia.org] On Behalf Of Pierre Labrecque Sent: Wednesday, September 16, 2009 7:55 PM To: 'MediaWiki announcements and site admin list' Subject: Re: [Mediawiki-l] : Security, Login and Files in Images directory
Great! Thanks you for the information. I appreciate! Bye !
-----Original Message----- From: mediawiki-l-bounces@lists.wikimedia.org [mailto:mediawiki-l-bounces@lists.wikimedia.org] On Behalf Of Benjamin Lees Sent: Wednesday, September 16, 2009 4:57 PM To: MediaWiki announcements and site admin list Subject: Re: [Mediawiki-l] : Security, Login and Files in Images directory
On Wed, Sep 16, 2009 at 3:53 PM, Pierre Labrecque pierre.labrecque@live.cawrote:
Now : if I copy this address and send it to a user that IS
NOT loggued
on the wiki, he's able to open the file. He have direct
access to the
file, without login to the wiki.
This is MediaWiki's standard behavior. If you want to restrict access to files, you will need to use img_auth.php < http://www.mediawiki.org/wiki/Manual:Image_Authorization%3E. _______________________________________________ MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Good Morning MediaWiki Fans:
Our wiki site suffered a spam attack this weekend. (version 1.13.0) The attack evidently had some method to work-around the new account Captcha barrier, and the authorized user email allowed to edit setting. I'm curious if anyone else has encountered such attacks and if there are new ways to block bogus account creation.
--Hiram
On Wed, Jul 28, 2010 at 12:11 PM, Hiram Clawson hiram@soe.ucsc.edu wrote:
Good Morning MediaWiki Fans:
Our wiki site suffered a spam attack this weekend. (version 1.13.0) The attack evidently
had some method to work-around the new account Captcha barrier, and the
authorized user email allowed to edit setting. I'm curious if anyone
else has encountered such attacks and if there are new ways to block
bogus account creation.
--Hiram
We suffered such an attack and fortunately had OpenID login installed and so decided to disable native wiki account creation with this in LocalSettings.php
# Prevent new user registrations except by sysops $wgGroupPermissions['*']['createaccount'] = false;
Then updated http://wiki.sugarlabs.org/go/MediaWiki:Loginprompt to suggest that new users create accounts with an OpenID.
This has prevented the spam, but the server and database may still be under attack.
--Fred
On Wed, Jul 28, 2010 at 12:11 PM, Hiram Clawson hiram@soe.ucsc.edu wrote:
Our wiki site suffered a spam attack this weekend. (version 1.13.0) The attack evidently had some method to work-around the new account Captcha barrier, and the authorized user email allowed to edit setting.
Which CAPTCHA plugin are you using? What do you mean by "the authorized user email allowed to edit setting"? $wgEmailConfirmToEdit?
On Wed, Jul 28, 2010 at 9:11 AM, Hiram Clawson hiram@soe.ucsc.edu wrote:
Good Morning MediaWiki Fans:
Our wiki site suffered a spam attack this weekend. (version 1.13.0) The attack evidently had some method to work-around the new account Captcha barrier, and the authorized user email allowed to edit setting. I'm curious if anyone else has encountered such attacks and if there are new ways to block bogus account creation.
It's probably a good idea to get some log details on those submissions to make sure there's not a bypass (at least double-check the MediaWiki debug logs to make sure it's listing captcha details?), but keep in mind that captchas are not an absolute preventer of spam... There are service firms that simply employ lots of people to type in captchas on your spambot's behalf.
-- brion
On Wed, Jul 28, 2010 at 14:15, Brion Vibber brion@pobox.com wrote:
There are service firms that simply employ lots of people to type in captchas on your spambot's behalf.
A number of porn sites work this way. When someone tries to access the freebie section of a porn site, they see a captcha. It's copied from the site they are trying to attack. The attack is conducted live as the porn site user tries to get in. That user types the captcha content which is passed along to the attacked site. The attack is successful and the porn viewer gets a little reward. It works because the attack is made when a user is available, so the captcha usually will not expire in that short time frame. As long as the people doing the attack understand the security mechanism of the target site, they can replicate it on their porn site and get other humans to do it for them, for a little reward.
Defeating this can be hard to do. The attacks are usually relayed through botnets. So all the accesses look like they are just coming from random home users (and not a bunch from one common IP address). There is relatively little lag between display of the captcha or whatever other mechanism is used, and the response of that user, so it looks like normal timing from a human (because it really is).
Anyway, people don't need to be employed to do this. There are lots of hormone starved teenagers willing, for a little reward.
Perhaps this is too simplistic, but I create a template for grouped pages and include it in all the pages (often at top and bottom for easy navigation). Then when you need to add a page, you just have the one template file to update. The current page is shown as bold, so it's easy to go through the pages in order if that's what you want - I just wanted an easy index.
<div style="font-size:0.9em"> [[IG:TGSTWiki 1.13.0|Home ]] • [[IG:TGSTWiki 1.13.0/Administration|Administration]] • [[IG:TGSTWiki 1.13.0/Maintenance Procedures|Maintenance Procedures]] • [[IG:TGSTWiki 1.13.0/Error reporting|Error Reporting]] • [[IG:TGSTWiki 1.13.0/Backup and restore procedures|Backup and restore procedures]]
[[IG:TGSTWiki 1.13.0/Customisation|Customisation]] • [[IG:TGSTWiki 1.13.0/MediaWiki installation page|MediaWiki Installation ]] • [[IG:TGSTWiki 1.13.0/MySQL install log|MySQL install log]] • [[IG:TGSTWiki 1.13.0/PHP logs|PHP logs]] • [[IG:TGSTWiki 1.13.0/SAFE integration|SAFE integration]] • [[IG:TGSTWiki 1.13.0/SMW|Semantic MediaWiki]] • [[IG:TGSTWiki 1.13.0/Migration|Migration]] • [[IG:TGSTWiki 1.13.0/Migration/MediaWiki setup log|MediaWiki setup log ]]
[[IG:TGSTWiki 1.13.0/D3000|D3000 ]] • [[IG:TGSTWiki 1.13.0/D3Wiki|D3Wiki ]] • [[IG:TGSTWiki 1.13.0/Migration/d3wiki setup|D3Wiki setup]] </div>
/Sam
-----Original Message----- From: mediawiki-l-bounces@lists.wikimedia.org [mailto:mediawiki-l-bounces@lists.wikimedia.org] On Behalf Of Jean-Marc van Leerdam Sent: 14 September 2009 22:11 To: MediaWiki announcements and site admin list Subject: [Mediawiki-l] Easy creation of page sequences
Hi,
I have been trying to create a maintainable way of grouping pages together and allowing readers to page through them in sequence. Most samples I've seen use templates that require you to supply the 'previous' and 'next' page. This however results in three page edits to insert a new page between two existing pages and does not guarantee that your prev-sequence is identical to the next-sequence...
Being a programmer, that is way too much duplicate and error-prone work for me ;-) There must be a better way to do this and I was hoping to solve it with a plain MW installation (with ParserFunctions and DynamicPageList at the moment).
Given an 'index' page that holds a list of all page titles in the preferred order, isn't it possible to create a template that selects the correct previous and next page title given the current page title?
I get stuck in getting the correct lines from the index page. DPL can select based on section name (= page title), but then the contents of that index section must be the prev/next links themselves:
=First Page= Prev [[Second Page|Next]] =Second Page= [[First Page|Prev]] [[Third Page|Next]] =Third Page= .. etc.
This works, except that it is still a lot of duplication of page names (but the edits are contained in a single page, big plus).
I hoped to simplify the index page by creating a template that writes the section header and prev/next links, but then DPL no longer recognizes the sections :-( Apparently DPL 'sees' the page text before the templates are called ({{Page|Prev page|Page title|Next page}}:
{{Page||First Page|Second Page}} {{Page|First Page|Second Page|Third Page}} {{Page|Second Page|Third Page|Fourth Page}}
Basically my questions are: 1. Am I completely off track here? 2. Can DPL be coerced to evaluate templates before looking at the page 3. Can DPL (or another extension) select the text from a section before/after a matched section? 4. Is it possible to determine the section sequence number given the section name (so 'Second Page' results in 2, allowing me to use DPL to retrieve the name of section 2 -/- 1 and 2 + 1 to create the prev/next links?
Apologies for the long post, hopefully someone can point me to some good resources (I've been to Meta, Wikibooks, Medawiki.org but could very well have overlooked something there as the amount of info is a bit overwhelming and it is difficult to judge how up to date it is).
-- Regards,
Jean-Marc
_______________________________________________ MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
This email was sent to you by Thomson Reuters, the global news and information company. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thomson Reuters.
Hi all,
Just thought I would give an update to my earlier request. I have created a simple parserfunction to get the result I want (at the moment combined with a template to wrap the calls to the parserfunction).
It's a start, which I want to expand in several ways: - have the parserfunction retrieve the index page itself instead of using a template to transclude the page content into the indexpage parameter - support alternate name for the page name to display as link - support links with (i18n) 'Previous' 'Next' text instead of page title
The good part is that the index page only needs a plain list of pages that provide the sequence: PageA PageB PageC PageD PageE
Currently the previous/next links are placed via a template call:
{{PrevNext|IndexPage|CurrentPage}}
The template contains:
<code> <span class="prevnext">{{#bpprev:{{{2|{{PAGENAME}}}}}|{{:{{{1}}}}}}} • {{#bpnext:{{{2|{{PAGENAME}}}}}|{{:{{{1}}}}}}} </span> </code>
The parserfunction:
<code> # Define a setup function $wgExtensionFunctions[] = 'jmlBrowsePage_Setup'; # Add a hook to initialise the magic word $wgHooks['LanguageGetMagic'][] = 'jmlBrowsePage_Magic';
function jmlBrowsePage_Setup() { global $wgParser; # Set a function hook associating the "example" magic word with our function $wgParser->setFunctionHook( 'bpnext', 'jmlBrowsePage_Next' ); $wgParser->setFunctionHook( 'bpprev', 'jmlBrowsePage_Prev' ); }
function jmlBrowsePage_Magic( &$magicWords, $langCode ) { # Add the magic word # The first array element is case sensitive, in this case it is not case sensitive # All remaining elements are synonyms for our parser function $magicWords['bpnext'] = array( 0, 'bpnext' ); $magicWords['bpprev'] = array( 0, 'bpprev' ); # unless we return true, other parser functions extensions won't get loaded. return true; }
function jmlBrowsePage_Next( &$parser, $pagename = '', $indexlist = '' ) { $parser->disableCache();
// Match the line after a line: /^Line\r?\n(.*)/m $regex = "/^$pagename\r?\n(.*)/m"; $result = preg_match( $regex, $indexlist, $results );
if ($results) { $output = "[[$results[1]]]"; } else { $output = ""; }
return $output; }
function jmlBrowsePage_Prev( &$parser, $pagename = '', $indexlist = '' ) { $parser->disableCache();
// Match the line before a line: /(.*)\r?\nLine\r?\n/m $regex = "/(.*)\r?\n$pagename\r?\n/m"; $result = preg_match( $regex, $indexlist, $results );
if ($results) { $output = "[[$results[1]]]"; } else { $output = ""; }
return $output; }
</code>
If there is demand for this extension I am willing to complete it and donate it to the community by submitting it to Mediawiki.
mediawiki-l@lists.wikimedia.org