 |
 |
Will, I'm not sure how widely used LibStats is at this point (we stopped using it here several years ago in favor of a custom plug-in we built internally for our CMS), but it certainly seems worthwhile to share your work in modernizing it for the benefit of others who still rely on it. Perhaps the best strategy is to fork the existing GitHub repo for the project, update it with your code, and submit a PR. If the existing GitHub repo is still active, then your PR will be accepted and all will be well. If not, at least your fork will be out there for those who might go hunting. - Demian -----Original Message----- From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of Will Martin Sent: Thursday, September 01, 2016 12:53 PM To: [log in to unmask] Subject: Re: [CODE4LIB] LibStats, PEAR, PHP 7 Well, after spending absolutely aaaages trying to make PEAR work and failing, I finally bit the bullet and rewrote LibStats to use PDO instead. It took 15 solid hours last Saturday, but it's been working smoothly all week. Hopefully that will prevent a recurrence of similar problems for some time. Since PDO is a native PHP interface, I suspect it's here for the long haul. I'd be happy to contribute this back to the community, but I don't know where to send it. The original code repository on code.google.com resembles a ghost town, complete with tumbleweeds, creaky half-hung doors, and a mournful wind whistling through the desolate ruins of a once vibrant project. I did find a fork on GitHub, but it too hasn't been updated in 4 years. I could just publish my own fork on github, but I worry that it would soon join the other abandoned versions littering the digital landscape, because I honestly don't have a whole lot of time to devote to maintaining it. Not that it needs much maintenance. It does what it does pretty well. It's got a few warts, notably the completely unhelpful white screen of death if you misspell your password. But aside from the PEAR issue, there's nothing I can see that's so critical that it really needs addressing. Will Martin On 2016-08-25 14:34, Demian Katz wrote: > It's possible that the problem is that updating PHP also updated > PEAR::DB, and it bumped up to a version that doesn't get along with > LibStats. Do you happen to have any record of the PEAR versions that > were running on your server before the upgrade so that you can compare > them against current versions? It might be possible to simply > downgrade the dependency to restore previous functionality (though of > course you then run the risk of running into some other > incompatibility between an old version of the library and PHP 7... > it's never easy!). > > For what it's worth, users running very old versions of VuFind (from > before it switched from PEAR::DB_DataObject to Zend\Db as its > abstraction layer) occasionally complain about breaks after upgrading > PHP, and the solution usually turns out to be "downgrade to a specific > old version of PEAR::DB_DataObject." I'm not sure if this also applies > to plain old PEAR::DB, but it's worth investigating if you have the > option. > > Good luck! > > - Demian > > -----Original Message----- > From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of > Will Martin > Sent: Thursday, August 25, 2016 12:52 PM > To: [log in to unmask] > Subject: [CODE4LIB] LibStats, PEAR, PHP 7 > > All, > > A recent server upgrade seems to have broken our installation of > LibStats. It appears that the database abstraction layer it uses, > PEAR::DB, is not working correctly. Once instantiated, it's supposed > to have methods like getOne() and getAll() that execute a SQL query > and retrieve the results; but keeps complaining that these are > undefined. > > I'm pretty sure this has something to do with the fact that the > upgrade > -- to Ubuntu 16.04.1 LTS -- installed PHP 7, up from 5.6. According > to the PEAR web site, PEAR::DB is supposed to be compatible with PHP 7 > despite being ancient and crufty, but it's not working. > > Anyone have any insight on how to get PEAR::DB to play nice in its new > environment? Because the other option would be going in and rewriting > all the database queries to use a more modern database abstraction > layer. Probably PDO. That's certainly doable, but it'd be quite a > pretty fair chunk of work, and in the meantime our reference and > access services staff can't log their stats normally. > > Will Martin