I'd like to announce the first release of EzMwLucene. This project provides a simplified Lucene search to Mediawiki. It is designed to be easy to install, configure, and run. It provides real-time, multiple field indexing and searching as well as text indexing of standard attachment types (pdf, xls, doc, ppt, vsd). The server is a self contained Java application (no application server needed), and the client portion is a standard Mediawiki extension. It is currently in production on an internal site with over 1000 users running on Mediawiki 1.13.
https://sourceforge.net/projects/ezmwlucene/
I welcome all feedback: questions, suggestions and offers to help improve it!
El 5/7/09 12:33 PM, Chris Reigrut escribió:
I'd like to announce the first release of EzMwLucene. This project provides a simplified Lucene search to Mediawiki. It is designed to be easy to install, configure, and run. It provides real-time, multiple field indexing and searching as well as text indexing of standard attachment types (pdf, xls, doc, ppt, vsd). The server is a self contained Java application (no application server needed), and the client portion is a standard Mediawiki extension. It is currently in production on an internal site with over 1000 users running on Mediawiki 1.13.
Sounds neat! Indexing of uploaded document contents would be very useful for some sites, and it would be great to have better real-time index update options for those sites with low enough traffic to handle it.
https://sourceforge.net/projects/ezmwlucene/
I welcome all feedback: questions, suggestions and offers to help improve it!
Any interest in helping to roll the new features into the existing Lucene search that's already actively maintained for Wikimedia? This would maximize availability of new functionality and ensure it's used and maintained in the future.
-- brion
2009/5/7 Brion Vibber brion@wikimedia.org:
Any interest in helping to roll the new features into the existing Lucene search that's already actively maintained for Wikimedia? This would maximize availability of new functionality and ensure it's used and maintained in the future.
I'm still looking forward to corporate readiness of MediaWiki, which for us basically means (1) good WYSIWYG (2) good search. (2) means Lucene in a box. We hardly care what box.
(The competitor is Confluence. Which is highly usable and an UTTER BASTARD to administer. Though Atlassian are very good at support.)
- d.
On Thu, 2009-05-07 at 21:33 +0100, David Gerard wrote:
2009/5/7 Brion Vibber brion@wikimedia.org:
Any interest in helping to roll the new features into the existing Lucene search that's already actively maintained for Wikimedia? This would maximize availability of new functionality and ensure it's used and maintained in the future.
I'm still looking forward to corporate readiness of MediaWiki, which for us basically means (1) good WYSIWYG
What's wrong with the FCKeditor extension?
Cheers, Rob.
2009/5/7 Robert Cummings robert@interjinn.com:
On Thu, 2009-05-07 at 21:33 +0100, David Gerard wrote:
I'm still looking forward to corporate readiness of MediaWiki, which for us basically means (1) good WYSIWYG
What's wrong with the FCKeditor extension?
It's promising but not really cooked to the standard I'm thinking of.
- d.
Not to mention it's totally broken since we got the new preprocessor.
On Thu, May 7, 2009 at 2:46 PM, David Gerard dgerard@gmail.com wrote:
2009/5/7 Robert Cummings robert@interjinn.com:
On Thu, 2009-05-07 at 21:33 +0100, David Gerard wrote:
I'm still looking forward to corporate readiness of MediaWiki, which for us basically means (1) good WYSIWYG
What's wrong with the FCKeditor extension?
It's promising but not really cooked to the standard I'm thinking of.
- d.
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
On Thu, 2009-05-07 at 14:48 -0600, Brian wrote:
Not to mention it's totally broken since we got the new preprocessor.
Working fine in MediaWiki 1.13.1 and 1.14.0. Which version has the new preprocessor?
Cheers, Rob.
El 5/7/09 1:55 PM, Robert Cummings escribió:
On Thu, 2009-05-07 at 14:48 -0600, Brian wrote:
Not to mention it's totally broken since we got the new preprocessor.
Working fine in MediaWiki 1.13.1 and 1.14.0. Which version has the new preprocessor?
1.12 and later.
-- brion
I'd be surprised if its been fixed, I believe I am subscribed to the bug report. A quick google should turn it up on their site.
On Thu, May 7, 2009 at 2:55 PM, Robert Cummings robert@interjinn.comwrote:
On Thu, 2009-05-07 at 14:48 -0600, Brian wrote:
Not to mention it's totally broken since we got the new preprocessor.
Working fine in MediaWiki 1.13.1 and 1.14.0. Which version has the new preprocessor?
Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Looks like there was some activity 2 months ago. I'll check if it works on 1.15a now since my users really like FCKeditor.
http://dev.fckeditor.net/ticket/2721
On Thu, May 7, 2009 at 2:57 PM, Brian Brian.Mingus@colorado.edu wrote:
I'd be surprised if its been fixed, I believe I am subscribed to the bug report. A quick google should turn it up on their site.
On Thu, May 7, 2009 at 2:55 PM, Robert Cummings robert@interjinn.comwrote:
On Thu, 2009-05-07 at 14:48 -0600, Brian wrote:
Not to mention it's totally broken since we got the new preprocessor.
Working fine in MediaWiki 1.13.1 and 1.14.0. Which version has the new preprocessor?
Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Looks like FCKeditor has been given a new chance at life! :)
WORKSFORME
On Thu, May 7, 2009 at 3:00 PM, Brian Brian.Mingus@colorado.edu wrote:
Looks like there was some activity 2 months ago. I'll check if it works on 1.15a now since my users really like FCKeditor.
http://dev.fckeditor.net/ticket/2721
On Thu, May 7, 2009 at 2:57 PM, Brian Brian.Mingus@colorado.edu wrote:
I'd be surprised if its been fixed, I believe I am subscribed to the bug report. A quick google should turn it up on their site.
On Thu, May 7, 2009 at 2:55 PM, Robert Cummings robert@interjinn.comwrote:
On Thu, 2009-05-07 at 14:48 -0600, Brian wrote:
Not to mention it's totally broken since we got the new preprocessor.
Working fine in MediaWiki 1.13.1 and 1.14.0. Which version has the new preprocessor?
Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
El 5/7/09 1:46 PM, David Gerard escribió:
2009/5/7 Robert Cummingsrobert@interjinn.com:
On Thu, 2009-05-07 at 21:33 +0100, David Gerard wrote:
I'm still looking forward to corporate readiness of MediaWiki, which for us basically means (1) good WYSIWYG
What's wrong with the FCKeditor extension?
It's promising but not really cooked to the standard I'm thinking of.
*nod*
It's much more promising now than I was afraid it was going to be a year or two ago, but there's a lot that still needs to be done (especially before we even consider it for sites like Wikimedia).
Some of that groundwork is going to be things like friendlier link, template, extension tag, table, and image editing that the usability initiative will be working on over the coming months. A WYSIWYG view only gets you so far if you have to switch to source view to actually edit anything. :)
These can be integrated into the existing editor and would be available to more advanced "basic editing" environments to make them suitable for all uses, not just the simplest pages.
-- brion
IMHO, the #1 usability need is an interactive table editor. I wish we would have FCKeditor's table editor alone. We don't need the rest of FCKeditor's functionality, but the table editor is the best I've ever worked with on a web page.
DanB
-----Original Message----- From: Brion Vibber
Some of that groundwork is going to be things like friendlier link, template, extension tag, table, and image editing that the usability initiative will be working on over the coming months...
On May 8, 2009, at 11:21 AM, Daniel Barrett wrote:
IMHO, the #1 usability need is an interactive table editor. I wish we would have FCKeditor's table editor alone. We don't need the rest of FCKeditor's functionality, but the table editor is the best I've ever worked with on a web page.
Our TableEdit extension isn't WYSIWYG, but it does make editing tables easier for our users. I need to package a new release; what we have linked from mediawiki.org is falling behind what we're using.
Jim
DanB
-----Original Message----- From: Brion Vibber
Some of that groundwork is going to be things like friendlier link, template, extension tag, table, and image editing that the usability initiative will be working on over the coming months...
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
===================================== Jim Hu Associate Professor Dept. of Biochemistry and Biophysics 2128 TAMU Texas A&M Univ. College Station, TX 77843-2128 979-862-4054
Thank you so much~! The WMF's implementation is a real PITA to configure.
On Thu, May 7, 2009 at 1:33 PM, Chris Reigrut chris@reigrut.net wrote:
I'd like to announce the first release of EzMwLucene. This project provides a simplified Lucene search to Mediawiki. It is designed to be easy to install, configure, and run. It provides real-time, multiple field indexing and searching as well as text indexing of standard attachment types (pdf, xls, doc, ppt, vsd). The server is a self contained Java application (no application server needed), and the client portion is a standard Mediawiki extension. It is currently in production on an internal site with over 1000 users running on Mediawiki 1.13.
https://sourceforge.net/projects/ezmwlucene/
I welcome all feedback: questions, suggestions and offers to help improve it!
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Thanks aside, it is such a PITA when developers choose to package tarballs the way you have. After opening tens of thousands of tarballs I can safely say that the "standard" way of doing it is to have a directory called ezmwlucene_1.0 inside ezmwlucene_1.0.tar. This means that you plop ezmwlucene_1.0.tar in mediawiki/extensions and then you untar it and your done.
What you have chosen to do is totally bizarre. If I do the standard thing I get client and server directories inside my extension directory and the client directory contains extensions/EzMwLucene. This is not exactly the "easy to install" solution I was imagining.
On Thu, May 7, 2009 at 2:37 PM, Brian Brian.Mingus@colorado.edu wrote:
Thank you so much~! The WMF's implementation is a real PITA to configure.
On Thu, May 7, 2009 at 1:33 PM, Chris Reigrut chris@reigrut.net wrote:
I'd like to announce the first release of EzMwLucene. This project provides a simplified Lucene search to Mediawiki. It is designed to be easy to install, configure, and run. It provides real-time, multiple field indexing and searching as well as text indexing of standard attachment types (pdf, xls, doc, ppt, vsd). The server is a self contained Java application (no application server needed), and the client portion is a standard Mediawiki extension. It is currently in production on an internal site with over 1000 users running on Mediawiki 1.13.
https://sourceforge.net/projects/ezmwlucene/
I welcome all feedback: questions, suggestions and offers to help improve it!
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
I think a demonstration of the directory structure a new user will end up with will be more clear:
/var/www/mediawiki/code/extensions/ezmwlucene/client/extensions/EzMwLucene
Of course I made the extensionsezmwlucene directory after I silently cursed to myself when I realized you had made the directory structure flat. It's not as bad as when a complicated software distribution does it, though.
On Thu, May 7, 2009 at 2:48 PM, Brian Brian.Mingus@colorado.edu wrote:
Thanks aside, it is such a PITA when developers choose to package tarballs the way you have. After opening tens of thousands of tarballs I can safely say that the "standard" way of doing it is to have a directory called ezmwlucene_1.0 inside ezmwlucene_1.0.tar. This means that you plop ezmwlucene_1.0.tar in mediawiki/extensions and then you untar it and your done.
What you have chosen to do is totally bizarre. If I do the standard thing I get client and server directories inside my extension directory and the client directory contains extensions/EzMwLucene. This is not exactly the "easy to install" solution I was imagining.
On Thu, May 7, 2009 at 2:37 PM, Brian Brian.Mingus@colorado.edu wrote:
Thank you so much~! The WMF's implementation is a real PITA to configure.
On Thu, May 7, 2009 at 1:33 PM, Chris Reigrut chris@reigrut.net wrote:
I'd like to announce the first release of EzMwLucene. This project provides a simplified Lucene search to Mediawiki. It is designed to be easy to install, configure, and run. It provides real-time, multiple field indexing and searching as well as text indexing of standard attachment types (pdf, xls, doc, ppt, vsd). The server is a self contained Java application (no application server needed), and the client portion is a standard Mediawiki extension. It is currently in production on an internal site with over 1000 users running on Mediawiki 1.13.
https://sourceforge.net/projects/ezmwlucene/
I welcome all feedback: questions, suggestions and offers to help improve it!
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
I'd like to announce the first release of EzMwLucene. This project provides a simplified Lucene search to Mediawiki. It is designed to be easy to install, configure, and run. It provides real-time, multiple field indexing and searching as well as text indexing of standard attachment types (pdf, xls, doc, ppt, vsd). The server is a self contained Java application (no application server needed), and the client portion is a standard Mediawiki extension. It is currently in production on an internal site with over 1000 users running on Mediawiki 1.13.
https://sourceforge.net/projects/ezmwlucene/
I welcome all feedback: questions, suggestions and offers to help improve it!
Does this require java 1.6? I'm getting an error trying to launch it:
Exception in thread "main" java.lang.UnsupportedClassVersionError: Bad version number in .class file at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
V/r,
Ryan Lane
Does this require java 1.6? I'm getting an error trying to launch it:
Exception in thread "main" java.lang.UnsupportedClassVersionError: Bad version number in .class file at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader. java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
Answering my own question... It works properly with java 1.6, so I'll update the wiki page to mention this requirement.
V/r,
Ryan Lane
I just about have this extension running. It sure would benefit from MWSearch's improved unicode handling:
*** WARNING: Funny characters in title SchrauwenD???HaeneVerstraetenEtAl07 ************************ 14000 row(s) processed ************************ 14100 row(s) processed ************************ 14200 row(s) processed *** WARNING: Funny characters in title SerinoGiovagnoliL??davas09 ************************ 14300 row(s) processed ************************ 14400 row(s) processed ************************ 14500 row(s) processed ************************ 14600 row(s) processed ************************ 14700 row(s) processed ************************ 14800 row(s) processed ************************ 14900 row(s) processed ************************ 15000 row(s) processed ************************ 15100 row(s) processed *** WARNING: Funny characters in title StruffertK??hrmannEngelhornEtAl09 ************************ 15200 row(s) processed ************************ 15300 row(s) processed *** WARNING: Funny characters in title TamosiunaiteAsfourW??rg??tter09 ************************ 15400 row(s) processed *** WARNING: Funny characters in title TanakaBalleineO???Doherty08 ************************ 15500 row(s) processed ************************ 15600 row(s) processed ************************ 15700 row(s) processed ************************ 15800 row(s) processed ************************ 15900 row(s) processed *** WARNING: Funny characters in title UrbanoLeznikLlin??s07 *** WARNING: Funny characters in title ValentinDickinsonO???Doherty07 ************************ 16000 row(s) processed ************************ 16100 row(s) processed *** WARNING: Funny characters in title VerstraetenSchrauwenD??HaeneEtAl07 ************************ 16200 row(s) processed ************************ 16300 row(s) processed ************************ 16400 row(s) processed ************************ 16500 row(s) processed ************************ 16600 row(s) processed ************************ 16700 row(s) processed *** WARNING: Funny characters in title WikiPapers/log/Kov????csMehler09 ************************ 16800 row(s) processed *** WARNING: Funny characters in title WikiPapers/log/SerinoGiovagnoliL??davas09 *** WARNING: Funny characters in title WikiPapers/log/SotoFunesGuzm????n-Garc????aEtAl09 *** WARNING: Funny characters in title WikiPapers/log/TanakaBalleineO???Doherty08 *** WARNING: Funny characters in title WikiPapers/log/ValentinDickinsonO???Doherty07 *** WARNING: Funny characters in title WikiPapers/log/WinklerH??denLadinigEtAl *** WARNING: Funny characters in title WinklerH??denLadinigEtAl ************************ 16900 row(s) processed ************************ 17000 row(s) processed ************************ 17100 row(s) processed ************************ 17200 row(s) processed ************************ 17300 row(s) processed ************************ 17400 row(s) processed ************************ 17500 row(s) processed *** WARNING: Funny characters in title BrouilletCond??BealEtAl99.pdf ************************ 17600 row(s) processed *** WARNING: Funny characters in title Carrillo-ReidTecuapetlaIb????ez-SandovalEtAl09.pdf *** WARNING: Funny characters in title CepedaWuAndr??EtAl07.pdf
On Thu, May 7, 2009 at 1:33 PM, Chris Reigrut chris@reigrut.net wrote:
I'd like to announce the first release of EzMwLucene. This project provides a simplified Lucene search to Mediawiki. It is designed to be easy to install, configure, and run. It provides real-time, multiple field indexing and searching as well as text indexing of standard attachment types (pdf, xls, doc, ppt, vsd). The server is a self contained Java application (no application server needed), and the client portion is a standard Mediawiki extension. It is currently in production on an internal site with over 1000 users running on Mediawiki 1.13.
https://sourceforge.net/projects/ezmwlucene/
I welcome all feedback: questions, suggestions and offers to help improve it!
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
service.sh has funky windows newlines that simply don't work on linux. I used the ubuntu package tofrodos, which contains the program fromdos, which cleaned it up for me.
http://packages.ubuntu.com/jaunty/tofrodos
Before:
mingus@grey:/var/www/ccnlab/extensions/EzMwLucene/server$ sudo sh service.sh : not found 2: : not found 33: : not found 37: Usage: service.sh {start|stop|restart|check}
After:
mingus@grey:/var/www/ccnlab/extensions/EzMwLucene/server$ sh service.sh Usage: service.sh {start|stop|restart|check}
On Fri, May 8, 2009 at 3:09 PM, Brian Brian.Mingus@colorado.edu wrote:
I just about have this extension running. It sure would benefit from MWSearch's improved unicode handling:
*** WARNING: Funny characters in title SchrauwenD???HaeneVerstraetenEtAl07 ************************ 14000 row(s) processed ************************ 14100 row(s) processed ************************ 14200 row(s) processed *** WARNING: Funny characters in title SerinoGiovagnoliL??davas09 ************************ 14300 row(s) processed ************************ 14400 row(s) processed ************************ 14500 row(s) processed ************************ 14600 row(s) processed ************************ 14700 row(s) processed ************************ 14800 row(s) processed ************************ 14900 row(s) processed ************************ 15000 row(s) processed ************************ 15100 row(s) processed *** WARNING: Funny characters in title StruffertK??hrmannEngelhornEtAl09 ************************ 15200 row(s) processed ************************ 15300 row(s) processed *** WARNING: Funny characters in title TamosiunaiteAsfourW??rg??tter09 ************************ 15400 row(s) processed *** WARNING: Funny characters in title TanakaBalleineO???Doherty08 ************************ 15500 row(s) processed ************************ 15600 row(s) processed ************************ 15700 row(s) processed ************************ 15800 row(s) processed ************************ 15900 row(s) processed *** WARNING: Funny characters in title UrbanoLeznikLlin??s07 *** WARNING: Funny characters in title ValentinDickinsonO???Doherty07 ************************ 16000 row(s) processed ************************ 16100 row(s) processed *** WARNING: Funny characters in title VerstraetenSchrauwenD??HaeneEtAl07 ************************ 16200 row(s) processed ************************ 16300 row(s) processed ************************ 16400 row(s) processed ************************ 16500 row(s) processed ************************ 16600 row(s) processed ************************ 16700 row(s) processed *** WARNING: Funny characters in title WikiPapers/log/Kov????csMehler09 ************************ 16800 row(s) processed *** WARNING: Funny characters in title WikiPapers/log/SerinoGiovagnoliL??davas09 *** WARNING: Funny characters in title WikiPapers/log/SotoFunesGuzm????n-Garc????aEtAl09 *** WARNING: Funny characters in title WikiPapers/log/TanakaBalleineO???Doherty08 *** WARNING: Funny characters in title WikiPapers/log/ValentinDickinsonO???Doherty07 *** WARNING: Funny characters in title WikiPapers/log/WinklerH??denLadinigEtAl *** WARNING: Funny characters in title WinklerH??denLadinigEtAl ************************ 16900 row(s) processed ************************ 17000 row(s) processed ************************ 17100 row(s) processed ************************ 17200 row(s) processed ************************ 17300 row(s) processed ************************ 17400 row(s) processed ************************ 17500 row(s) processed *** WARNING: Funny characters in title BrouilletCond??BealEtAl99.pdf ************************ 17600 row(s) processed *** WARNING: Funny characters in title Carrillo-ReidTecuapetlaIb????ez-SandovalEtAl09.pdf *** WARNING: Funny characters in title CepedaWuAndr??EtAl07.pdf
On Thu, May 7, 2009 at 1:33 PM, Chris Reigrut chris@reigrut.net wrote:
I'd like to announce the first release of EzMwLucene. This project provides a simplified Lucene search to Mediawiki. It is designed to be easy to install, configure, and run. It provides real-time, multiple field indexing and searching as well as text indexing of standard attachment types (pdf, xls, doc, ppt, vsd). The server is a self contained Java application (no application server needed), and the client portion is a standard Mediawiki extension. It is currently in production on an internal site with over 1000 users running on Mediawiki 1.13.
https://sourceforge.net/projects/ezmwlucene/
I welcome all feedback: questions, suggestions and offers to help improve it!
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
service.sh has funky windows newlines that simply don't work on linux. I used the ubuntu package tofrodos, which contains the program fromdos, which cleaned it up for me.
dos2unix also works, if you are on a RHEL system.
Have you had problems uploading new files? I'm getting a php crash on it. I fixed the issue with the following patch:
--- EzMwLuceneIndexer.php.old 2009-05-08 16:26:28.000000000 -0500 +++ EzMwLuceneIndexer.php 2009-05-08 16:26:00.000000000 -0500 @@ -38,7 +38,7 @@ $xml .= "<content><![CDATA[{$revision->getRawText()}]]></content>"; /* If the article is in the Image namespace, add the file url */ if ($article->getTitle()->getNamespace()==6) { - $file = wfFindFile($article->getTitle()); + $file = wfFindFile($article->getTitle(),false,0,true); $xml .= "<attachment><![CDATA[{$file->getFullUrl()}]]></attachment>"; } $xml .= '</article>';
The php error I was getting was:
PHP Fatal error: Call to a member function getFullUrl() on a non-object in /var/www/html/wiki/extensions/EzMwLucene/EzMwLuceneIndexer.php on line 42, referer: https://<servername>/wiki/index.php/Special:Upload
The extension doesn't currently work with wikis that are using img_auth.php either.
V/r,
Ryan Lane
I must have missed a configuration step because MediaWiki is still defaulting to the mysql search. I've included EzMwLucene.php in my LocalSettings.php, and managed to get the server started manually (service.sh kept failing), and the loader does seem to do some indexing, but other than that nothing.
My impression so far is that even if you polish this up it will be just as difficult to configure as MWSearch. The only added benefit on top of it for me right now is pdf indexing. I've got thousands and thousands of PDFs on my wiki.
:.../EzMwLucene/server# /usr/lib/jvm/java-6-sun-1.6.0.10/jre/bin/java -cp "/var/www/ccnlab/extensions/EzMwLucene/server/ezmwlucene.jar:/var/www/ccnlab/extensions/EzMwLucene/server/lib/jetty-6.1.14.jar:/var/www/ccnlab/extensions/EzMwLucene/server/lib/jetty-util-6.1.14.jar:/var/www/ccnlab/extensions/EzMwLucene/server/lib/servlet-api-2.5-6.1.14.jar:/var/www/ccnlab/extensions/EzMwLucene/server/lib/commons-codec-1.3.jar:/var/www/ccnlab/extensions/EzMwLucene/server/lib/commons-httpclient-3.1.jar:/var/www/ccnlab/extensions/EzMwLucene/server/lib/commons-logging.jar:/var/www/ccnlab/extensions/EzMwLucene/server/lib/FontBox-0.1.0-dev.jar:/var/www/ccnlab/extensions/EzMwLucene/server/lib/lucene-core-2.4.0.jar:/var/www/ccnlab/extensions/EzMwLucene/server/lib/lucene-highlighter-2.4.0.jar:/var/www/ccnlab/extensions/EzMwLucene/server/lib/PDFBox-0.7.3.jar:/var/www/ccnlab/extensions/EzMwLucene/server/lib/poi-3.5-beta3-20080926.jar:/var/www/ccnlab/extensions/EzMwLucene/server/lib/poi-scratchpad-3.5-beta3-20080926.jar" net.sourceforge.ezmwlucene.service.EzMwLuceneService Starting EzMwLucene server... 2009-05-08 16:22:48.039::INFO: Logging to STDERR via org.mortbay.log.StdErrLog 2009-05-08 16:22:48.259::INFO: jetty-6.1.14 2009-05-08 16:22:48.498::INFO: Started SocketConnector@0.0.0.0:8080 EzMwLucene started!
On Fri, May 8, 2009 at 3:31 PM, Lane, Ryan Ryan.Lane@ocean.navo.navy.milwrote:
service.sh has funky windows newlines that simply don't work on linux. I used the ubuntu package tofrodos, which contains the program fromdos, which cleaned it up for me.
dos2unix also works, if you are on a RHEL system.
Have you had problems uploading new files? I'm getting a php crash on it. I fixed the issue with the following patch:
--- EzMwLuceneIndexer.php.old 2009-05-08 16:26:28.000000000 -0500 +++ EzMwLuceneIndexer.php 2009-05-08 16:26:00.000000000 -0500 @@ -38,7 +38,7 @@ $xml .= "<content><![CDATA[{$revision->getRawText()}]]></content>"; /* If the article is in the Image namespace, add the file url */ if ($article->getTitle()->getNamespace()==6) {
$file = wfFindFile($article->getTitle());
$file =wfFindFile($article->getTitle(),false,0,true); $xml .= "<attachment><![CDATA[{$file->getFullUrl()}]]></attachment>"; } $xml .= '</article>';
The php error I was getting was:
PHP Fatal error: Call to a member function getFullUrl() on a non-object in /var/www/html/wiki/extensions/EzMwLucene/EzMwLuceneIndexer.php on line 42, referer: https://<servername>/wiki/index.php/Special:Upload
The extension doesn't currently work with wikis that are using img_auth.php either.
V/r,
Ryan Lane
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Ryan, could I have a brief overview of your config?
On Fri, May 8, 2009 at 3:31 PM, Lane, Ryan Ryan.Lane@ocean.navo.navy.milwrote:
service.sh has funky windows newlines that simply don't work on linux. I used the ubuntu package tofrodos, which contains the program fromdos, which cleaned it up for me.
dos2unix also works, if you are on a RHEL system.
Have you had problems uploading new files? I'm getting a php crash on it. I fixed the issue with the following patch:
--- EzMwLuceneIndexer.php.old 2009-05-08 16:26:28.000000000 -0500 +++ EzMwLuceneIndexer.php 2009-05-08 16:26:00.000000000 -0500 @@ -38,7 +38,7 @@ $xml .= "<content><![CDATA[{$revision->getRawText()}]]></content>"; /* If the article is in the Image namespace, add the file url */ if ($article->getTitle()->getNamespace()==6) {
$file = wfFindFile($article->getTitle());
$file =wfFindFile($article->getTitle(),false,0,true); $xml .= "<attachment><![CDATA[{$file->getFullUrl()}]]></attachment>"; } $xml .= '</article>';
The php error I was getting was:
PHP Fatal error: Call to a member function getFullUrl() on a non-object in /var/www/html/wiki/extensions/EzMwLucene/EzMwLuceneIndexer.php on line 42, referer: https://<servername>/wiki/index.php/Special:Upload
The extension doesn't currently work with wikis that are using img_auth.php either.
V/r,
Ryan Lane
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Ryan, could I have a brief overview of your config?
I added this to the wiki discussion page, under one of your comments:
http://www.mediawiki.org/wiki/Extension_talk:EzMwLucene#service.sh_always_fa ils_.28with_FAIL.29
I changed stuff as to not fully disclose how my server is configured; but, the config will still work.
V/r,
Ryan Lane
Thanks Ryan. Chris also fixed service.sh for Ubuntu (it only worked on RHEL). It does have a syntax or condition error still but it does start up the service and return OK now.
On Mon, May 11, 2009 at 8:48 AM, Lane, Ryan Ryan.Lane@ocean.navo.navy.milwrote:
Ryan, could I have a brief overview of your config?
I added this to the wiki discussion page, under one of your comments:
http://www.mediawiki.org/wiki/Extension_talk:EzMwLucene#service.sh_always_fa ils_.28with_FAIL.29
I changed stuff as to not fully disclose how my server is configured; but, the config will still work.
V/r,
Ryan Lane
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
mediawiki-l@lists.wikimedia.org