Matthew:
Thanks! I just commented that line, and the result is exactly what I
wanted. I suspected that hacking Parser.php would be necessary, but
hoped it wouldn't be.
I think maybe I'll make a feature request.
Thanks again!
Mike
>>> Matthew.Simoneau(a)mathworks.com 12/22/04 2:40 PM >>>
> "Auto-number headings" applies to the numbering of headings within
the
> body of the article (as I just discovered by enabling it). What I
want
> to be able to do is disable the auto numbering of table of contents
> entries in the table of contents that appears at the *beginning* of
the
> article.
Now I understand what you want. There isn't any way to do it without
touching the code. These are the relevant lines from Parser.php:
if( $doNumberHeadings || $doShowToc ) {
$tocline = $numbering . ' ' . $tocline;
...
}
Since $doShowToc will be true, you'll always hit that middle line.
Also, the numbering is attached with the same style as the text, so
there's no way to hide it with CSS. The smallest change you could
make
to the PHP-file to do this is to comment out the middle line above.
Sincerely,
Matthew Simoneau
_______________________________________________
MediaWiki-l mailing list
MediaWiki-l(a)Wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
Is this a supported configuration in 1.3.9:
The URL is http://developer.fictionalley.org/wiki. ModRewrite permits
http://developer.fictionalley.org/wiki/Main_Page for the top page. And the
links on the pages are similar URLs.
The problems I'm seeing are numerous redirects with the Apache log
ping-ponging between URLs like the following:
GET /wiki/?title=User ...
GET /wiki?title=User ...
GET /wiki/?title=User ...
GET /wiki?title=User ...
However, if I configure LocalSettings to display the links on the pages to
contain index.php in the URL (for example,
http://developer.fictionalley.org/wiki/index.php/Main_Page), there are no
problems with numerous redirects.
The reason I'm wondering if links on the page of this form is supported is
that half the redirects happen from the file includes/RawPage.php on line
63. And in my configuration, wgScript is '' and PHP_SELF is '/wiki/'. To
me, it looks like this is intended in that file and it was looking for a
filename/script in the URL.
An interesting thing this is, wikipedia.com and meta.wikipedia.org have no
problems with having URLs without including the script name, index.php.
Help!
Thanks,
Paul
What is the current expected release horizon for the first full-working
version of MediaWiki v1.4?
Morten :-)
--
Crews Cut Community
http://www.crewscut.com
Morten Blaabjerg
Dronningensgade 4B, DK-5000 Odense C.
Tlf. +45 65 90 60 88
I would like to be able to use java applets and flash on wiki pages.
Any idea how could I achieve that?
(let's say that uploads of jars will be done manually)
Thanks for any comments,
KK
During a upload of a PDF file, I get:
The file you uploaded seems to be empty. This might be due to a typo in
the file name. Please, check whether you really want to upload this
file.
The file size is 6600584 bytes. I made sure that the file name was
typed in correctly. Another user is having a similar trouble with some
tgz files.
Thanks for your help.
john
John S. Lee
Public Sector, HP Services
Hewlett-Packard Company
johnswlee(a)hp.com
Columbia, MD: (443) 285-4214
Hi:
I'm instlling mediawiki in a web server where I have an account. I
uploaded all the files and set the wiki up. Everything was OK until
then. The LocalSettings.php file was succesfully created, but when I
copied it to the root directory and followed the link to the wiki
server, I received the following error message from the web server:
[pear_error: message="failed to open stream: Operation not permitted"
code=0 mode=return level=notice prefix="" info=""]
I hope somebody can explain what's the problem.
Thank you!
Abel
I have a small problem.
Recently a worm has been assailing the web (using Google to search out new
victims). I had MediaWiki installed alongside phpBB on PHP 4.3.9. After PHP
released 4.1.10 (which was duly installed by my host) the worm began making
the rounds. phpBB was the primary target - luckily phpBB released a patched
version to block any potential attack by the worm.
Unfortunately even with PHP 4.1.10, and the new phpBB - MediaWiki is being
hit hard. It's the only PHP application effected on my server. Here's the
worm's message which it leaves behind:
This site is defaced!!!
NeverEverNoSanity WebWorm generation 25.
[pear_error: message="Template function
'tpl_0_7_0_d709070e8418c9bc7d313434ecea7226' not found (template source :
/home/groups/e/es/esun/htdocs/wiki/templates/xhtml_slim.pt" code=0
mode=return level=notice prefix="" info=""]
I still need to track which files were effected or how the worm works - but
thought I'd post it here. You all do great work - :) and I'm cool with
waiting for whatever issue (whether my host or the wiki app) to resolve
itself in time.
-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-
Pádraic Brady
aka Maugrim The Reaper
http://www.quantum-star.com/http://www.shadowsrising.net/
-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-
> Have you tried modifiying the link to say:
>
[{{SERVER}}{{localurl:Special:Userlogin|returnto={{NAMESPACE}}:{{PAGENAM
E}
> }}}]
This works! It is marked as an off-Wiki link, but I can live with that.
Thanks for your help. Please let me know if there's anything I can do
for you, like send you a Gmail invitation or help with some Wikipedia
edits.
Sincerely,
Matthew Simoneau
I'm currently in the proces of setting up a MediaWiki site, using
v.1.3.8. I was overwhelmingly surprised at the ease of setting things
up, and everything works quite well, (although a few things does not yet
so). I have a number of questions, I would like to have shed some light
on. And this seems like a good place to ask them. (Maybe someone would
one day collect the questions asked here, and expand on the online
documentation on the WikiMedia site help pages? -maybe I can contribute
to that some day...!) I intend to upgrade to v1.4 as soon as it is out,
so if any of the following is too much trouble with v1.3.8 and will be
solved with v1.4 I would like to know.
LANGUAGE
What is causing me the most trouble is the language issue, and the
special messages. While I intend the site to be informative and inviting
to global users, I reckon it will mostly be used by danish-speaking
local people, cooperating on creative projects and expanding a base of
knowledge.
When setting up the wiki, I decided to set up with the english version
of the text, which it seems I am now stuck with?
-is it possible to change the interface language from english to danish
(including all the special messages) after setup and with a growing
database? - which files are relevant?
Is it possible with MediaWiki 1.4 for users to specify their preferred
site language in their preferences, for the interface and system
messages? - how is this managed more precisely? - Which files will still
be of concern to me, after the install of MediaWiki 1.4?
Is it possible to limit the languages available to users, if one cannot
commit to customizing one's wiki to all kinds of languages? -or the
system messages can be kept to such a minimum, that I won't have to
(which I doubt)?
IMAGES
Another concern of mine, is images. Since my server runs in PHP Safe
Mode, image upload is automatically disabled (I strongly suppose that is
why it doesn't work, even though all the flags should be correct). I'd
really want image upload to be enabled, so what are my alternatives?
-will this be solved in MediaWiki v1.4.? -as suggested in the beta
release document?
-can I alternatively add the information included when uploading to the
database by directly querying the MySQL db myself, and uploading the
images manually via FTP? - this would be the best solution to get me
started for real using images, if possible. Right now all I do is
manually upload images and create tables with direct links to them.
Clearly this is not an optimal solution and use of the software. And it
breaks the creative flow, as all images will have to go through the
administrator.
OTHER QUESTIONS & COMMENTS
How does one best limit the menu items, user preferences or special
pages of no relevance to one's customization? Which files are the
important ones to meddle with, to remove, say, certain skins, from being
selectable by a user? The site has been designed with a site-particular
skin, a modified monobook-css etc. and you don't want the site style to
appear otherwise to the user. How do you do that?
Why not keep all the system messages within the file system, easily
accessible from the root system, - and keep them all out of the wiki?
There are quite a few "wikipedia leftovers" for instance, in the special
messages, such as a number of unneccessary references or links, that are
empty, and a bit of a hazzle to track down and eliminate. No need to
refer in the special messages to a 'policy' if a small site doesn't have
one (yet)... No need either IMO to wet everything in a
copyright/disclaimer context, if the site in question or users has no
need for them, but only loads their base engine with existing links to a
lot of non-creative empty 'paragraph pages' (and all that even before
there's any creative content).
This is just constructive criticism - so far from ever becoming a
programmer myself, I can only hack, copy n' paste and learn bits
everywhere. I love the power of the wiki concept - I feel I am
witnessing the maturing of the internet and its real creative power
here. Keep up the good work :-)
Cheers :-)
--
Morten Blaabjerg
morten(a)crewscut.com
Tlf. +45 65 90 60 88
We require a login for our corporate intranet Wiki. If you try to edit
a page and you're not logged in, you receive the message
"You have to login to edit pages." (with "edit" a link to the login
page)
This text is defined by the "MediaWiki:Whitelistedittext" system
message. Here is that message's Wiki markup:
"You have to [[Special:Userlogin|login]] to edit pages."
I've been receiving complaints from users that if you click on that link
and log in, the following page gives you a link to the Main Page, not
the page you wanted to edit, and you have to navigate back where you
were.
You do, however, get this link back to where you were if you use the
"Log in" link in the page navigation, rather than the link from
Whitelistedittext. This is because the link contains the "returnto"
parameter:
.../index.php?title=Special:Userlogin&returnto=My_Page
What is the cleanest way to add the "returnto" parameter with the proper
value to this other link, the one generated from Whitelistedittext?
I've been fooling around with this for a while and haven't found a clean
solution. Has anyone else tackled this?
Thanks for your help!
Sincerely,
Matthew Simoneau
The MathWorks, Inc.