Best way to add a new block to an existing package
Permalink 1 user found helpful
I'm looking for the best way (or the only way) to add a new block to a package in a production scenario. Is this possible without uninstalling/reinstalling the entire package?
I tried changing the version number on my package, which gives me an "Update Addons" button, but running it didn't install the new block. Is this the right way to add blocks?
I tried changing the version number on my package, which gives me an "Update Addons" button, but running it didn't install the new block. Is this the right way to add blocks?
I've already created a package, with blocks inside of it, and installed it in production.
Now I just created a NEW block for that package, and really I want to keep it within the package if possible, and install it in production. I was wondering if there's a way to do this without reinstalling the entire package.
I realize I could put it in the blocks folder, but then it would be outside the package folder where it really belongs.
Now I just created a NEW block for that package, and really I want to keep it within the package if possible, and install it in production. I was wondering if there's a way to do this without reinstalling the entire package.
I realize I could put it in the blocks folder, but then it would be outside the package folder where it really belongs.
Ah I see; it wasn't clear if it was your custom c5 package or one you downloaded from the MarketPlace.
In your package controller you can add an upgrade method.
This is run when you increase the version number of your package and click the update package button in the dashboard. Within the upgrade, include the usual code to add your extra block type.
For more extensive examples, the upgrade method for eCommerce is full of things you can do.
public function upgrade() { ... ... }
This is run when you increase the version number of your package and click the update package button in the dashboard. Within the upgrade, include the usual code to add your extra block type.
For more extensive examples, the upgrade method for eCommerce is full of things you can do.
How do you keep around incremental upgrade logic (version 1.1 to 1.2, 1.2 to 1.3, etc.)? Or does your upgrade function have to be smart enough to detect the state of the user's installation and upgrade accordingly?
C5 is already smart enough.
Just changing a package version (for example) from 1.0.0.1 to 1.0.0.2 (or 0.0.0.1 to 0.0.0.2) will cause the dashboard to prompt for update and, when you click, for the packages upgrade fn to run.
Many developers use this trick to upgrade add-on packages during development and save the hassle of uninstall-reinstall.
Just changing a package version (for example) from 1.0.0.1 to 1.0.0.2 (or 0.0.0.1 to 0.0.0.2) will cause the dashboard to prompt for update and, when you click, for the packages upgrade fn to run.
Many developers use this trick to upgrade add-on packages during development and save the hassle of uninstall-reinstall.
Yea, I understand that changing the version causes Concrete to prompt for upgrade automatically.
My question is, say I have logic in the upgrade() function for upgrade from 1.0.0.1 to 1.0.0.2. Then I have another upgrade, so I replace the upgrade logic with my new upgrade logic, and change the version to 1.0.0.3.
Someone comes along with version 1.0.0.1 and upgrades. They are going to miss the upgrade from 1.0.0.1 to 1.0.0.2 because that logic has been replaced with the upgrade to 1.0.0.3
Is there a best practice here?
My question is, say I have logic in the upgrade() function for upgrade from 1.0.0.1 to 1.0.0.2. Then I have another upgrade, so I replace the upgrade logic with my new upgrade logic, and change the version to 1.0.0.3.
Someone comes along with version 1.0.0.1 and upgrades. They are going to miss the upgrade from 1.0.0.1 to 1.0.0.2 because that logic has been replaced with the upgrade to 1.0.0.3
Is there a best practice here?
For multiple upgrades the trick is to put a test whether a block is already installed about it in the upgrade fn.
After posting yesterday I wrote a how-to on this, it is currently waiting approval (maybe it will be approved and at the top of how-to by the time you read this - or if this link will workhttp://www.concrete5.org/index.php?cID=226980... ).
The key part of it is:
After posting yesterday I wrote a how-to on this, it is currently waiting approval (maybe it will be approved and at the top of how-to by the time you read this - or if this link will workhttp://www.concrete5.org/index.php?cID=226980... ).
The key part of it is:
public function upgrade() { parent::upgrade(); $bt = BlockType::getByHandle('my_other_block'); if (!is_object($bt)) { BlockType::installBlockTypeFromPackage('my_other_block', $this); } }
How-to now available at:
http://www.concrete5.org/documentation/how-tos/developers/add-anoth...
http://www.concrete5.org/documentation/how-tos/developers/add-anoth...
Now, if this is a production site and you don't have a lot of experience building blocks from scratch I would suggest to install the free add-on "Designer Content" which allows you to build blocks through a user interface in the dashboard.
http://www.concrete5.org/marketplace/addons/designer-content....
Depending on your level of comfort with this, you could even set up a dummy site and play around with the addon until you get comfortable, but if you've used C5 for any decent amount of time the learning curve is nearly non-existent.