PKP Bugzilla – Full Text Bug Listing
|Summary:||Plug-In version entries are not properly being installed/updated (was: Custom Block Manager doesn't work properly)|
|Product:||OJS||Reporter:||Bozana Bokan <bozana.bokan>|
|Component:||Plug-ins||Assignee:||PKP Support <pkp-support>|
|Severity:||normal||CC:||alec, jmacgreg, kritikes.spoudes, mattcrider, pdietz84|
|Version Reported In:||2.3.3||Also Affects:||OCS 2.3.3, OCS 2.3.4, OHS 2.3.2, OJS 2.3.4, OMP 1.0|
Patch against OJS 2.3.3-2
Patch against pkp-lib, tag OJS 2.3.3-2
Description Bozana Bokan 2010-10-27 08:54:55 PDT
After adding a new custom block using the custom block manager settings an empty 'div' element appears in the right sidebar just on that page (.../manager/plugin/generic/customblockmanagerplugin/settings): " <div class="block" id="custom"> </div> " The new custom block doesn't appear anywhere, neither in the list of the block plug-ins nor in the setup 5 :-( Tested on ojs 2.3.3-1 and 2.3.3-2, as well as on PKP testdrive (http://pkp.sfu.ca/ojs/demo/testdrive/index.php). Strangely, on the pkp installation I used to test ojs 2.3.3 before it's released (http://pkp.sfu.ca/ojs/demo/translate/index.php) everything seems to be OK :-O
Comment 1 Matthew Crider 2010-10-28 10:23:36 PDT
I can confirm this behavior (at OJS commit 9176ed3f7, PHP 5.2.6), but I'm not quite sure what's going on as it seems to be a system-dependent issue. Are files created anywhere in this plugin? Looking through the code it doesn't seem like it (It looks like everything is stored in the DB), but if so this might just be a permissions problem. Also, I don't really understand why empty Divs are being created on the settings page (if that isn't part of the bug). Also, editing a block's name and hitting save on the settings form doesn't actually edit the name, it just creates a new block--And the old one remains in the plugin_settings table.
Comment 2 Alec Smecher 2010-10-28 10:52:04 PDT
This appears to be caused by missing version information for this plugin. It can be corrected by executing the following in the DB: INSERT INTO versions (major, minor, revision, build, date_installed, current, product_type, product, product_class_name, lazy_load, sitewide) VALUES (1, 1, 0, 0, now(), 1, 'plugins.generic', 'customBlockManager', 'CustomBlockManagerPlugin', 1, 0);
Comment 3 Alec Smecher 2010-10-28 10:53:54 PDT
I've filed a related issue in bug #6071 -- see the first comment there.
Comment 4 Matthew Crider 2010-10-28 10:58:51 PDT
Yup, that fixed it Alec -- But my two 'Alsos' are still an issue-- The settings page makes these useless 'custom' divs on the page (not that big a deal, but its unnecessary), and renaming blocks doesn't work (It will always create a new, empty block).
Comment 5 Alec Smecher 2010-10-28 11:20:42 PDT
Matt, I think the empty "divs" are appearing because the custom blocks you've just created are empty; if you go into the Settings page for each (under "Block Plugins") you can add content, and the divs won't be empty any longer. Unless I misunderstand what you're seeing. I can't duplicate the behavior you're talking about re: renaming blocks; could you investigate a little further?
Comment 6 Matthew Crider 2010-10-28 12:22:03 PDT
You're right about the first one alec--I thought for some reason it was dynamically adding the DIVs to the DOM (which didn't make sense to me), but clicking the 'add block' button reloads the page and that empty div is supposed to be there. For the second one, basically the issue is that without IDs to reference in the plugin settings table, its not easy to rename the custom blocks. Try creating a new block from the Custom Block Manager, then adding content for that block (through the block's settings page). If you go back to the Custom Block Manager and change the name of the block, a new block will be created and the old one will disappear (though it still exists in the plugin_settings table, its no longer referenced in the row with plugin_name = customblockmanagerplugin and setting_name = blocks). I can spend some more time on this later, but it wasn't immediately obvious to me how to fix it.
Comment 7 jerico 2010-10-29 04:31:04 PDT
@Matt, Alec: Thanks for debugging this issue in my absence! I'll take on the first part (the missing version information). I've split off the second part (the renaming issue) into a separate bug report (see bug #6082) as these are two unrelated problems. I'm quite sure that the installer problem is just due to the missing reference of the updated to addPluginVersions(). I'll check that and provide a patch for that today. This fix should be part of a 2.3.3 point release if possible.
Comment 8 jerico 2010-10-29 14:09:51 PDT
Created attachment 3313 [details] Patch against OJS 2.3.3-2
Comment 9 jerico 2010-10-29 14:11:03 PDT
Created attachment 3314 [details] Patch against pkp-lib, tag OJS 2.3.3-2
Comment 10 jerico 2010-10-29 14:35:43 PDT
@Alec: the two patches should fix OJS. I won't include those patches on the wiki as they are part of the -3 release, right? I've tested that the upgrade works in OJS. You said you'll test a fresh install of OJS? I didn't test upgrade/fresh install of the other apps yet as this would have taken a considerable amount of time and I think we'll easily catch bugs in this change before their next release anyway. Here are links to the commits for all apps: http://github.com/pkp/ocs/commit/47b550464d88b3f4a27381f520484e5b9cd81a39 http://github.com/pkp/harvester/commit/c3d8534dde718e6359ad7700869a5e956ee3c0b1 http://github.com/pkp/ojs/commit/d24f208ad7ab5416041b09796c7408e24d39d3ba http://github.com/pkp/omp/commit/ddd39753d2f6efcbe327d719e3bc30ad9d6a4e7b http://github.com/pkp/pkp-lib/commit/933dc1a56b51f08e4599a60bcd76ab6846e9d507
Comment 11 Alec Smecher 2010-10-29 16:22:00 PDT
Florian, this breaks the upgrader -- addPluginVersions is no longer available to the Upgrade class, as it's moved into Installer, so the upgrade.xml call to addPluginVersions causes an error.
Comment 12 Alec Smecher 2010-10-29 16:29:16 PDT
Never mind -- my misunderstanding.
Comment 13 Alec Smecher 2010-10-29 16:32:24 PDT
*** Bug 6077 has been marked as a duplicate of this bug. ***
Comment 14 James MacGregor 2011-03-28 14:55:28 PDT
This doesn't appear to be fixed. I've replicated the problem where the custom blocks don't appear in the Blocks plugins listing, in both OJS 2.3.3-3 and 2.3.5-RC (the version Alec uploaded for testing recently). There is an entry for customBlockManager listed in the versions table, but the "current" value was set to 0 instead of 1. Changing that fixed everything.
Comment 15 James MacGregor 2011-03-28 14:58:26 PDT
(In reply to comment #14) > This doesn't appear to be fixed. I've replicated the problem where the custom > blocks don't appear in the Blocks plugins listing, in both OJS 2.3.3-3 and > 2.3.5-RC (the version Alec uploaded for testing recently). There is an entry > for customBlockManager listed in the versions table, but the "current" value > was set to 0 instead of 1. Changing that fixed everything. Also -- the 2.3.5 RC was a fresh install; the 2.3.3-3 is CGJ on our servers, and also appears to be a fresh install. In both instances, I could create new custom block plugins; they just weren't being displayed in the Custom Block listing.
Comment 16 James MacGregor 2011-04-07 10:49:01 PDT
*** Bug 6516 has been marked as a duplicate of this bug. ***
Comment 17 James MacGregor 2011-04-12 11:41:52 PDT
I'm closing this one in favour of a new bug -- after a lot of testing, I don't think the behaviour originally described in this bug report (missing info in versions table) is an issue for new installs, but I'm still running into custom block plugin issues in new installs, which I'll file separately to avoid confusion.
Comment 18 Peter Dietz 2013-03-04 12:14:57 PST
(In reply to comment #17) > I'm closing this one in favour of a new bug So, what is the new bug issue number? Sorry to post in an old bug report, but there's no path to find the new solution to this issue you are mentioning. Adding a link to the new one would be useful.
Comment 19 Alec Smecher 2013-03-04 13:28:02 PST
Peter, if you can't find the bug in the Bugzilla database, could you describe the behavior you're encountering in detail in a new bug entry? With that description we can try to find a duplicate if it's already filed. But there are lots of different behaviors described here and I'm not sure which applies to your situation.
Comment 20 Peter Dietz 2013-03-04 14:24:21 PST
I was commenting that (comment #17) >I'm closing this one in favour of a new bug Well, there's no trace of the new bug.. That before I went ahead and ran a DB insert, or cherry-picked some code in, which were the best solutions mentioned in this ticket. I wanted to make sure I had the latest instructions. As opposed to finding the next ticket that is related that says "DONT!!, It breaks everything, do this OTHER command instead". So, just to wrap up here. I did end up running the "INSERT into versions" mentioned here in comment #2, and it fixed my affected instance. I also did custom-block-manager plugin disable, then re-enable. Then I was able to see custom named blocks.
Comment 21 Alec Smecher 2013-03-04 15:15:38 PST
Peter, this bug was filed around the time we moved from loading all plugins all the time, to storing information in the database that allowed us to selectively load plugins. This resulted in a big performance improvement but as you've seen from the several bug entries it did have some growing pains. If you're able to describe in more detail -- e.g. "I used to run OJS 2.2.4, then I upgraded to 2.3.7, and suddenly my Custom Block Manager plugin stopped working" -- that would help.