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 }
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
John Moorhouse wrote:
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.
Change:
wfStrencode($blah) to $db->strencode($blah) (or better $db->addQuotes($blah); note this includes the outer quotes)
wfQuery($blah, DB_WRITE, $fname); to $db->query($blah, $fname);
(or better use the various query-builder functions, which will tend to be safer due to applying propr quoting always, and may be more portable for not-quite-standard constructs).
These long-, long-, long-obsolete functions have been removed because they are unreliable -- it's hard to know which database object they will be sent to, and that's generally icky.
You get a Database object from wfGetDB(DB_MASTER) or wfGetDB(DB_SLAVE). Writes must go to the master *only*. Many read operations can be taken from a slave, which will spread load away from your primary server in a load-balancing replication setup. (On a single server they will both return the same connection.)
- -- brion vibber (brion @ pobox.com)
Brion- many thanks is now working,
I've used the db->addQuotes, I will see what I can learn on the query builder functions to see if I can remove the sql bits as well.
Thanks for this.
John
Brion Vibber wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
John Moorhouse wrote:
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.
Change:
wfStrencode($blah) to $db->strencode($blah) (or better $db->addQuotes($blah); note this includes the outer quotes)
wfQuery($blah, DB_WRITE, $fname); to $db->query($blah, $fname);
(or better use the various query-builder functions, which will tend to be safer due to applying propr quoting always, and may be more portable for not-quite-standard constructs).
These long-, long-, long-obsolete functions have been removed because they are unreliable -- it's hard to know which database object they will be sent to, and that's generally icky.
You get a Database object from wfGetDB(DB_MASTER) or wfGetDB(DB_SLAVE). Writes must go to the master *only*. Many read operations can be taken from a slave, which will spread load away from your primary server in a load-balancing replication setup. (On a single server they will both return the same connection.)
Hi,
I have noticed some wikis have upgraded to 1.8.3 instead of to 1.9 - is there any specific reason why one may not wish to upgrade to the new branch (slow performance on shared servers, for instance)? Currently I am running 1.8.2. Also, will there be additional fixes to 1.9 within the coming weeks, i.e. should I hold off on upgrading for awhile?
Thanks,
Sven
--------------------------------- Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. Check it out.
On 22/01/07, Metaspheres metaspheres@yahoo.com wrote:
I have noticed some wikis have upgraded to 1.8.3 instead of to 1.9 - is there any specific reason why one may not wish to upgrade to the new branch (slow performance on shared servers, for instance)? Currently I am running 1.8.2. Also, will there be additional fixes to 1.9 within the coming weeks, i.e. should I hold off on upgrading for awhile?
I can't think of any particular reason people would want to hold off, except for the fact that historically, our .0 releases from 1.5.0 through 1.8.0 have had bugs in. 1.9.0 should start off a new chain of exceptions; we had a couple release candidates which underwent a lot of volunteer testing (thanks!) before the main 1.9.0 release, and it's proven to be pretty stable, so far.
I heard a quiet mutter from our release manager that 1.9.1 might be coming soon, but that was only a quick thing, and I may well misremember. Any road, there's no point in holding off upgrading to 1.9.0 now, if only to get the database updates out of the way and make a quick and painless upgrade to 1.9.1 possible.
Rob Church
I think if people upgrade from RPM via YUM, they'll be on 1.8.3 now. Mine just recently upgraded itself.
HTH
Chandler Bing
On 1/22/07, Metaspheres metaspheres@yahoo.com wrote:
Hi,
I have noticed some wikis have upgraded to 1.8.3 instead of to 1.9 - is there any specific reason why one may not wish to upgrade to the new branch (slow performance on shared servers, for instance)? Currently I am running 1.8.2. Also, will there be additional fixes to 1.9 within the coming weeks, i.e. should I hold off on upgrading for awhile?
Thanks,
Sven
Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. Check it out. _______________________________________________ MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
mediawiki-l@lists.wikimedia.org