e-Pubs & publication date

I don't remember if the "rc" version has it but the dev version will periodically check for updates using cron.

GinaF: Did the automatic scheduled update work? Is that why you closed your issue? Do you have to do anything to make the automatic schedule update work?

Looks like the auto syncing and cron job can be set in admin/config/content/biblio under PREFERENCES ->Pubmed.

Did you check the DRUPAL report logs for clues?

Good, that tells me exactly what the problem is.

I've just pushed the fix.. http://drupalcode.org/project/biblio.git/commit/abdb0de

(it will be in the next -dev build)

can you try grabbing the current Nov 2nd 2012 dev release, install it, update.php, and then run the -DEV that rjermone is suggesting? I know that the biblio_pubmed_grant_info table was created fine with the current -DEV on Nov. 2nd.

I looked in the biblio.install file, both the Nov. 25 development and the current one I am using, and I don't see a call to create a new table of 'biblio_pubmed_grant_info' anywhere. But then again I am not a Drupal module developer expert. I have no idea how my 'biblio_pubmed_grant_info' table got created with the development version I am using, but it had to come from this Drupal biblio webpage. Nonetheless, here is the output of my "show create table biblio_pubmed_grant_info":

CREATE TABLE `biblio_pubmed_grant_info` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `nid` int(11) NOT NULL,
  `biblio_pubmed_id` int(11) NOT NULL,
  `grantid` varchar(255) DEFAULT NULL,
  `acronym` varchar(2) DEFAULT NULL,
  `agency` varchar(255) DEFAULT NULL,
  `country` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=13165 DEFAULT CHARSET=utf8

I believe if you can create that table on your Drupal database on your MySQL server, then that should resolve the issue of not being able to find this table. I believe that the "AUTO_INCREMENT=13165" is unique to my DB server, so I think you can exclude that from the SQL query. If it does resolve it, then I am assuming we need to put this table creation in the biblio.install file so that it will create this table (if not exists) for future users. Inputs? suggestions? comments?

As far as I know regarding the epub date, it has not been implemented yet. It is something I do need, but for now, I have my users entering it by hand. :( Perhaps I will get around to figuring it out by the end of the year, but at the moment, this is not a high priority for my needs.

Regarding the first error

biblio_pm module

Update #7004
Failed: DatabaseSchemaObjectExistsException: Table biblio_pubmed_grant_info already exists. in DatabaseSchema->createTable() (line 657 of /u01/www/vhosts/www-test.cir.ed.ac.uk/httpdocs/includes/database/schema.inc).

This is happening because you manually created the biblio_pubmed_grant_info table as I told you to, but in Drupal (or Biblio), it has no record of a "biblio_pubmed_grant_info" table existing or what its version is, therefore it tries to create it, but obviously you created it. it's nothing major, but we will need to find out where to tell Drupal (or Biblio) that the biblio_pubmed_grant_info table has been created and that its table version is #7004 to shut it up. I will see if I can dig around this week to find this for you as it would help me learn more about the development of this module, as well.

Regarding the below error:

PDOException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'vid' cannot be null: INSERT INTO {biblio_keyword} (kid, vid, nid) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2); Array ( [:db_insert_placeholder_0] => 1 [:db_insert_placeholder_1] => [:db_insert_placeholder_2] => 4 ) in biblio_insert_keywords() (line 176 of /..../www-test.cir.ed.ac.uk/httpdocs/sites/all/modules/biblio/includes/biblio.keywords.inc).

Does that get triggered when you are trying to import from Pubmed? It seems like it fails to add a new keyword! So if you are trying to import or add new entries in Biblio, particularly in regards to the keyword, then it is *not* being added to the keywords list. Be aware of this if you find yourself scratching your head wondering why keywords are not being found. :(

Which Biblio development version are you using? Do you have the date or version number? This is why I am scared to keep updating to the most recent development versions. :(

These errors below, which is hard to say, could be related to other modules and may not be Biblio's fault. Or it could be Biblio's fault where it is trying to pass certain values to other modules, in this case according to your log, the common and node modules that are built into Drupal. That would need more debugging. Basically something is not passing the correct date values to Drupal and it is not liking it! It is as if I am asking for your name, but you are giving me a buch of numbers.

    Warning: date_format() expects parameter 1 to be DateTime, boolean given in format_date() (line 1951 of /u01/www/vhosts/www-test.cir.ed.ac.uk/httpdocs/includes/common.inc).

    Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (line 1941 of /u01/www/vhosts/www-test.cir.ed.ac.uk/httpdocs/includes/common.inc).

    tice: Undefined property: stdClass::$created in node_object_prepare() (line 954 of /u01/www/vhosts/www-test.cir.ed.ac.uk/httpdocs/modules/node/node.module).

biblio_pm module

Update #7004
Failed: DatabaseSchemaObjectExistsException: Table biblio_pubmed_grant_info already exists. in DatabaseSchema->createTable() (line 657 of /u01/www/vhosts/www-test.cir.ed.ac.uk/httpdocs/includes/database/schema.inc).

The table creation code for 'biblio_pubmed_grant_info' is located in modules/pubmed/biblio_pm.install. Update #7004 calls to create that table. It looks fine for me.

"SELECT * FROM system WHERE name='biblio' AND type='module'"

What is your schema_version show? Mine is at 7022. I am just curious.

There was a new 7.x-Dec. 9th dev just released. Maybe you can try dropping that 'biblio_pubmed_grant_info' table and try running update.php with this newer Dec. 9th version. You shouldn't lose anything valuable, I hope, by dropping that 'biblio_pubmed_grant_info' table since it just pulls in grant info from Pubmed. If you're not sure, then backup, backup, backup!

Why don't you just disable the Biblio-PubMed module for the time being. That should get rid of that error.

The other thing you want to make very sure of is that you don't have multiple versions of the Biblio module in different directories under the same Drupal directory tree. I've seen this trip people up more than once, and it could explain the issue with db table not being created.

I think rjerome is right. Gina: you mentioned that in post #22, you are using 7.x-1.0-rc4+37-dev, but I am specifically and only talking about and using the development version (pink colored box on Biblio main page). Maybe you are mixing and matching the different versions (e.g. green box versus pink box on Biblio home page).

A suggestion might be to backup your database, delete the biblio module from your file system, and then download the development version (pink one), and start from there. Hopefully your biblio tables aren't munged from the various mixed up versions. I am not sure what would happen.

*ouch!* Let us know what you figure out and if you can resolve it.

BUT, back to the point of this ticket is the issue of ePubs date from Pubmed. I'm still requesting it and will either dig it into myself and submit a patch, or hopefully someone else can get to it before me.

I'm not really understanding what you mean about "mixing and matching" different versions. If you have a Recommended Release (green box) and then you install a Development Release (pink box) - are you not able to just delete the current Biblio folder and replace it with an updated version and then run update.php?? Are there additional steps you are supposed to take when moving from a green to a pink version?

In principle, do not mix the green and pink versions together. It's not only the files that are different, but the Biblio tables in the database! There might be certain changes, additions, or modification differences between the green version and pink version. Don't mix and match them! Only the author, rjerome, would know best since he knows his code the best. It might be that it is okay to mix and match since the changes are not major and could just be additions. I would wait to rjerome's point of view. The *cleanest* step to transition from green to pink would be to uncheck all the biblio modules, and then UNINSTALL biblio. As you mentioned, this means that your Biblio tables get dropped and your settings are dumped. You basically are starting from scratch, but this is the cleanest and purest way to update unless rjerome says it's okay to mix and match, or the newest stable version of Biblio 7.1 comes out and includes an upgrade pathway.

Now that Biblio has created the missing table itself, I thought cron would be OK to run now. I am still getting the same errors as in #21 though - is everyone else managing to run cron OK - is it just me that can't?

Looking at my log messages in Drupal, I don't see any cron job errors. I'm not even sure if my cronjobs are running, but this is something I need to look into myself later. As I mentioned earlier regarding #21, there is something wrong with your biblio keywords table and the 'vid' is non-existent. Biblio is trying to insert something that does not exist (i.e. vid) into the table. That would take a little more debugging.

You say the ePub issue is not resolved yet - I thought the point of adding biblio to the cron run was that this would then update ePub dates. Is that not right? (#12 - rjerome said he had this sorted)

rjerome looks to be saying that saving biblio nodes is fixed. It is in direct response to your #9 & #11 problem, which is with your cron job, which is different from this current cron issue. I don't get the impression that he implemented the ePub dates yet, or if it's possible. I am frustrated myself because it only takes a few minutes to see the data that Pubmed spits out for the ePub date, and from there, it should be easy to modify the table and account for this. I'm just procrastinating on this. :(

If I do indeed need to completely uninstall Biblio and start again, is there a way to backup data so it can be imported? Should I export all biblio tables and then import again afterwards, or do I need to get data from individual tables?? I've never uninstalled/reinstalled before so would appreciate any advice on minimising manual input.

I would definitely backup all the biblio tables (and your entire database!). The biblio tables usually are prefixed with 'biblio_'. I *think* those are all the tables you need for biblio. Just export them out into CSV format or something in MySQL. I would assume that if the table structure is the same after you uninstall and reinstall Biblio, then you can just import them back in via MySQL easily. Otherise, if they are not the same, then you may need to clean up the exported text files in Excel or some CSV/TSV program, and then import it back in via MySQL to the appropriate Biblio tables.

1. I'm not really understanding what you mean about "mixing and matching" different versions. If you have a Recommended Release (green box) and then you install a Development Release (pink box) - are you not able to just delete the current Biblio folder and replace it with an updated version and then run update.php?? Are there additional steps you are supposed to take when moving from a green to a pink version?

No there are no additional steps, so long as you delete the old version and replace it with the -dev version, you should be good (but you should always remember to run the update.php script after replacing the files). The only difference between the release and dev packages is the point in time they were created. The -dev releases get rebuilt every 12 hours (assuming I've pushed any changes to the code since the previous build). The 'release' versions only get built if I specifically make it happen. The upshot of all this is that it's easy to move from a "release" version to a -dev version because you are essentially moving forward in time. It's not so easy to go back from -dev to a release version, because you are moving back in time and database changes made in the -dev version may not be backward compatible with the older release version. The best time to move from a -dev version back to a release version is when a new release version is created because this is when the two code bases are at the same point in time.

2. Now that Biblio has created the missing table itself, I thought cron would be OK to run now. I am still getting the same errors as in #21 though - is everyone else managing to run cron OK - is it just me that can't?

OK, it just occurred to me what the problem is here. Cron jobs run as the anonymous user, thus don't have enough privilege to update the nodes. There are work arounds for this in Drupal 6, but I just checked and it seems that these things don't work in Drupal 7, infact the documentation specifically says that you cannot run a cron job as an authenticated user in D7 :-( So I'm going to have to think about this one a bit to see how we can work around it. If you were to log into the site as a user with biblio_admin privileges, and then run the cron.php script, I would be will to bet that all would work just fine, it's just the automated cron tasks that won't work at this time.

4. If I do indeed need to completely uninstall Biblio and start again, is there a way to backup data so it can be imported? Should I export all biblio tables and then import again afterwards, or do I need to get data from individual tables?? I've never uninstalled/reinstalled before so would appreciate any advice on minimising manual input.

This is a tricky one, because biblio stores data in other tables as well as the ones prefaced with "biblio_". I have developed a module (but it's not publicly available yet) which was intended to migrate data from one installation to another, but it could also be used for backup purposes.

So the bottom line is... I think your biblio installation is probably fine, and I wouldn't completely uninstall biblio at this point. I suspect that the root cause of the errors in #21 is the cron/permission issue, and I will explore options to fix that.

Cheers,

Ron.

In theory, you shouldn't have to disable the module before updating (I never do), but can't hurt and if it works for you...

If you need further help, please re-open and provide details.