There was some discussion on one of the mailing lists about
protecting specific sections in a wiki page, where Rob Church noted
an extension called ProtectSection.php. I have modified the code to
run one of the functions at a different hook, which allows me to also
kill any subsection Edit links on headings inside a protected
section. I have it working on 1.8.3 and 1.7.1 locally.
I noticed that ProtectSection in svn has been modified by tstarling
and hashar (tstarling says "It's still completely broken with
section editing, though." ... but it seems to work for me, unless I'm
misunderstanding the issue. Also, if the section edit links are
gone, the issue may be moot.). How should I submit the code
modification for others to look at? I wasn't sure if this should go
to bugzilla bug 4375 or here. I hope that my code modification may
be worth looking at, but I worry that it's too hacky to warrant
consideration yet for the topic of the bug.
Please advise.
=====================================
Jim Hu
p.s. What I did was move the call to one of the functions,
wfStripProtectTags, to ParserAfterTidy, and changed it to:
> function wfStripProtectTags ( &$parser , &$text) {
>
> $tmp = explode("<protect>",$text);
> $sections = array();
> $sections[] = array_shift($tmp);
> foreach($tmp as $block){
> $tmp = explode("</protect>",$block);
> $sections[] = "<span class='protected'>".preg_replace("/<div
> class=\"editsection(.*?)<\/div>/i", "", $tmp[0])."</span>";
> array_shift($tmp);
> $sections[] = implode('',$tmp);
> }
> $text = implode("",$sections);
> return true;
> }
someday I'll learn how to use diff :(
Is there any way I can stop that gaping mouth of an edit box on empty
category pages??
P.S., I will see you here in Taiwan at WikiMania, 8/2007.
function fnmybla($text,$title)
{
if ( ( NS_CATEGORY == $title->mNamespace )
|| ( NS_CATEGORY_TALK == $title->mNamespace ) )
{
$text = "(Please don't edit any Category pages on this wiki.
They are ment to have members, but no text bodies, on purpose. I
cannot figure out any way to stop the big edit window from opening
below. I wish when one visits action=edit on category pages, it would
act like action=view. I could have \$wgHooks['userCan'] return false,
but then the user is given 'This page has been locked to prevent
editing...' and must click an additional time to see what are the
member categories.
makeBrokenLinkObj() has no hook to stop making them &action=edit links
for empty categories. I wish I had a way to change them to
action=view, i.e., no action= parameter at all.)";
}
}
$wgHooks['EditFormPreloadText'][]='fnmybla';
function fnmyEdit(&$this )
{
#gave up due to not being a php phd
global $wgUser, $wgOut, $wgRequest, $wgContLang;
global $wgEnableParserCache, $wgStylePath, $wgUseRCPatrol, $wgParser;
global $wgUseTrackbacks, $wgNamespaceRobotPolicies;
global $wgArticle, $wgTitle;
$sk = $wgUser->getSkin();
wfDebug("qq$wgTitle->mNamespace $wgTitle->mTitle\n");
if ( ( NS_CATEGORY == $wgTitle->mNamespace )
|| ( NS_CATEGORY_TALK == $wgTitle->mNamespace ) )
{
#maybe these will do what I want, except I don't know how to invoke them.
CategoryPage::view();
#CategoryPage::doCategoryMagic();
return false;
#you see, I want the user to see just what he would if action=view,
though he did HTTP GET action=edit.
#no, Article::view(); won't get the category links shown.
}
return true;
}
$wgHooks['AlternateEdit'][]=fnmyEdit;
As you can see I want to contain all this inside LocalSettings.php.
I've been interested in WYSIWYG editing for MediaWiki for a long time.
For others who are interested, you may want to look at the new PBWiki
WYSIWYG editor. It's very nicely done.
Obviously, there's not anything there we can use, but it's interesting
to see that PB has gone WYSIWYG nonetheless.
~Evan
________________________________________________________________________
Evan Prodromou <evan(a)prodromou.name>
http://evan.prodromou.name/
We had some slowness today, where after some temporary issue cluster ended
up spending >50% of it's time working on Spanish wikipedia template. We
nuked the template (es.wikipedia site was also turned off at some moment),
so now it is all up and running.
The template was used for adding a single line of text, though it took 20
seconds to render. ;-)
We'll probably have to do something about that.
Cheers for now,
Domas
Is there any reason why you work with pre-defined levels for page protection
(default, block unregistered users, users with the sysop right), why not
base the protection on the available groups available in the user_groups
table?
cheers,
Peter.
An automated run of parserTests.php showed the following failures:
This is MediaWiki version 1.10alpha (r19680).
Reading tests from "maintenance/parserTests.txt"...
Reading tests from "extensions/Cite/citeParserTests.txt"...
Reading tests from "extensions/Poem/poemParserTests.txt"...
18 still FAILING test(s) :(
* URL-encoding in URL functions (single parameter)
* URL-encoding in URL functions (multiple parameters)
* TODO: Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html)
* TODO: Link containing double-single-quotes '' (bug 4598)
* TODO: message transform: <noinclude> in transcluded template (bug 4926)
* TODO: message transform: <onlyinclude> in transcluded template (bug 4926)
* BUG 1887, part 2: A <math> with a thumbnail- math enabled
* TODO: HTML bullet list, unclosed tags (bug 5497)
* TODO: HTML ordered list, unclosed tags (bug 5497)
* TODO: HTML nested bullet list, open tags (bug 5497)
* TODO: HTML nested ordered list, open tags (bug 5497)
* TODO: Inline HTML vs wiki block nesting
* TODO: Mixing markup for italics and bold
* TODO: 5 quotes, code coverage +1 line
* TODO: dt/dd/dl test
* TODO: Images with the "|" character in the comment
* TODO: Parents of subpages, two levels up, without trailing slash or name.
* TODO: Parents of subpages, two levels up, with lots of extra trailing slashes.
Passed 489 of 507 tests (96.45%)... 18 tests failed!
An automated run of parserTests.php showed the following failures:
This is MediaWiki version 1.10alpha (r19671).
Reading tests from "maintenance/parserTests.txt"...
Reading tests from "extensions/Cite/citeParserTests.txt"...
Reading tests from "extensions/Poem/poemParserTests.txt"...
18 still FAILING test(s) :(
* URL-encoding in URL functions (single parameter)
* URL-encoding in URL functions (multiple parameters)
* TODO: Table security: embedded pipes (http://mail.wikipedia.org/pipermail/wikitech-l/2006-April/034637.html)
* TODO: Link containing double-single-quotes '' (bug 4598)
* TODO: message transform: <noinclude> in transcluded template (bug 4926)
* TODO: message transform: <onlyinclude> in transcluded template (bug 4926)
* BUG 1887, part 2: A <math> with a thumbnail- math enabled
* TODO: HTML bullet list, unclosed tags (bug 5497)
* TODO: HTML ordered list, unclosed tags (bug 5497)
* TODO: HTML nested bullet list, open tags (bug 5497)
* TODO: HTML nested ordered list, open tags (bug 5497)
* TODO: Inline HTML vs wiki block nesting
* TODO: Mixing markup for italics and bold
* TODO: 5 quotes, code coverage +1 line
* TODO: dt/dd/dl test
* TODO: Images with the "|" character in the comment
* TODO: Parents of subpages, two levels up, without trailing slash or name.
* TODO: Parents of subpages, two levels up, with lots of extra trailing slashes.
Passed 489 of 507 tests (96.45%)... 18 tests failed!
Why doesn't Special:Search ever find anything on my test wiki that is
on a computer powered up only a few hours every few days?
Must be some mysterious cron function. OK, this looks like it will
manually refresh things:
$ php rebuildtextindex.php
Dropping index...
A database query syntax error has occurred.
The last attempted database query was:
"ALTER TABLE `searchindex` DROP INDEX si_title, DROP INDEX si_text"
from within function "dropTextIndex".
MySQL returned error "1142: ALTER command denied to user 'wikiuser'@'localhost' for table 'searchindex' (localhost)"
OK, but why wasn't that detected/fixed by the upgrader script when I
upgraded to 1.9.0? Now what? Manually change some/what mysql things?
I don't want to put my fingers in there.