Bug 6076

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.

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);

I've filed a related issue in bug #6071 -- see the first comment there.

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).

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?

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.

@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.

Created attachment 3313 [details]
Patch against OJS 2.3.3-2

Created attachment 3314 [details]
Patch against pkp-lib, tag OJS 2.3.3-2

@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

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.

Never mind -- my misunderstanding.

*** Bug 6077 has been marked as a duplicate of this bug. ***

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.

(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.

*** Bug 6516 has been marked as a duplicate of this bug. ***

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.

(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.

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.

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.

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.