All,
Upgrading to version 1.10.1 by rerunning the install. Received
positive results except getting the following error on new wiki Main
Page:
Warning: mkdir() [function.mkdir]: Permission denied in /home/
jcapp197/public_html/wikiboats/wiki/includes/GlobalFunctions.php on
line 1695
Please advise.
James
I think there are two ways to do this. Easy-hackish, and a harder-better way.
First way is to rewrite queries, basically, you would make your extension,
or modify an existing one to rewrite queries like "Bob Jr" into "Bob (Jr
OR Junior)". So, a simple regexp search/replace will do. However, if you
add a feature like this in existing extension, it might brake in the
future ...
The other way is to use the lucene extension, and add a custom filter that
would inject synonyms during indexing, so that you would index Bob Jr as
Bob Jr Junior (where Jr and Junior would be in the same position in the
text, thus threated as aliases by lucene). You can do this by making your
filter, and then listing it for your language in FilterFactory.java in
init() method.
In any case, I don't think it would slow down search too much, especially
if you don't have a lot of synonyms, and they are not extremely frequent,
but performance-wise the second solution is better.
robert
> I am looking to enhance search in my MW install such that someone
> searching
> for some of the common abbreviations below would find a page with the
> fully
> word in its title.
> E.g. I might have a page called Billy Bob Junior¹ but my users might type
> Billy Bob Jr¹. I would want the Jr to match as well as the other words.
> Is there any manner of allowing this type of search.
> I am starting also to look at Lucene and wondered if anyone has experience
> of the performance differential I might expect.
I am looking to enhance search in my MW install such that someone searching
for some of the common abbreviations below would find a page with the fully
word in its title.
E.g. I might have a page called Billy Bob Junior¹ but my users might type
Billy Bob Jr¹. I would want the Jr to match as well as the other words.
Is there any manner of allowing this type of search.
I am starting also to look at Lucene and wondered if anyone has experience
of the performance differential I might expect.
Common abbreviations I am dealing with.
Gdns would find Gardens
Nth would find North
Jr or Sr would find Junior or Senior
St would find Saint
Many thanks,
Paul
Hello all!
I'm writing a custom tag (I call it <xdata>) that looks like this:
------------------------------------------------------------------
Article Name: Country:US
The US has a population of <xdata id="US_Population">280,000,000</xdata>.
------------------------------------------------------------------
I would like to check or extract the contents of this custom XML tag before saving it. Is there any convenient way to extract the following information:
1) id attribute (e.g. "US_Population" in the above example) in the opening tag
2) the value in between the opening and closing tags (e.g. 280,000,000 in the above example).
I noticed that the $wgParser->setHook( 'xdata', 'some_function') can extract extract attributes like "id" and store it in a variable $argv.
For example, I have written the ff. code to correctly parse the custom tag BEFORE DISPLAYING it:
function wfXdataExtension()
{
global $wgParser;
$wgParser->setHook( "xdata", "renderXdata" );
}
function renderXdata( $input, $argv, &$parser )
{
// some code that uses contents of $argv
}
I am looking for a way to parse the custom tag BEFORE SAVING an article that contains it.
Thank you very much!
Filip
Send instant messages to your online friends http://uk.messenger.yahoo.com
Thomas Dalton wrote:
> While there have been lots of suggestions for WYSIWYG, it is very
> difficult to implement with the current syntax (for technical reasons
> I don't fully understand). The MediaWiki syntax isn't that difficult
> to learn, however. You don't even need to use it at all, you can just
> type in plain text. If you want simple formatting (headers, bold,
> italic), it's quite easy. Things like tables and templates are much
> more complicated, but there is no need to use them for most content.
With all due respect, saying that MediaWiki syntax "isn't that
difficult to learn" is just like saying that HTML or Wordperfect's
old markup language "isn't that difficult to learn." The worlds of
word processing and desktop publishing have gone to WYSIWYG for a
reason: It really *is* easy to learn, and nothing else really matches
it.
MediaWiki syntax is better than CamelCase and may be marginally
easier to learn initially than HTML, but once you get past beginner-
level editing, there's nothing easy about syntax like {{info |
param1=foo | param2=bar}}. For that matter, I don't see how
'''this''' or ''this'' is any easier to understand than <b>this</b>
or <i>this</i>. The HTML version is a few more keystrokes, but it's
actually easier to guess that <b> means bold than it is to guess that
''' means bold, and '' for italic is easily mistaken for a quotation
mark.
I think MediaWiki's supposed ease of use is mostly a convenient
excuse for complacency and a way of avoiding dealing with the mess
that the parser has become. I predict that eventually someone will
develop a WYSIWYG wiki platform that does everything MediaWiki can
do, and once that happens, even Wikipedia will have to follow suit to
stay relevant. Its big advantage right now is that it has great
<i>content</i>, not that it is particularly easy to edit.
Umair Imam wrote:
> And the only problem is that i have to be bound to a WYSIWYG based
> wiki.
> Is there any other wiki which is as stable and simple as Media Wiki ?
You might want to try Wetpaint, which offers free WYIWYG wiki hosting:
http://www.wetpaint.com/
I tried them out awhile ago and thought they looked pretty good
overall. They weren't a good fit for my needs. (I'm sticking with
MediaWiki for now.) However, someone else might find them easier to use.
--------------------------------
| Sheldon Rampton
| Research director, Center for Media & Democracy (www.prwatch.org)
| Author of books including:
| Friends In Deed: The Story of US-Nicaragua Sister Cities
| Toxic Sludge Is Good For You
| Mad Cow USA
| Trust Us, We're Experts
| Weapons of Mass Deception
| Banana Republicans
| The Best War Ever
--------------------------------
| Subscribe to our free weekly list serve by visiting:
| http://www.prwatch.org/cmd/subscribe_sotd.html
|
| Donate now to support independent, public interest reporting:
| http://www.prwatch.org/donate
--------------------------------
You may also wish to try
http://www.mediawiki.org/wiki/Extension:Simple_Security
Regards,
Jack
----------------------------------------------------------------
"If you can find something everyone agrees on, it's wrong"
-----Original Message-----
From: mediawiki-l-bounces(a)lists.wikimedia.org
[mailto:mediawiki-l-bounces@lists.wikimedia.org] On Behalf Of Marco
Ferretti
Sent: Tuesday, July 24, 2007 2:29 AM
To: mediawiki-l(a)lists.wikimedia.org
Subject: [Mediawiki-l] managing users rights
Hello all,
this is my first post, forgive me if this is not the right
place & please direct me to the right one.
I am in the process of moving documentation to mediawiki and
would, basically, create three groups :
1- Admins ( can do anything )
2- Editors ( can edit anything )
3- Contributors ( can read *most* of the pages + edit all
they can see + submit new documents but Editors must approve
)
4- Readers ( can read the same pages as Contributors )
I have already a bunch of documents ( 900 more & less ) that
I have already *converted* to the wikimedia format . Now,
what I would like to do is to flag the documents so that
they can be classified using the 4 steps above.
I am currently using version 1.6 ( well, it is the DEV one
so I can upgrade if necessary) .
Surfing the documentation I have read about
http://www.mediawiki.org/wiki/Extension:Group_Based_Access_Control
and that version 1.10 has a new table ( page restrictions
http://www.mediawiki.org/wiki/Page_restrictions_table ) .
Is there any other way to achieve what I need ? If yes, can
you please point me somewhere ? If no, considering that I
will be tagging the pages programatically ( I wouldn't want
to manually edit 900 pages ), what would be the best
solution for my problem ?
TIA
Marco
_______________________________________________
MediaWiki-l mailing list
MediaWiki-l(a)lists.wikimedia.org
http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
This electronic mail (including any attachment thereto) may be confidential and privileged and is intended only for the individual or entity named above. Any unauthorized use, printing, copying, disclosure or dissemination of this communication may be subject to legal restriction or sanction. Accordingly, if you are not the intended recipient, please notify the sender by replying to this email immediately and delete this email (and any attachment thereto) from your computer system...Thank You
I want to write PHP code for a MediaWiki I own (I have command-line +
admin access) that:
% Checks if a given article exists, and creates it if not.
% Checks if a given section exists in an article, and creates it if not.
% Edits a given section in a given article.
I want the edit to be done just as if a user had gone in and edited
the page: it should create a history entry, update all the appropriate
tables, update the page in the cache, etc.
Can I use MediaWiki's PHP functions/libraries to do this?
I realize I can use wget/curl/lynx/elinks to do this, but was looking
for something more "internal".
On a related note, does MediaWiki come w/ any maintenance tools? Examples:
% Auto-fix all double redirects (if X -> Y -> Z, just edit X to
redirect directly to Z).
% Find all instances of certain words (eg, spam), and revert to the
previous version of each page that contains those words (crude
anti-vandalism tool). Delete pages where there is no previous version.
% For commonly misspelled articles, find all instances of [[wrong
spelling]] and change them to [[correct spelling]] (redirecting "wrong
spelling" to "right spelling" sort of works, but it still leaves the
link misspelled on many pages)
I realize SQL queries can do some of this, but they won't update the
history, won't handle caching issues properly, etc. I'm looking for
something that works within MediaWiki's framework, not an outside
hack.
--
We're just a Bunch Of Regular Guys, a collective group that's trying
to understand and assimilate technology. We feel that resistance to
new ideas and technology is unwise and ultimately futile.
Is it possible to do something so that a link like
[[:Category:Homer]] doesn't go to an edit page even if there
is no text in the category page, but just goes to the
category listing, as if I had written "Category:Homer" in
the search box? (Other than manually putting the content
" " into each category page so linked, that is!)
TIA,
/BP
> I predict that eventually someone will
> develop a WYSIWYG wiki platform that does everything MediaWiki can
> do...
Leopard Server Teams is looking pretty good... if Apple would only
get off this iPhone distraction and get Leopard released.
:::: I think our [energy] policy is called "aircraft carriers." --
Irwin Steltzer, 1987 ::::
:::: Jan Steinman http://www.VeggieVanGogh.com ::::
Hello,
I am interested in hacking our sidebar to dynamically draw content from
the TOC on certain pages. Does anyone know where the code is that
generates the TOC on each wiki article?
Thanks,
John Getzke
Jgetzke(a)ptc.com