Keep both MR until new stable release for 1.2.x at least, use MR19 changes for currrent stable or MR47 for dev version or future 1.2.x stable.
Needs re-roll for 1.2.x (dev version not current stable)
Attach patch of that mentioned changes in case anyone wants to try, please also note that content provided by recipe & generated by default content will not use the same logic so it will fail so... maybe something has also to be done into "core recipe import content logic" to use similar or compatible strategies?
It should work fine using genenerated default content using these changes & creating content also with this changes (default content not core recipe content).
Not sure why latest changes was reverted, recover most relevant notes about important points written in #63 & #65,
please note that any existing exported default content generated without this logic, or previous version, may be incorrect as it is expectable and may be regenerated:
Current approach just avoids exception & skips "block serialized" approach, which is the default one; @see "\Drupal\layout_builder\Plugin\Block\InlineBlock::getEntity()":
...
if (!empty($this->configuration['block_serialized'])) {
$this->blockContent = unserialize($this->configuration['block_serialized']);
}
elseif (!empty($this->configuration['block_revision_id'])) {
$entity = $this->entityTypeManager->getStorage('block_content')->loadRevision($this->configuration['block_revision_id']);
$this->blockContent = $entity;
}
....
So any serialized block dependencies are ignored, and is the first option when new non existing content block is used in layout builder, besides that approach just works with "inline_block" plugin variants & "InlineBlock instance" can be used instead in order to get it working per base class.
Other case where that should be managed as in layout builder you can mix entity field blocks and content blocks (content) into any display of exported content or its dependencies.
Also some entities like section library template may use same field type to store sections but in different field name, not "layout_builder__layout" but "layout_section", to manage that again "instance of SectionData" can be used instead to detect it.
So taking all use cases would be something like:
- Content blocks serialized & dependent entities (media or other)
- Content blocks direct usage & dependent entities (not serialized)
- Content blocks usage inside any display of exported entity or its dependent entities. Maybe this one is the hardest to manage. Not display config entity but any content block usage on it.
Reverted changes to MR;
- Avoid layout_builder classes direct use to not force module dependency by missing classes on sites without layout builder enabled
- Manage serialized block content
- Use base classes to evaluate instances to avoid strict unique core lb support
Maybe "Drupal\block_content\Plugin\Block\Drupal\block_content\Plugin\Block" should be also supported (direct block content usage from core content block library). Also other possible use cases like commented into #63 -> 3.
Happily using those changes for months with Layout builder, VLSuite & Section library...
Using core 11, on configuration of any block it appears:
ArgumentCountError: Too few arguments to function Drupal\block\BlockForm::__construct(), 6 passed in /var/www/html/web/modules/contrib/block_ajax/src/Form/AjaxBlockForm.php on line 55 and exactly 7 expected in Drupal\block\BlockForm->__construct() (line 94 of core/modules/block/src/BlockForm.php).
Great!!
Included some extra notes to readme file in order to clarify some doubts that may appear on first steps with VLSuite.
Ready to review
crzdev → created an issue.
Thanks @iván barrios, analyzed solution with @alejandro cabarcos & decided to keep that customizable by alter as current approach opens the door to many use cases that can't be simplified just to two padding options:
- Logo link is affected
- Header top main dropdown link
- Header top inner dropdown links
- Header top nav link
- Header top other link (content block text with link)?
- Header main dropdown link
- Header inner dropdown links
- Header nav link
- Header inner nav link
- Header other link (content block text with link)?
- Also add to footer?
So we currently decided to not make that so complex as you can always define your own customizations by alter or adjust header & footer default styles from starterkit according to your needs.
crzdev → changed the visibility of the branch 3497861-inconsistencies-in-themes to active.
Great, thanks! Integrated!
Great, thanks! Yes this should be definacly inditated into release notes.
Not related to this module & not sure about what could be happening in your specific installation, sorry!
Only thing that i can suggest with that info is to ensure you are executing drush from your site composer installation e.g: "vendor/bin/drush status", or to check what drush location you are running "whereis drush", you should see something similar to "/var/www/html/vendor/bin/drush" if using ddev.
Also ensure your site installation main composer core dependency "drupal/core" or "drupal/core-recommended", helpful command: composer why "drupal/core".
Hope it helps a bit!
MR changes integrated into 2.x!
New approach working as expected:
- Layout builder bundle fields added to field map still needed
- No error report related to bundle field storages
- Tested with new vlsuite demo setup
- Tested for existing sites
To evaluate after new approach is ready:
- Check existing site (without status report errors)
- Check layout builder bundle fields patch is not required any more
Not working current approach into all scenarios, adjusting with @omarlopesino
Ohh great, something fixed & included, that other error seems quite strange, maybe related to files folder permissions to generate twig templates cache? Did you tried clearing cache?
Generated MR with changes to avoid reported error
According to core php compatibility table we should support 8.1 too for core 10, this requires some minimal changes
Thanks for the interest shown, it should work properly if you use specific version according to your core version using last stable of each major version:
- Core 10 (current stable 10.4.1): PHP 8.2 or PHP 8.3
- Core 11 (current stable 11.1.1): PHP 8.3
Related to specific error:
- PHP 8.2: Constants are supported in traits: https://php.watch/versions/8.2/constants-in-traits
- Drupal PHP requirements: https://www.drupal.org/docs/getting-started/system-requirements/php-requirements →
Please let us know if that solves your support request.
Tested into existing site and also into new site with vlsuite demo installation, working fine!
crzdev → made their first commit to this issue’s fork.
Related issue to refine base ( 3499643 ✨ Base refinement Active ) was also used to adjust missing font family into footer links & footer top links, also includes an adjust to apply customizations to any link not just menu links.
With that change all links customizations keeps with same options except "font_size" for base links, complete list is "font_family", "font_size", "font_weight", "decoration", "color" & "accent_color".
Please @iván barrios adjust issue title & description for adding padding (horizontal & vertical). please note that may have no sense for "simple links" but for "menu links", take that into account.
@sylvain lavielle Glad you managed to adjust customizations by using alter, nice to ear that :). We will credit you in related issue.
These changes are included:
- Include artisan language switcher optional block
- Unify links options(footer top & footer links missing font family) cc @sylvain lavielle
- Header always visible region inline blocks
- Inline form mixin (header search basic block)
Thanks for the insterest on Artisan theme @abhiyanshu!
Can you please confirm that you followed these installation steps?: https://git.drupalcode.org/project/artisan/-/blob/1.2.2/README.md?ref_ty...
So that you have generated your own subtheme, serialization, artisan & artisan_SUBTHEME (your subtheme) are enabled & last as default? Also that artisan_starterkit is not enabled as in only used as starterkit. Specially using artisan drush command that does everything automated when possible.
Also note that 1.2.2 has views SDC component so problem may be solved just by clearing cache in that scenario:
https://git.drupalcode.org/project/artisan/-/blob/1.2.2/artisan_starterk...
https://git.drupalcode.org/project/artisan/-/blob/1.2.2/components/views...
Unable to reproduce the error for now, please include further information like core version you used.
Thanks for reporting, that error seems related to popper bootstrap 5.3 dependency ("for positioning dropdowns, poppers, and tooltips"), theme dependency is the same as suggested per bootstrap "^2.11.8": https://git.drupalcode.org/project/artisan/-/blob/1.x/artisan_starterkit...
https://getbootstrap.com/docs/5.3/getting-started/introduction/
<script src="https://cdn.jsdelivr.net/npm/@popperjs/core@2.11.8/dist/umd/popper.min.js" integrity="sha384-I7E8VVD/ismYTF4hNIPjVp/Zjvgyol6VFvRkX/vR+Vc4jQkC+hVqc2pM8ODewa9r" crossorigin="anonymous"></script>
<script src="https://cdn.jsdelivr.net/npm/bootstrap@5.3.3/dist/js/bootstrap.min.js" integrity="sha384-0pUGZvbkm6XF6gxjEnlmuGrJXVbNuzT9qBBavbLwCsOGabYfZo0T0to5eqruptLy" crossorigin="anonymous"></script>
Genrated "package-lock.json" expected generation for popperjs:
"node_modules/@popperjs/core": {
"version": "2.11.8",
"resolved": "https://registry.npmjs.org/@popperjs/core/-/core-2.11.8.tgz",
"integrity": "sha512-P1st0aksCrn9sGZhp8GMYwBnQsbvAWsZAX44oXNNvLHGqAOcoVxmjZiohstwQ7SqKnbR47akdNi+uleWD8+g6A==",
"dev": true,
"license": "MIT",
"funding": {
"type": "opencollective",
"url": "https://opencollective.com/popperjs"
}
},
When that happens you should be able to manage it manually, command is just a helper that will try to simplify process. So if that happens new theme folder should exists either way, but you will have to enable serialization module dependency & default theme manually.
As tunic said, i'm not able to reproduce this bug either, feel free to change status if you found new details to replicate.
https://www.drupal.org/project/artisan/issues/3497974 🐛 "Accent border color" field in Button theme settings works unexpectedly Active & https://www.drupal.org/project/artisan/issues/3493246 ✨ Artisan Styleguide refinement Active will be included soon which will make detect this kind of things in an easy way.
Besides please note that some options may not have been considered to be there like generic "links" font size as it may be a little strange to read an article body with text & its links in a different size, that does not occur with header links (menu links) as there that property has more sense to be customizable to increase main menu header links size.
Please also not existence of "hook_artisan_customizations_alter" & "artisan_starterkit_artisan_customizations_alter" where you can adapt all these presets to your specific needs in an easy way.
Thanks for reporting.
Never seen that error before, could you please specify core version that are you using and confirm 1.1.1 for artisan version?
Accoding to exception that happens when starterkit does not have ".starterkit.yml" file, which is included into starterkit for that theme version: https://git.drupalcode.org/project/artisan/-/blob/1.1.1/artisan_starterk...
Maybe a cache thing?, please try to flush cache and restart ddev containers (or equivalent) after you installed artisan to confirm if that error dissapears.
Iteration ready, same concept as "type" & "type_default" but with "extra_widget" && "extra_widget_default", also definitions or alterations should be much more flexible & easy to use. Note new method "getDefaultDefinition" to achieve that.
No worries, we are getting main idea of using "extra widget" definition; that is 100% backwards compatible. Also not sure why under forms & components extra widgets are not appearing. It will be in MR soon.
Integrated changes, another patch down!
Great, thanks @mortona2k, minimal required version constraint should be "^1.2", releasing asap!
Looks nice, thanks for the effort, reviewing asap!
crzdev → created an issue.
crzdev → made their first commit to this issue’s fork.
Feature base ready in MR:
- Use layout / section when available in sections "use advanced vlsuite layout options"
- Use animations options when available "use advanced vlsuite animations options"
- Use slider options when available "use advanced vlsuite slider options"
Pending:
- Update demo config to include new permissions for provided role & update for existing installations.
- Ensure coding standards.
- Update to grant new permissions to any other role (e.g: those with advanced utilities usage?), also include in release notes.
crzdev → created an issue.
Core compatibillity & vlsuite_demo / vlsuite_shuttle, 1.x will be end-of-life in future
You can use 1.x version of vlsuite (suported for now but with some changes from 2.x):
composer require 'drupal/vlsuite:^1.2' (for initial setup enable vlsuite_shuttle instead vlsuite_demo in that version). Then you should be able to update to 2.x without any problems when all dependencies are adjusted.
Or help with PR / issue into commerce_kickstart issue with change "drupal/layout_builder_restrictions": "^2.12" for "drupal/layout_builder_restrictions": "^3.0".
Great that you are interested! You can see a demo replicating drupal.org homepage here
In that case commerce kickstart should update that dependency version, as layout_builder_restrictions ^3.0 is the sugested by mantainers & also is compatible with core 11. So great that you created https://www.drupal.org/project/commerce_kickstart/issues/3481898 📌 Update layout builder restrictions to version 3 Active
Hello ugintl!
Could you please add link to the commerce kickstart used project & specify its version?
According to provided output, your composer.lock has defined layout_builder_restrictions:2.20.0, & vlsuite for core ^10.3 || ^11 (2.2.0) requires layout builder restrictions ^3.0.
So try to require that version first "composer require 'drupal/layout_builder_restrictions:^3.0'" or install vlsuite with "-W or --with-all-dependencies" so all dependecies are updated to correct minimum version.
omarlopesino → credited crzdev → .
All adjustments ready, it should be working with core 11, for existing sites installed by shuttle: https://www.drupal.org/project/vlsuite/issues/3435575#comment-15800647 📌 Automated Drupal 11 compatibility fixes for vlsuite Needs work
Closing this issue, 2.x release out today
Fixed "AssertionError: "..." must be defined in MODULE_NAME.field_type_categories.yml in assert()" when creating new field for core 11 into 2.x
Removed composer dependencies (& moved as suggestions) of:
- layout_builder_at
- media_responsive_thumbnail
Those dependencies are now managed by those using new vlsuite_demo preset (old vlsuite_shuttle now with just basis for a customized installation):
https://www.drupal.org/project/vlsuite/issues/3479416
✨
Customized installation refinement
Active
That will be included into release notes when new stable version comes.
NOTE: That just will affect to new 2.x version, 1.x keeps as it is. That way those modules won't affect for new installations in core 11 & no complete demo preset is needed.
Great, thanks! Integrating MR changes to 2.x
Uploading static patch of MR 53 changes to avoid commit iterations with MR gitlab patch or diff
Adjusted dependencies to new paradigm
Done both changes in MR:
Move composer dependencies optional with customizable installation to suggest:
- layout_builder_at: Required for VLSuite demo & suggested to resolve layout builder asymmetric translations strategy.
- media_responsive_thumbnail: Required for VLSuite demo & suggested to skip media entity view layer when using that formatter in a referencing entity.
New vlsuite demo & shuttle definition:
- Visual Layout Suite (VLSuite) - Demo. Install this module to automatically setup the VLSuite ready to use.
- Visual Layout Suite (VLSuite) - Shuttle. Install this module to automatically setup the VLSuite basis for a customized installation with complete integration but without node, block or media entities.
Maybe vlsuite_shuttle should enable full "basis but complete" integration & new vlsuite_demo should take that "role" for a complete "demo" experience. Of course with customized installation you are responsible to make all entities like "landing" node (existing or not), content blocks & medias & all others configurations needed to have similar experience of enabling shuttle but with complete customization.
Maybe this dependencies should not be added by main vlsuite composer file if those modules last too long to achieve core 11 compatibility (when using shuttle installation will request you to install them):
- layout_builder_at
- media_responsive_thumbnail
Related:
https://www.drupal.org/project/vlsuite/issues/3435575
📌
Automated Drupal 11 compatibility fixes for vlsuite
Needs work
Just to clarify; vlsuite basis may be:
- vlsuite (main module)*
- vlsuite_media (main media integration)*
- vlsuite_block (main block integration)*
- vlsuite_layout (main layout integration)*
- vlsuite_layout_builder (main layout builder integration)*
- vlsuite_utility_classes (main appearance modificators integration)*
- vlsuite_icon_font (main UI & other uses as field into any entity icon font integration)*
*Including its dependencies.
Adjusted vlsuite_layout dependencies without:
- vlsuite:vlsuite_media_image
- vlsuite:vlsuite_media_local_video
To check:
- Install vlsuite_shuttle: exact same behavior
- Customized installation: any vlsuite "basis" module is enabled but without of collection, block or media that generates vlsuite entities (like vlsuite_collection_hero, vlsuite_block_image or vlsuite_media_image).
crzdev → created an issue.
If the problem comes from "https://git.drupalcode.org/project/xray_audit/-/blob/1.x/src/Plugin/xray..." (Link Url generation), $Link->getUrl()->access() can be checked to avoid that error at time of rendering. Besides that will manage that user has access to xray report but has not to edit views.
To check just use:
new \Drupal\core\Url('<front>')->access();
= true
> new \Drupal\core\Url('noexists')->access();
= false
Then core patch related to bundle fields should not be needed, pending checking this for all use cases that suite provides as remove just some of those fields or entities & verify base tables.
Fixed config UI 2.x for core 11 with compatibility with ^10.3, also indcluded minimal test coverage (all config pages responds with response code 200).
New releases coming shortly with this fix
Making cherry pick also for 1.1.x branch (D9 & <10.3) also adding related original issue
Working as expected, thanks!!
crzdev → made their first commit to this issue’s fork.
To use with core 11 using composer:
Make sure vcs of compatible core 11 module dependencies are defined before "https://packages.drupal.org/8"
"repositories": [
{
"type": "vcs",
"url": "https://git.drupalcode.org/issue/layout_builder_at-3431569.git"
},
{
"type": "vcs",
"url": "https://git.drupalcode.org/issue/media_responsive_thumbnail-3431911.git"
},
{
"type": "composer",
"url": "https://packages.drupal.org/8"
}
],
Then:
composer require "drupal/layout_builder_at:dev-project-update-bot-only#1711072acdd1316d2648372557bf4273a9352e66 as 2.x-dev"
composer require "drupal/media_responsive_thumbnail:dev-3431911-automated-drupal-11#37e476ed5555d8b4d63c273a581da67ebd2ee445 as 1.x-dev"
composer require 'drupal/vlsuite:^2.0'
Including basis composer.json file to avoid "No valid composer.json was found in any branch or tag of https://git.drupalcode.org/issue/media_responsive_thumbnail-3431911.git, could not load a package from it." MR5
Any progress with core 11 compatibility?
Stable 11.0.0 is out since 2 August 2024 & current version is 11.0.5 (3 October 2024), maybe at least adjust "core_version_requirement" with "|| ^11" as first step to allow composer install, any other adjustment cannot be checked without possibility to install it. Thanks in advance!
Any progress with core 11 compatibility?
Stable 11.0.0 is out since 2 August 2024 & current version is 11.0.5 (3 October 2024), maybe at least adjust "core_version_requirement" with "|| ^11" as first step to allow composer install, any other adjustment cannot be checked without possibility to install it. Thanks in advance!
crzdev → created an issue.
+1 to RTBC! Thanks!
It was not really needed into that files, working as expected, thanks!
crzdev → made their first commit to this issue’s fork.
Great, thanks! Generating 2.x version!
Integrating current changes as it wont affect to any current installation due 2.x branch, moving to needs review
composer require 'drupal/vlsuite:2.x-dev@dev'
crzdev → changed the visibility of the branch 3472249-core-10.3.2-compatibility to hidden.
No action will be made into 1.x branch but into 2.x
Using 1.x for core ^9.5 || ^10 & 2.x for core ^10.3 || ^11