Closed mrpdean closed 4 years ago
Is anyone able to confirm this is a bug or am I the only one having this problem?
Thanks.
Looks like you're the only one with this bug :/
Maybe you can research a little bit to fix this problem.
Thanks for replying @core23.
If it's working for you I'm wondering if you might be able to share your relevant config files, sonata admin/blocks/pages so that I can compare them to mine?
Believe me I've tried to debug this error myself but haven't been able to identify the cause.
On older versions of the Page Bundle (3.3.0 for example) the block type is passed through when the Add New button is clicked: &type=sonata.page.block.container
For some reason, on this version (3.11.0) the type parameter is no longer passed through.
As to what has changed and why this is not working I have not been able to work it out. I don't even know if the issue is with Page Bundle, Block Bundle or Admin Bundle.
I've tested again on a brand new, clean install of Symfony 3.4: *composer create-project symfony/skeleton:3.4. my-project with nothing else but Sonata Page bundle installed: composer require sonata-project/page-bundle** and letting the recipes run and adding some minor config changes as per Sonata Page instructions but the error still occurs.
Here is the relevant parts of my config in case that helps:
`sonata_block: default_contexts: [sonata_page_bundle] context_manager: sonata.page.block.context_manager blocks: sonata.admin.block.admin_list: contexts: [admin] sonata.block.service.text: sonata.block.service.rss:
sonata_admin: assets: extra_javascripts:
sonata_page: slugify_service: sonata.core.slugify.cocur multisite: host use_streamed_response: false
router_auto_register:
enabled: true
priority: 150
ignore_route_patterns:
- ^(.*)admin(.*) # ignore admin route, ie route containing 'admin'
- ^_(.*) # ignore symfony routes
ignore_routes:
- sonata_page_cache_esi
- sonata_page_cache_ssi
- sonata_page_js_sync_cache
- sonata_page_js_async_cache
- sonata_cache_esi
- sonata_cache_ssi
- sonata_cache_js_async
- sonata_cache_js_sync
- sonata_cache_apc
ignore_uri_patterns:
- ^/admin\/ # ignore admin route, ie route containing 'admin'
default_template: default
templates:
default:
path: '@SonataPage/layout.html.twig'
name: 'default'
containers:
header:
name: Header
content_top:
name: Top content
content:
name: Main content
content_bottom:
name: Bottom content
footer:
name: Footer
matrix:
layout: |
HHHHHHHH
HHHHHHHH
TTTTTTTT
TTTTTTTT
CCCCCCCC
CCCCCCCC
BBBBBBBB
BBBBBBBB
FFFFFFFF
FFFFFFFF
mapping:
H: header
T: content_top
C: content
B: content_bottom
F: footer
direct_publication: '%kernel.debug%'
catch_exceptions:
not_found: [404] # render 404 page with "not_found" key (name generated: _page_internal_error_{key})
fatal: [500] # so you can use the same page for different http errors or specify specific page for each error
class:
page: 'App\Entity\SonataPagePage'
snapshot: 'App\Entity\SonataPageSnapshot'
block: 'App\Entity\SonataPageBlock'
site: 'App\Entity\SonataPageSite'
` Any assistance anyone is able to provide would be greatly appreciated.
Thank you
I'm also experiencing this problem.
The only progress I've made so far is if I add the following the BuildEditForm method of ContainerBlockService in the block bundle then the Add New button works:
'link_parameters' => array('type' => $block->getType()),
However, when saving (clicking the Update button) the same error appears.
Also, the ContainerBlockService has never had that line so this definitely isn't the issue.
This issue is really difficult for me to solve because of all the dependencies between different sonata bundle.
I can't but think this issue might only take a few minutes for the bundles authors to solve (or at least point me in the right direction), rather then me spending weeks trying to figure it out :(
I am also experiencing this problem
That's three individuals who are experiencing this bug. Can this now be tagged as confirmed?
There's no confirmed
label, but I sure can remove the unconfirmed
label. Did this work with previous versions of sonata-project/block-bundle ? Same question for sonata-project/page-bundle.
Thanks. Yes, it was working in our previous/old sonata setup using page-bundle 3.3.0 with block-bundle 3.3.0
That's an important piece of news. Anyone willing to push this forward can try to determine if it is an issue with the page bundle or the block bundle by trying the latest version of one of them and version 3.3.0 of another and vice versa
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
Bit sad that many of these bug reports get auto-closed without any resolution.
Sorry, but we need a cleanup because our team is very small and we try to spend our energy on the most important things to get things done.
It seems there was not so much interest in this issue, so no one tries to get a solution.
Bit sad that many of these bug reports get auto-closed without any resolution.
A PR is welcome :)
That's an important piece of news. Anyone willing to push this forward can try to determine if it is an issue with the page bundle or the block bundle by trying the latest version of one of them and version 3.3.0 of another and vice versa
@mrpdean not like I didn't explain how someone really interested in fixing this could have helped. bit sad that no one was.
@greg0ire I wasn't criticising the fact that it hadn't been resolved, merely that these bugs are being auto-closed without resolution. I don't see how that helps anyone. Just seems like false reporting of the current state of the bundle. I spent a few hours on it without success before I had to move on to alternate solutions. If I get time I'll take another look.
That would be great. We know it's not optimal, but it helps us focus on issues that receive activity, feedback. There are way to many issues for us to deal with, so at some point, we make a choice, and naturally pick issues that we think can be fixed because people stay involved. Note that it was auto-closed after some delay, and that the bot asked:
Is there anything you can do to help move it forward?
There clearly was, and no one did anything. Not blaming you of course, but I think it's fair to close the issue in such a situation.
Upgrading to SonataPage 3.29.0 fixed the problem for us.
Environment
Ubuntu 18.04
Sonata packages
Symfony packages
PHP version
Subject
Unable to add a child block to a sonata.page.block.container via the Block List tab.
When the Add New button is clicked the resulting request returns the error: RuntimeException: The block service `` does not exist
Block can be added via the Composer tab, but not via the Block list tab.
Steps to reproduce
Expected results
A new child block line get added under "Children"
Actual results
After clicking the Add New button the subsequent request returns
RuntimeException: The block service `` does not exist
at vendor/sonata-project/block-bundle/src/Block/BlockServiceManager.php:198 at Sonata\BlockBundle\Block\BlockServiceManager->load(null) (vendor/sonata-project/block-bundle/src/Block/BlockServiceManager.php:60) at Sonata\BlockBundle\Block\BlockServiceManager->get(object(SonataPageBlock)) (vendor/sonata-project/page-bundle/src/Admin/BaseBlockAdmin.php:266) at Sonata\PageBundle\Admin\BaseBlockAdmin->loadBlockDefaults(object(SonataPageBlock)) (vendor/sonata-project/page-bundle/src/Admin/BaseBlockAdmin.php:78) at Sonata\PageBundle\Admin\BaseBlockAdmin->getNewInstance() (vendor/sonata-project/admin-bundle/src/Admin/AdminHelper.php:220) at Sonata\AdminBundle\Admin\AdminHelper->addNewInstance(object(SonataPageBlock), object(FieldDescription)) (vendor/sonata-project/admin-bundle/src/Admin/AdminHelper.php:190) at Sonata\AdminBundle\Admin\AdminHelper->appendFormFieldElement(object(BlockAdmin), object(SonataPageBlock), 's6f2c8e486d_children') (vendor/sonata-project/admin-bundle/src/Action/AppendFormFieldElementAction.php:84) at Sonata\AdminBundle\Action\AppendFormFieldElementAction->__invoke(object(Request)) (vendor/symfony/http-kernel/HttpKernel.php:151) at Symfony\Component\HttpKernel\HttpKernel->handleRaw(object(Request), 1) (vendor/symfony/http-kernel/HttpKernel.php:68) at Symfony\Component\HttpKernel\HttpKernel->handle(object(Request), 1, true) (vendor/symfony/http-kernel/Kernel.php:200) at Symfony\Component\HttpKernel\Kernel->handle(object(Request)) (public/index.php:25)