Page MenuHomePhabricator

URL links to books in the ISBN are not being constructed properly
Open, Needs TriagePublic

Description

Overall, the extension has been working well, although a new bug has
arisen: URL links to books in the ISBN are not being constructed properly, so that CAZypedia readers are not directed to the proper book entry. See the link under the Stick and Williams reference at the bottom of the page here:

http://www.cazypedia.org/index.php/Help:References

This should point here: http://isbndb.com/book/carbohydrates_a16 , but instead the misformed link takes you to a default page.

Event Timeline

The bug seems to be related to caching of incorrect keys. If I bypass the cache by commenting out line 440 in BiblioPlus.body.php:

//$res = $cache->get( $cacheKey )

Then it will run through the isbnDbQueryOne function and output the expected results.

The cache of these keys seems to be unaffected by manually purging the cache by ?action=purge

Thanks for posting. Is there anything else you need from me at this moment Alex (@Ahvca) or are you able to continue to debug this on your own?

I've managed to reproduce this bug consistently and resolve it by purging the redis cache. To purge the cache, I login to the server through a shell and run $ redis-cli flushall

Sadly we are not running Redis on the cazypedia.org server. This must be getting stuck elsewhere too.

I've found a small illogical code setup, as the TTL on the cache is refreshed on every page load irrespective of the results coming from the cache or directly from the ISBNdb. As such, if, for whatever reason, an ISBNdb record is cached wrongly, it will basically persist in the cache forever if the page is loaded at least once every 24 hours.

in BiblioPlus.body.php from line 435:

	function isbnDbQuery( $isbns ) {
		$result = array();
		$cache = wfGetMainCache();
		
		foreach ( $isbns as $isbn ) {
			$cacheKey = wfMemckey( 'Biblio', $isbn );
			//$cache->delete($cacheKey);
			$res = $cache->get( $cacheKey );
			if ( $res ) {
				wfDebug( "Biblio cache hit $cacheKey\n" );
			} else {
				wfDebug( "Biblio cache miss $cacheKey\n" );
				$res = $this->isbnDbQueryOne( $isbn );
			}
			$cache->set( $cacheKey, $res, CACHE_TTL );
			$result["$isbn"] = $res;
		}
		return $result;
	}

Should be changed to:

	function isbnDbQuery( $isbns ) {
		$result = array();
		$cache = wfGetMainCache();
		
		foreach ( $isbns as $isbn ) {
			$cacheKey = wfMemckey( 'Biblio', $isbn );
			//$cache->delete($cacheKey);
			$res = $cache->get( $cacheKey );
			if ( $res ) {
				wfDebug( "Biblio cache hit $cacheKey\n" );
			} else {
				wfDebug( "Biblio cache miss $cacheKey\n" );
				$res = $this->isbnDbQueryOne( $isbn );
				$cache->set( $cacheKey, $res, CACHE_TTL );
			}
			$result["$isbn"] = $res;
		}
		return $result;
	}

@Ahvca: Thanks for taking a look at the code!

You are very welcome to use developer access to submit the proposed code changes as a Git branch directly into Gerrit which makes it easier to review them quickly and provide feedback.
If you don't want to set up Git/Gerrit, you can also use the Gerrit Patch Uploader. Thanks again!

@Ahvca were you able to confirm that this fix works in testing?

@vtingey Yes, this code change is working. For it to take immediate effect the servers cache will have to be flushed, otherwise the fix will work once the cache expires (default is 24 hours).

@Ahvca I implemented your change on cazypedia.org, restarted the webserver and tried clearing the cache using this url:
https://www.cazypedia.org/index.php/Help:References?action=purge

The fix did not work. The link is still broken:
http://isbndb.com/d/book/.html

@vtingey The ?action=purge does not flush the redis or memcache (or whichever cache that CAZypedia is using).

In my local environment mediawiki use redis as default, to clear it I have to I login to the server through a shell and run $ redis-cli flushall.

@Ahvca As mentioned previously, the cazypedia server does not run redis. You should reconfigure your development environment to exclude redis. We run simple mysql, php, and apache.

Using the special version page, compare your development environment and cazypedia.org. The two pages should be very similar and you should disable anything extra if possible:
https://www.cazypedia.org/index.php/Special:Version

Bonus points for configuring your Vagrant box to match current cazypedia AND being able to share it with other developers!

I'll need the output of a php info() to configure my local server to match that of the CAZypedia server. In any case, this should resolve itself 24 hours after the fix have been implemented if the default TTL for BiblioPlus extension haven't been modified. Also it would be useful for me to get an user account for CAZypedia, which I'll need to create content for my research anyway.

@vtingey If the fix is still implemented, it seems like some modifications have been done to the BiblioPlus extension on CAZypedia. Can you please share the following two files with me:

/extensions/BiblioPlus/BiblioPlus.php
/extensions/BiblioPlus/BiblioPlus.body.php

(In general I'd recommend to discuss and review proposed code changes in Gerrit instead of sending source code files around...)

Hi @Ahvca,

I have shared the cazypedia php info as a pdf document and the BiblioPlus files via UBC Workspace just like I had previously shared the LocalSettings.php file.

Hi @Ahvca ,

Any update on your progress?

Thanks!

Hi @vtingey The BiblioPlus extension is working with the small patch, provided that the cache on the server gets flushed - There is a lot of different caches, mediawiki specific and server specific, that all have to be cleared. I don't have the appropriate server knowledge to be able to track this down. I think this issue should be created under a new and different ticket, since the problem is not with the Biblioplus extension itself.

@Ahvca I will schedule a reboot of the cazypedia server which should flush any caches to confirm that your patch works and let you know.

@Ahvca I did the following and was still not able to make the problem go away. I really feel this is not a caching issue.

  1. a full reboot of the server.
  1. disabled caching and restarted the web server again:
## Completely disable caching, for testing only - HB
# See http://www.mediawiki.org/wiki/Manual:Configuration_settings#Cache
$wgEnableParserCache = false;
$wgCachePages = false;
$wgMainCacheType = CACHE_NONE;
  1. adding ?action=purge to the URL.
  1. looked in the file cache dir to manually clear it but there were no files present there.

Please let me know if there is anything else I can do.

References:
https://www.mediawiki.org/wiki/Manual:$wgMainCacheType
https://techwelkin.com/tips-purging-mediawiki-file-cache-pages
https://www.mediawiki.org/wiki/Manual:Purge
https://www.mediawiki.org/wiki/Manual:MediaWiki_architecture#Caching
https://www.mediawiki.org/wiki/Manual:File_cache

@vtingey I forced the bug in my local environment and got that value stored in the cache. Following the same steps as you did, did NOT clear the cache - setting those variables and restarting my server did not solve it. In my case it's the Redis cache that I had to flush. CAZypedia don't use this cache system, and I have no knowledge about which system it would then use or how to flush it.

The extension used to work without trouble, and it's working without trouble in my local environment.

Another way to test this on CAZypedia would be to create a new entry with a reference to the ISBNdb and see if the new entry is created correctly. If that should not work, then if you can setup my local environment identical to the CAZypedia I can try to resolve this issue specifically for CAZypedia.