Is there a way I can raise the limit on the max number of template
substitutions done in one page from 5 to something more useful for my
site in a configuration file? I've managed to figure out that I can
raise it by modifying the code in exactly one place (the definition of
MAX_INCLUDE_REPEAT in includes/Parser.php), but I'd rather not have to
touch the code at all, even for something so trivial.
PS yes, I understand the attack that this limit protects again, and
have judged that in an in-house wiki where all the users are trusted,
the actuality of the limit hurts more than the possibility of an
attack.
--
Luis Casillas <casillas(a)mercedsystems.com>
I need to do a simple hack to the default 1.3 skin. I need to put a donation link above the article title like Wikipedia's. I could do this in 1.2, but the new skin bewilders me. I may need to put it at the very top, before any content or links for preferences, login etc. Can anyone tell me the file name and/or line (I have dreamweaver) where I can insert my XHTML for this?
-Moonlight Embrace
P.S. Sorry if sent this twice, I first sent it through the wrong address.
I need to do a simple hack to the default 1.3 skin. I need to put a donation link above the article title like Wikipedia's. I could do this in 1.2, but the new skin bewilders me. I may need to put it at the very top, before any content or links for preferences, login etc. Can anyone tell me the file name and/or line (I have dreamweaver) where I can insert my XHTML for this?
-Moonlight Embrace
Hello,
It works wonderful, but I did find a couple of strange things:
The import page is still referring to a beta:
http://www.xxxxxxx.com/index.php?title=Special:Import
The system messages-page errors:
Warning: set_time_limit(): Cannot set time limit in safe mode in
/home/httpd/vhosts/xxxxxxxx.com/httpdocs/includes/SpecialAllmessages.php
on line 8
http://www.xxxxxxxx.com/index.php?title=Special:Allmessages
I get an error message at:
http://www.xxxxxxxx.com/index.php?title=Special:Maintenance&subfunction=dis…
wfSpecialDisambiguation is broken. Link tables have changed...
Further, I have chmodded my images directory, also for TMP, like
suggested, but I am a bit concerned that it is possible to upload
malicious code there to. Is there a way to prevent this? .htaccess?
Anyway, nice piece of work! Thanks!
--
Kind Regards,
Marko Faas
I've tried repeatedly to install a fresh copy of 1.3.0 on my server, but I
get a very strange problem. I enter the appropriate information into the
fields (no SQL root pw), and click "install". Some text shows up, the
browser indicates "Done", but no LocalSettings.php file is generated, and
when using a manually generated LocalSettings.php, I receive a 404 error
upon access of "index.php/MainPage". This problem occurs whether or not I
delete the tables, delete/re-upload the files, etc. I have set CHMOD 777
onto the /config/ directory as instructed.
PHP version: 4.3.8
MySQL version: 4.0.20-standard-log
This is the output of the install webpage:
- PHP 4.3.8: ok
- Warning: PHP's register_globals option is enabled. MediaWiki will work
correctly, but this setting increases your exposure to potential security
vulnerabilities in PHP-based software running on your server. You should
disable it if you are able.
- PHP server API is cgi; using ugly URLs (index.php?title=Page_Title)
- Have XML / Latin1-UTF-8 conversion support.
- PHP's memory_limit is 40M. If this is too low, installation may fail!
- Have zlib support; enabling output compression.
- Found GD graphics library built-in, image thumbnailing will be enabled if
you enable uploads.
- Installation directory: /homepages/45/d95239576/htdocs/mwiki
- Script URI path: /mwiki
Upon reading the source code output of the page, the html abruptly cuts off
at the last entry, no </body> or </html> tag. This must indicate some kind
of crash? Checking tables through phpMyAdmin shows that the relevant SQL
tables have been generated.
I don't mind performing a manual install, if it is at all possible with
1.3.0, but I will need some guidance as to what data needs to be loaded.
Thanks for your help
-Bryan
Calum Galleitch wrote:
>
> You can control access quite simply using .htaccess files. Check out your web
> server documentation - this is more secure than any software built-in
> security, and easier to manage, too.
I'm probably not understanding you correctly, but MediaWiki doesn't
store individual pages does it? There all stored in the database no?
--
Jean-Christian Imbeault
Assistant Manager
Technology Department
_____________________________________
Mizuho Securities Co, Ltd.
Tel: (03) 5208-2932 (direct)
Hello Wikings,
I am very impressed with this project. So I am trying to participate. I have downloaded everything and attempted to install it locally.
This is what I get during installation:
...ipblocks is up to date.
...already have interwiki table
...indexes seem up to 20031107 standards
...have linkscc table.
...linkscc is up to date, or does not exist. Good.
...have hitcounter table.
Converting links table to ID-ID...
Sorry! The wiki is experiencing some technical difficulties, and cannot contact the database server.
Any ideas?
Thanks
Len Yabloko
Next Generation Software
"If you're working on something new, then you are necessarily an amateur."
John Archibald Wheeler
Hello,
I was running 1.3 Beta 5, and made some changes to the
PHPTAL and the monobook skin,
WIll these changes still work in the new 1.3 release?
Or will I have to modify those in the 1.3 final
release as well?
Thanks
Jimmy
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail
"Richards,Michael" <Michael.Richards(a)gartner.com> wrote:
> The disadvantage is of course that the info in the file server is not
> edited collaboratively using a wiki, but we have found this no big
> deal (because there is not much of it).
One solution to this is to use a second, more private wiki instead of a
file server. If you use MediaWiki for this second wiki, you can
prevent non-logged in users from seeing anything other than the user
login page, and clamp down account creation.
--
Luis Casillas <casillas(a)mercedsystems.com>
The option we have used here at Gartner is to leave the sensitive information on files on file servers. We then add links in wiki articles directly to the files and only people with access to those file servers can click on the link.
Your situation may vary, but we have found that only a small percentage of info actually requires access control.
The risk with trying to add access control into the wiki itself is that you add an extra layer of complexity that can really put people off contributing.
The disadvantage is of course that the info in the file server is not edited collaboratively using a wiki, but we have found this no big deal (because there is not much of it).
You also need to configure the mediawiki software a little:
* edit OutputPage.php in the wiki directory (in Mediawiki 1.1 or wiki/includes/Parser.php in 1.2 or 1.3)
** enable links to external files by adding in the following line after the other ReplaceExternalLinks lines
*** $text = $this->subReplaceExternalLinks( $text, "file", false );
You can then add links to external files using this syntax:
* [file://servername/sharename/path/file%20name.ext alternate text]
Back slashes don't seem to work and the path and filename cannot contain spaces (hence the %20).
Michael Richards
-----Original Message-----
From: mediawiki-l-bounces(a)Wikimedia.org
[mailto:mediawiki-l-bounces@Wikimedia.org]On Behalf Of Jean-Christian
Imbeault
Sent: Thursday, August 12, 2004 12:50 AM
To: MediaWiki announcements and site admin list
Subject: [Mediawiki-l] Access control feature
I am in need of ACL (access control) for mediawiki. I've looked through
the docs and mailing list and it seems that mediawiki doesn't have that
feature. Am I correct?
If I were to try and implement that feature how hard would it be? Would
it be easy to plug in to the current architecture or is this feature
something so foreign to mediawiki that integrating it would require a
lot of effort?
Oh, and I do realize that ACLs go against the spirit of a wiki. It's
just that we would like to use mediawiki internally but some information
must not be viewed by certain employees (legal reasons, NDAs, etc ...)
Thanks,
--
Jean-Christian Imbeault