Hello all,
My mediawiki install was recently moved from a VPS to a dedicated
server. Ever since that move uploads have been very "flaky," sometimes
working and sometimes not.
When it does not work I receive the following error message.
"Could not copy file "/tmp/phpSomething" to
"/home/c/public_html/images/5/5a/image.jpg".
It seems that the smaller the image the better the chances that it will work.
Anyone have any ideas?
Thanks!
After reading the documents I was under the impression that if I placed
$wgLogo = "$wgStylePath/common/images/wikiSanMar.png";
In the LocalSettings.php our image should be available. But this does
not appear to be the case as I now have a blank Logo (which the docs
says happens if it can't find the image).
IF I place a png in the common/images directory what specifically do I
need in localsettings in order for the image to appear.
Thanks
DSig
David Tod Sigafoos | SANMAR Corporation
PICK Guy
206-770-5585
davesigafoos(a)sanmar.com
Hi,
I have a slight anomaly after merging two wikis in that the statistics
appear not to change after the merge. I have run various scripts in the
maintenance folder including rebuildall.php, updateArticleCount.php,
clear_stats.php and updateSpecialPages.php.
The combined wiki seemed to inherit identical stats from the wiki that acted
as a 'host' during the merge. Before the merge the 'host' claimed to have
3746 total pages and 407 legit pages. The wiki that got folded in claimed
7668 total and 616 legit. The combined wiki claimed 3746 total and 407 legit
(same as the 'host').
The only script that appeared to make a difference to those figures was
updateArticleCount.php. This bumped up the legit article count of the
combined wiki from 407 to 871, but oddly the total no. of pages stayed
resolutely at 3746.
I'll briefly mention how I did the merge in case it is relevant:
*Wikis being merged were old (1.5.2) so upgraded them individually to 1.9.3.
All seemed fine.
*Used dumpBackup.php to extract data from the wiki to be folded into the
'host' wiki
*Used importDump.php to import this data into 'host' wiki
*Ran rebuildall.php
*Copied images from merged wiki into image folder of 'host' wiki, then ran '
rebuildImages.php --missing' to recover image information in tables (as
image data in tables don't seem to transfer in dumpBackup / importDump
process).
*Ran rebuildall again as well and other scripts mentioned in opening
paragraph.
I certainly didn't expect the total pages to be the sum of the two wikis as
I there are a lot of shared pages both in the Mediawiki namespace and there
were some duplicates in the main namespace too.
All the page titles seem to list OK in the 'all articles' special page and
various pages I've manually visited from each contributing wiki seem to be
exist in the combined wiki which is heartening. I am just concerned that the
'total pages' stubbornly not reporting correctly may indicate data integrity
problems, and feeI slightly reluctant to make this combined wiki
operational, in case there are issues later on.
Any suggestions to get the statistics reporting correctly gratefully
received.
Regards,
Charles.
2007/3/25, Markus Krötzsch <mak(a)aifb.uni-karlsruhe.de>:
> > Is the page in a different namespace? E.g. If it's [[User:Skierpage]]
> > then you have to add
> > [[User:+]]
>
> True, or you could change the default namespaces that <ask> is searching. The
> default is:
>
> $smwgIQSearchNamespaces = array(NS_MAIN, NS_IMAGE);
>
> You can add any namespaces, or set the whole value to NULL to switch off this
> restriction. While S' other suggestions also are very reasonable, this seems
> to be a very likely cause of the problem.
That dit it.
It seems the default value for $smwgIQSearchNamespaces has changed.
Before, disabling the line was enough to search in all namespaces. Now
we must set it to null.
Thanks to all that helped.
I am trying to get the short URLs working and after searching the mailing
list archives don't see a solution to my problem anywhere.
I am starting to think that the Drupal modifications (see bottom) to
.htaccess are causing my "Page not found" errors on all Mediawiki pages.
I followed the instructions at both URLs below but have had little success.
http://www.mediawiki.org/wiki/Manual:Short_urlhttp://www.mediawiki.org/wiki/Using_a_very_short_URL
Here are my steps so far:
1) I have added the following line into my LocalSettings.php file.
$wgArticlePath="/wiki/$1";
2) I have added the following line to my .htaccess file in the DocumentRoot
folder (/public_html)
RewriteRule ^/wiki/(.*)$ /archives/index.php?title=$1 [PT,L,QSA]
Note that Mediawiki is installed into a folder called archives off of the
root (public_html). So the mediawiki index.php is located at
public_html/archives/index.php
I have Drupal installed into the root folder which already had inserted the
lines below into the .htaccess file. I simply added my new line below these.
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
This has now become (to include the Mediawiki rule):
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
RewriteRule ^/wiki/(.*)$ /archives/index.php?title=$1 [PT,L,QSA]
Any suggestions?
Thanks,
Paul
Hello,
I am writing a special page extension that does a mass creation of
articles. Since there will be a lot of articles created, the extension
takes some time to finish, especially when putting in some sleep-time.
The user should have some kind of progress information, which could be a
single text line.
My problem is, that the page is only displayed once before the user hits
the start button and once after the code has finished.
Is there a way to place some output on the screen without exiting the
extension code?
Thank you for help,
GunterS
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello all
I have a a wiki site like /index.php/Test with a content:
<myextension/>
If a user change something with my extension, I'd like to update the
recentchanges/rss list. How is this possible? Isn't it?
Thank you for help.
/maba
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGBSci8JLvhlgYtaoRApJxAJ4nJ4uHlOPA4+dn78qvBy2xbJuWPwCeOVnV
6UzjCuY7INWSXDsGXx3mrsc=
=0qdf
-----END PGP SIGNATURE-----
Caitlin Dempsey wrote:
> Anybody know if it's possible to see a list of pages that contain no
> internal links. I looked through the special pages and couldn't see
> anything that would provide that.
>
Special:Deadendpages
Filip wrote:
> Special:Deadendpages
Deadendpages only gets me the pages that have no internal links TO them.
I'm trying to find pages that contain no internal links, that is, the page
only has text on it with no links to other pages in the wiki.
______________________
Caitlin Dempsey, Editor
GIS Lounge
http://gislounge.com
editor(a)gislounge.com
---
Ricardo Rodríguez
Your XEN ICT Team
>>> Platonides<Platonides(a)gmail.com> 24/03/07 8:23 >>>
>This is done to make the second user aware of the changes, so
>he can merge both.
Thanks. It is now clear to me. And this is the problem at the same time: it is clear to me but it I am not sure I will be able to convince team members to expend time understanding it.
>Then the second one would simply "won" without noticing.
>
>One solution could be stating that before editing very-used
>articles they had to do a microedit adding a template
>
>{{i'm editing this|~~~~}}
>and then do the full edit (removing the template on it) so if
>a user wants to edit an article and it has the template, he
>should wait (if the template was added recently, of course).
>Another way could be doing one edit per section. Edits on
>different sections merge gracefully, and an edit conflict on a
>section will be small.
>
>Saludos
The template works great. But, could you figure out how to automatically introduce it at the top of the document/section to be edited when you hit the edit button and automatically remove it when hitting the Save one?
This will avoid to relly on the user action to copy/paste/remove the template to warn other users she/he is editing the concerning section.
Could it be a feature request?
Saludos!
---
Ricardo Rodríguez
Your XEN ICT Team
>>> Fred Bauder<fredbaud(a)waterwiki.info> 24/03/07 7:39 >>>
>I'm not sure if your question is about coding or editing. When
>an edit conflict happens you need to hit your back button and
>save the new content, which, hopefully, is in a compact
>section. Then you need to take a look at the other edit, by
>checking the edit history. Not a good idea to simply replace it.
>If both edits are spread all over the page, all you can do is start
>over. So a good habit not to make extensive edits over the entire
>text of a popular article, especially if you are taking a lot of time.
>I can't imagine a coding solution for conflicts between two edits >
>when both make numerous changes spread over the whole article.
>
>Fred
Hi, Fred,
Thanks for the explanation. I am afraid I have missused the term "coding" in my first message. I understand now that "editing" is the right word.
I think I get the point. I agree about the good habit of a by section edition and short time edition sessions and frequent save hits. But the problem is that I can not enforce these habits (or I do not know how to do that). Thus, any action that can not be enforced as part of an use policy, risks to be never considered. If frequent edition conflicts risk the edition process, the solution will be to forget the wiki as a collaborative edition solution. Even worse: to forget collaborative edition at all!
My challenge is to convince people about the fact that collaborative edition using wikis is a good idea. I truly think it is! So, I think MediaWiki should have a better support for simultaneous edition.
I can figure out two complementary paths:
1. By avoiding completely risky situations. Or at least by producing a clear warning issued by the system when an user start editing a section already edited by other. Something close to the early proposal by Frederik Dohr. I do not know if this is possible at all by using a PHP application. Of course this will avoid non-conflictive simultaneous edition, but is there any way of detecting conflicts on the go?...
2. ... a better support to manage conflicts. Has anybody integrated Synchroedit with his/her wiki?
As MediaWiki by itself is a "collaborative effort", I should be ready to contribute. I only can do that now by posting my own poor experience trying to promote its use. I do hope I will able to do something better in the near future! Thanks for your help.
Any new input will be welcome!
All the best,
Ricardo