No Functionality when creating blocks in a Package
Permalink Browser Info Environment
When trying to "concrete/bin/concrete c5:block-developer -b testblock" on a v9.0.1 Project with BlockDeveloper 1.2.3 it only works if i dont place the block in a package.
If i choose to place the block in an existing package the script runs fine, all lights green but there is no block (and no entry in the "BlockTypes" Table)
Any ideas or ways for me to figure out what is failing?
Regards
If i choose to place the block in an existing package the script runs fine, all lights green but there is no block (and no entry in the "BlockTypes" Table)
Any ideas or ways for me to figure out what is failing?
Regards
| Type: | Pre-Sale |
|---|---|
| Status: | Resolved |
Thanks for responding.
The Folder is created in the package with all files at /packages/mypackage/blocks/theblock.
The Folder is created in the package with all files at /packages/mypackage/blocks/theblock.
Hi there again,
Just tried it out, and I am seeing the same. Seems like they changed something crucial the way 9.x works - as the classes for Block Developer seem not to be loaded when the block is loaded. So this is a core concreteCMS issue at the moment, since it works perfectly fine in the /application/blocks directory. You can continue installing the block types in the /application folder at this point though.
At the moment, I don't see a workaround or fix yet. I will try my best for you though. I already posted an issue in the Slack channels, hoping to get an answer. Let's wait that out and see what happens.
Kind regards
Ramon
Just tried it out, and I am seeing the same. Seems like they changed something crucial the way 9.x works - as the classes for Block Developer seem not to be loaded when the block is loaded. So this is a core concreteCMS issue at the moment, since it works perfectly fine in the /application/blocks directory. You can continue installing the block types in the /application folder at this point though.
At the moment, I don't see a workaround or fix yet. I will try my best for you though. I already posted an issue in the Slack channels, hoping to get an answer. Let's wait that out and see what happens.
Kind regards
Ramon
I've got a temporary fix in 1.2.4 - it needs some manual changes though.
1) Install/create the block as you normally do in the CLI
2) Locate the controller.php file of the block
3) Change the line "use Devoda\BlockDeveloper\BlockDeveloper\Block\BlockController;" to "use Concrete\Core\Block\BlockController;"
4) Run the same CLI command as in step 1
5) The block type should be installed now, revert the change from step 3
6) You're done.
Not ideal for sure, but it's a workaround until they come up with a fix for this issue (probably not loading stuff in the correct order).
You do need version 1.2.4 of Block Developer, because I made sure some steps didn't fail because when using the default BlockController, a few methods are not available which the code expected to be there before. Now they may not be present and it will just say "failed" in the CLI but that's fine since it was already done in the initial creation.
Let me know if this works for you now. Sorry I couldn't come up with anything easier for now.
Kind regards
Ramon
1) Install/create the block as you normally do in the CLI
2) Locate the controller.php file of the block
3) Change the line "use Devoda\BlockDeveloper\BlockDeveloper\Block\BlockController;" to "use Concrete\Core\Block\BlockController;"
4) Run the same CLI command as in step 1
5) The block type should be installed now, revert the change from step 3
6) You're done.
Not ideal for sure, but it's a workaround until they come up with a fix for this issue (probably not loading stuff in the correct order).
You do need version 1.2.4 of Block Developer, because I made sure some steps didn't fail because when using the default BlockController, a few methods are not available which the code expected to be there before. Now they may not be present and it will just say "failed" in the CLI but that's fine since it was already done in the initial creation.
Let me know if this works for you now. Sorry I couldn't come up with anything easier for now.
Kind regards
Ramon
Thanks a lot.
I did the following:
1) create the Block in the CLI with -s install
2) taylor config.php
3) rerun cli with -s install (so db is updated and all)
4) change the "use" line in the controller
5) rerun without skipping installation
6) change the controller back to normal
This gives me an installed block inside the package with following Problems:
- the "default_set" option in config.php -> 'block' is not respected
- inside a repeatable, the image fieldtype is not working. the form is there but the fileselector does not get initialized i guess. outside a repeatable, it works.
NOTE: i have also tested an image fieldtype on a block installed outside a package. there i got similar problems and had to change the controller to get it to install and the image inside a repeatable also did not work
block_developer is 1.2.4 and concrete is 9.0.1
Seasonal Greetings
donat from lemonbrain
I did the following:
1) create the Block in the CLI with -s install
2) taylor config.php
3) rerun cli with -s install (so db is updated and all)
4) change the "use" line in the controller
5) rerun without skipping installation
6) change the controller back to normal
This gives me an installed block inside the package with following Problems:
- the "default_set" option in config.php -> 'block' is not respected
- inside a repeatable, the image fieldtype is not working. the form is there but the fileselector does not get initialized i guess. outside a repeatable, it works.
NOTE: i have also tested an image fieldtype on a block installed outside a package. there i got similar problems and had to change the controller to get it to install and the image inside a repeatable also did not work
block_developer is 1.2.4 and concrete is 9.0.1
Seasonal Greetings
donat from lemonbrain
Hi Donat,
The Block Type Set issue is also related to version 9 unfortunately. Perhaps I can also find a workaround for that... Still waiting for someone to reply on my question regarding these things.
As for the "Image" not working in repeatables, images/selectors work differently in version 9 as well. It indeed should work perfectly fine without a repeatable, but with repeatables it's an issue for now. This is the new setup of version 9 and should be something I can sort out but this takes a bit more effort so I won't be able to be of help on the short-short term. Hope to get this issue resolved ASAP. Due to holidays and deadlines this is something I haven't had time to fix yet.
Happy holidays and hope you manage for now!
Kind regards
Ramon
The Block Type Set issue is also related to version 9 unfortunately. Perhaps I can also find a workaround for that... Still waiting for someone to reply on my question regarding these things.
As for the "Image" not working in repeatables, images/selectors work differently in version 9 as well. It indeed should work perfectly fine without a repeatable, but with repeatables it's an issue for now. This is the new setup of version 9 and should be something I can sort out but this takes a bit more effort so I won't be able to be of help on the short-short term. Hope to get this issue resolved ASAP. Due to holidays and deadlines this is something I haven't had time to fix yet.
Happy holidays and hope you manage for now!
Kind regards
Ramon
Hi Donat,
I just tested the following issues in 9.0.2 of ConcreteCMS:
- the "default_set" option in config.php -> 'block' is not respected
- inside a repeatable, the image fieldtype is not working. the form is there but the fileselector does not get initialized i guess. outside a repeatable, it works.
Both are working good now. For the last bug, please update to 1.3.0. The first bug seems related to ConcreteCMS 9.0.1 (or below) - as it appears to be working perfectly here in 9.0.2.
Let me know if you still have any issues!
Kind regards
Ramon
I just tested the following issues in 9.0.2 of ConcreteCMS:
- the "default_set" option in config.php -> 'block' is not respected
- inside a repeatable, the image fieldtype is not working. the form is there but the fileselector does not get initialized i guess. outside a repeatable, it works.
Both are working good now. For the last bug, please update to 1.3.0. The first bug seems related to ConcreteCMS 9.0.1 (or below) - as it appears to be working perfectly here in 9.0.2.
Let me know if you still have any issues!
Kind regards
Ramon
Is the directory created in that package? If not, did you set the correct read/write rights for this directory?
If it is created, can you see if all files that are necessary are there?
Kind regards
Ramon