As some of you might recall, I am highly interested in finding a way to
convert MediaWiki pages to a format that can be edited by a word processor.
After reading Louis Suarez-Potts's (the OpenOffice.org Community
Manager) announcement about the ODF Toolkit
(http://odftoolkit.openoffice.org), I thought that this might make the
conversion easier.
However, I'm not programmer enough to really understand what this ODF
Toolkit actually is. All I know is that I've failed creating a script
for converting wiki content to ODF so far.
Does anyone happen to know more about this project - because if it's
worth it, I might (at least try to) use it for such a conversion script...
Thanks,
Frederik
Hello All,
I recently read on this mailing list
[http://lists.wikimedia.org/pipermail/mediawiki-l/2007-January/017269.html]
about the StableVersion extension, and I think I may be able to make
use of it. But I unable to get it to work.
I installed it as mentioned in the mail with Mediawiki verison 1.8.2.
I also checked on some of errors mentioned. When I try to make an
article stable I get the following error:
Warning: strcspn() expects parameter 1 to be string, object given in
<path>/wiki/includes/Parser.php on line 2558
Fatal error: Cannot use object of type ParserOutput as array in
<path>/wiki/includes/Parser.php on line 2560
Also, its mentioned that this feature is going to be incorporated in
the newer version of mediawiki. Do you know what version its going to
be in, or is already in.
I would appreciate any help or comments.
Thanks
-- Pranav
Thanks so far about the IDE.
I will check wheter some trial versions are available.
What strikes me most is the fact that there seems to be no clear strucutre
of the software.
Seems that I have to spend some more time before I'll have an overview ;-}
Regards
A. Cremer
"Dorozynski Janusz" <dorozynskij(a)wampnm.webd.pl>
schrieb im Newsbeitrag news:31184.7716141076$1169416870@news.gmane.org...
>| -----Original Message-----
> | From: ... Rolf Lampa
> | Sent: Sunday, January 21, 2007 8:26 PM
> /
> | Zend was already mentioned. Another #1 tool - with integrated (also
> | remote) debugging included - is Nusphere PhpED, more info here:
> |
> | http://www.nusphere.com/products/index.htm
>
> for 390 $
>
> but for 89 euro is phpEdit (http://www.waterproof.fr/) - with debugger,
> and
> for personal noncommercial works or education/training anybody can receive
> special licence for free
> (http://www.waterproof.fr/products/PHPEdit/buy-personal.php
> http://www.waterproof.fr/products/PHPEdit/buy-education.php).
>
> Reg., Janusz 'Ency' Dorozynski
I've installed this extension yesterday. Instead of more hits the search
produced less ...
Still looking for an explanation.
>
> Message: 2
> Date: Tue, 23 Jan 2007 11:54:13 +0000
> From: "aretai aretai" <aretaiuc(a)gmail.com>
> Subject: Re: [Mediawiki-l] Mediawiki 1.8.1 - Searching With Wildcards
> To: "MediaWiki announcements and site admin list"
> <mediawiki-l(a)lists.wikimedia.org>
> Message-ID:
> <5783abc70701230354l31d94764ib0c2ddf4cc6f8319(a)mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi,
>
> I've found sth you may find interesting. Let me know if it
> works for you as I would like to have it in my wiki soon as well:
>
> http://assela.pathirana.net/Wildcard_Search_Extension
>
> Regards,
> Aretai
>
>
> On 1/23/07, Wartner Carsten <c.wartner(a)tvzzd.de> wrote:
> >
> > The default mediawiki search routine doesn't support
> wildcards (*, ?).
> > Does anybody know of an extension or something to enable
> > wildcard-search? I'm using mediawiki 1.8.1. (PHP 5.1.6,
> MySQL: 5.0.26).
> >
> > Thanks.
> >
> >
> > Carsten
> > c.wartner(a)tvzzd.de
The default mediawiki search routine doesn't support wildcards (*, ?).
Does anybody know of an extension or something to enable
wildcard-search? I'm using mediawiki 1.8.1. (PHP 5.1.6, MySQL: 5.0.26).
Thanks.
Carsten
c.wartner(a)tvzzd.de
I have a parser extension to parse PHP scripts in wikitext, but it appears
that my 1.6.9 mediawiki server is caching pages since the scripts won't run
unless I edit the page they're on and resave. I know this is happening
because as a test I put in a simple command to echo the current date and
time and it can be a day off.
I've put "$wgCachedPages=false" in my LocalSettings but it doesn't seem to
have any effect. Client side browser settings don't do it either--I can
shift-click refresh or set IE to always check for new pages and I get old
data. Same problem in Firefox.
Any ideas how I can get my inline PHP scripts to always run?
Jim Titus
Hello everyone,
I am running a wiki for a research project with access restricted to the
participants. So far, it works quite well, but there is a problem with a
file upload.
When trying to upload a certain .ppt file, the data seems to be sent to
the wiki (according to the browser's progress bar), but when it should
be finished, all I (as well as the contributor whose file it actually
is) get is a blank upload form. However, this only occurs when I try
this from home. When I'm at work, i.e. in the same local network as the
server the wiki is on, I get to the file's description page, and the
file is shown correctly in the file list (which it is not in the former
case).
Even more confusingly, uploading different .ppt files (smaller as well
as larger ones) seems to work fine from everywhere, as is the case with
other file types (e.g. pdf). But when I convert the ppt file mentioned
above to pdf (using StarOffice), the result will not be uploaded
correctly either.
I am aware of the advice given at
http://meta.wikimedia.org/wiki/Uploading_files#I_get_a_Blank_Screen_.28IE.2…,
but it was not helpful in my case.
MediaWiki version is 1.6.7 (I set it up a while ago, and it was hardly
ever used since; futhermore, the server, on which I do not have admin
privileges, has only PHP 4.3.4).
The relevant lines in my LocalSettings.php are
$wgEnableUploads = true;
$wgUploadPath = "$wgScriptPath/img_auth.php"; #"prevent not
logged-in users from accessing files
$wgUploadDirectory = "$IP/files";
$wgCheckFileExtensions = false;
$wgStrictFileExtensions = false;
$wgUploadSizeWarning = 8 * 1024 * 1024;
$wgVerifyMimeType = false;
In the php.ini, memory_limit is 64M. I also tried
$wgMimeDetectorCommand= "file -bi" as described on the page linked
above, but on solaris (afair), the file command seems to work slightly
different, and since $wgVerifyMimeType is false anyway, this should not
have any effect, should it?
Thanks in advance,
Arne
Thanks again to all. I was able to find the solution (or, more accurately, a
clue to getting at the solution) in a PHP forum.
For those who are curious, the critical module for working with PHP and
MySQL under my specific setup (again, WinXP, IIS 5.1, PHP 5.2.0, MySQL 5.1)
is, in fact, a little file called libMySQL.dll ...
This file comes with MySQL, and actually lives in the MySQL/debug (there is
a version in the MySQL/bin folder, too -- but it's an older version and
didn't work for me -- that was what was frustrating my efforts so)
directory. Furthermore, you must make sure you have the most current version
of it (mine is approx. 2.49 megs in size ... the bad version is 1.49
megs)...
Thanks again to Arthur and Jason for their suggestions. It does seem like my
problem was pretty configuration-specific, so I'm not sure whether this
solution will be of use to others -- hopefully it will. Thanks again.
- Jeremy Milarsky
Sun-Sentinel
Fort Lauderdale, Fla.
-----Original Message-----
From: mediawiki-l-bounces(a)lists.wikimedia.org
[mailto:mediawiki-l-bounces@lists.wikimedia.org]On Behalf Of Arthur Guy
Sent: Monday, January 22, 2007 2:56 PM
To: MediaWiki announcements and site admin list
Subject: Re: [Mediawiki-l] Installation help
2 other things, have you granted read and execute access to the php
directory to the 2 iis user accounts along with write and modify access
to the session and upload directory within the php folder?
And finally does the output of phpinfo have a section detailing the
mysql connection dll and the default variables?
You could also try creating a simple php script containing a command to
connect to the database and see what happens?
Arthur
arthur(a)assys.net
_______________________________________________
MediaWiki-l mailing list
MediaWiki-l(a)lists.wikimedia.org
http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
I'm working on moving a number of Wiki's to V1.9 and have hit a problem
with the kWBreadCrumbs extension, which is complaining about both
wfStrencode & wfQuery functions, I've tried the various suggestions
about replacing wfStrencode with addQuotes() but I'm rather out of my
depth. The rest of the extension works with 1.9 (I've dot it running
without the kwBreadCrumbsNoCache function, any help would be
appreciated, as I'm out of my depth here, I've added the function code
to this email. If I can get it working I'll add it back into the
extensions list if this is felt appropriate.
Thanks
John
function kwBreadCrumbsNoCache()
{
global $wgTitle, $wgOut;
if (!isset($wgTitle) || !isset($wgOut))
{
return;
}
/*
Let's 'touch' the page to invalidate its cache.
The code below is slightly identical to Title::invalidateCache().
Even though invalidateCache() sets cur_touched to 'now', we are still
in the process of creating and rendering the page itself and the
page will be cached only once it is done. At the end of the day the
cache would always end up newer than cur_touched, defeating the whole
purpose of calling invalidateCache().
The trick here is to set cur_touched in the future, something not too
intrusive, say 'now' + 120 seconds, provided that we expect the cached
page to be created within 120 secs after this extension code has been
executed. That way, cur_touched remains 'fresher' than the cache, and
the page is always re-created dynamically.
*/
$ts = mktime();
$now = gmdate("YmdHis", $ts + 120);
$ns = $wgTitle->getNamespace();
$ti = wfStrencode($wgTitle->getDBkey());
$sql = "UPDATE pett_page SET page_touched='$now' WHERE
page_namespace=$ns AND page_title='$ti'";
wfQuery($sql, DB_WRITE, "kwBreadCrumbsNoCache");
// This does not seem to do anything. I assume once it's called here
// in the extension, it's already too late.
$wgOut->enableClientCache(false);
// The followings should prevent browsers to cache too long
/*
$wgOut->addMeta("http:Pragma", "no-cache");
$wgOut->addMeta("http:no-cache", NULL);
$wgOut->addMeta("http:EXPIRES", "TUES, 31 DEC 1996 12:00:00 GMT");
*/
// HTTP_IF_MODIFIED_SINCE ? // see OutputPage: checkLastModified
}
Thanks, Arthur, but the phpinfo page does indeed say the php.ini file is
where it truly is and the extension=php_mysql.dll is indeed uncommented.
Using Apache is also not an option (thanks anyway, Jason -- I do appreciate
all suggestions), because I work in a Windows shop and we have lots and lots
of ASP.NET apps existing already.
Thanks again for the effort, and if there are any other suggestions, please
feel free to send them my way.
- Jeremy
-----Original Message-----
From: mediawiki-l-bounces(a)lists.wikimedia.org
[mailto:mediawiki-l-bounces@lists.wikimedia.org]On Behalf Of Arthur Guy
Sent: Monday, January 22, 2007 2:04 PM
To: MediaWiki announcements and site admin list
Subject: Re: [Mediawiki-l] Installation help
Does the location of the php.ini file displayed in the output of phpinfo
correspond to the actual location of php.ini?
If so have you un-commented the line which includes the mysql dll file?
Arthur
arthur(a)assys.net
_______________________________________________
MediaWiki-l mailing list
MediaWiki-l(a)lists.wikimedia.org
http://lists.wikimedia.org/mailman/listinfo/mediawiki-l