Hi
Symptom: The search engine works for title search but gives no result for any text search. The words of the query appears correctly in the "For query" at the top and in the form textarea after the namespaces boxes.
Environnment: # MediaWiki: 1.6alpha # PHP: 4.4.2 (cgi) # MySQL: 4.0.26
Explanation: During install or upgrade, the value of the DBtype variable was not set correctly.
Solution: Edit the LocalSettings.php file Find the $wgDBtype = ""; Type between the hyphens the type of your database: example: $wgDBtype = "mysql";
Hope this helps. Thank you to Brion for (re)giving the steps of debugging :-)
François
___________________________ The FAQ: http://meta.wikimedia.org/wiki/FAQ The newsgroups: http://blog.gmane.org/gmane.org.wikimedia.mediawiki The archive: http://search.gmane.org/?group=gmane.org.wikimedia.mediawiki User Guide: http://meta.wikimedia.org/wiki/MediaWiki_User%27s_Guide:_Installation CVS: http://cvs.sourceforge.net/viewcvs.py/wikipedia/
FxParlant wrote:
Symptom: The search engine works for title search but gives no result for any text search. The words of the query appears correctly in the "For query" at the top and in the form textarea after the namespaces boxes.
Environnment: # MediaWiki: 1.6alpha
You're way behind. Update to current code.
# PHP: 4.4.2 (cgi) # MySQL: 4.0.26
Explanation: During install or upgrade, the value of the DBtype variable was not set correctly.
1) Upgrade to current code. 2) Try to reproduce this issue.
-- brion vibber (brion @ pobox.com)
Good Afternoon MediaWiki Fans:
It appears from the source changes from 1.6.2 to 1.6.3 that there are important database table changes. Is this just for MySQL 5.0 support, or are these real database table changes that will take place during the run of the maintenance/update.php script ?
--Hiram
Hiram Clawson wrote:
Good Afternoon MediaWiki Fans:
It appears from the source changes from 1.6.2 to 1.6.3 that there are important database table changes.
There are no differences at all, no.
Some early versions of MySQL 4.0 didn't accept the 'ENGINE' parameter on CREATE TABLE statements. It's been changed back to 'TYPE' for improved compatibility. (Apparently it was changed to 'ENGINE' because some versions of the experimental MySQL 5.1 had removed the 'TYPE' keyword, a change which has since been reverted.)
-- brion vibber (brion @ pobox.com)
Good Afternoon Captcha Fans:
I discovered an interesting situation with the login Captcha business here today.
If I have anonymous users excluding from reading anything: $wgGroupPermissions['*' ]['read'] = false;
When they go to the create account page, they don't have permission to read the Captcha png image and it doesn't show up on the login page. Everything else is there for the Captcha entry, but since there is no image to view, it is unknown what to enter into the verify entry box.
Is there some way to allow anonymous users to read only this one bit that the img src URL references: img src="/index.php?title=Special:Captcha/image&wpCaptchaId=696369 457"
--Hiram
On 4/12/06, Hiram Clawson hiram@soe.ucsc.edu wrote:
Is there some way to allow anonymous users to read only this one bit that the img src URL references: img src="/index.php?title=Special:Captcha/image&wpCaptchaId=696369 457"
Don't know for sure, but my guess would be to add "Special:Captcha" to $wgWhitelistRead in LocalSettings.php
- Cameron
Yes, that works, thanks Cameron:
$wgWhitelistRead = array( "Main Page", "Special:Userlogin", "Special:Captcha/image" );
--Hiram
M. Cameron Jones wrote:
On 4/12/06, Hiram Clawson hiram@soe.ucsc.edu wrote:
Is there some way to allow anonymous users to read only this one bit that the img src URL references: img src="/index.php?title=Special:Captcha/image&wpCaptchaId=696369 457"
Don't know for sure, but my guess would be to add "Special:Captcha" to $wgWhitelistRead in LocalSettings.php
- Cameron
mediawiki-l@lists.wikimedia.org