https://www.drupal.org/project/drupal/issues/3432874 📌 Replace "Expose all fields as blocks to Layout Builder" configuration with feature flag Active
is a discussion among core committers and developers about Layout Builder Expose All Field Blocks. While they have committed some changes for 10.3 that supposedly resolve issues related to the module you might want to post your findings in that issue.
On my site (local and hosted) I did the drush pmu command I listed earlier. But I am not really using Layout Builder and thus may not have encountered the same issues you did.
Not trying to promote my own web site, but you can see a sample photo gallery from there at:
Note that the title at the top of the page and a list of thumbnails at the bottom are standardized. I could even live without the thumbnail listing. On my local site I have created a half dozen or so galleries over to paragraph bundles. The workload to insert 5000 jpg files (after individually creating media module copies of them and to customize the settings for each gallery is daunting.
I suspect we could probably use paragraphs bundles for all these galleries if we could have (a) a standard setup and (b) use the original image files rather than converting them to media files one by one.
fkelly12054@gmail.com → created an issue.
Exact Drupal version being run? All security patches applied? All contrib modules up to date?
Take a look in admin/reports and recent log messages, access denied, page not found messages. There could be an indication there of who is hacking you.
With 10.2.6 I was having similar Ajax, check your developer console errors trying to create media files. Searching for a space before <?php wasn't showing much EXCEPT that I found a couple of instances in phpunit.xml files from when I had been doing some testing last year. At times I had to customize versions of PHPunit.xml to deal with various testing demands and so had different versions lying around. The PHP statement is not right at the top of the file the way it normally is.
I'm not currently doing any testing but I've removed the blank space that's buried in the various phpunit.xml files and got through an afternoon of media work without any Ajax / see your developer console errors. I'm just searching in PHPstorm projects and testing on a local dev site.
I install using Composer. The code goes into project files (really just a directory) managed by PHPstorm. I use a subtheme which I named TSZL based on some suggestions in the issue queue here. It goes in a "custom" directory under \themes. This keeps it from getting overwritten by Composer. As far as I can tell the only things that matter in the subtheme are the line in its inf.yml that says:
base theme: solo
and then the fact that I've copied menu--sidebar-first.html.twig from the solo base theme.
After the composer update, my default theme in appearance changed from the tszl theme to the solo_subtheme. I went into appearance and changed it back to tszl. Then everything (which in my case is the menu--sidebar) worked again.
I have no idea or interest in what codemirror does. PHPstorm in conjunction with Composer does what I need. It would sure be nice if a Composer update to the Solo theme could retain customizations we've made but I realize that may be technically impossible. It is not a great difficulty once you realize that you may need to redo customizations after you update to a new release of Solo.
I don't find Balzy Photoshop module on Drupal.org at all. There is a flag module but the module page makes me suspicious that it is not really compatible with Drupal 10. There are lots on open issues, but little indication that the module is really ready for production use.
What version of Drupal are you trying to make this work with? The flags module has an impressive list of maintainers but it is not clear how many of them are really engaged with the product. The last "beta" release was December 2022 and the last dev release was January 2024. I'd want to dig a bit more into the release notes and who is supporting the project before spending a lot of time on it.
I support my wife's art gallery web site (many photo galleries) and am not sure that if I had a single page site I would get involved with all of Drupal's complexities.
Did you clear cache after making the change?
Suggest you post an issue in the Solo theme issue queue. The maintainer is very responsive
Good start. When you first go into the issue queue to create an issue there is a link to steps to creating an issue:
https://www.drupal.org/community/contributor-guide/reference-information... →
Cilefen (a former core committer) posted some corrections based on these issue "standards" that you should look at after reading this. No problem: we all have to start somewhere. Your screenshots look good and you've found the right place to report the issue. You might want to look at:
Which is listed on the main project page. There could be an answer to your problem in there. There is an impressive "set" of maintainers for the paragraphs module and it appears to be up to date with Drupal changes. This is not always true for contrib projects so that gives some hope that you'll reach a resolution.
re. screenshots: This is another good reason to use the appropriate issue queues for the modules you are working with. You can upload a screenshot or screen shots as files within the issue queue. In the forums here you would have to put the screenshot(s) on an external site and ask people to link to it.
On Drupal Org I see a module project for Paragraphs Version: 8.x-1.17. I don't see one for Extra Paragraph Types or Carousel Version: 1.4.1. I do see a module project for Slick Extras, the most recent release being 2.0.0 → released 6 April 2024.
I can't tell if you are referring to something in Slick Extras.
I would recommend that you seek support in the issue queue of the exact modules and releases you are using.
For what it is worth, I am working through issues with a paragraphs_bundles module that is linked up to the Solo Theme on Drupal. Even trying to work through the exact modules, the documentation and the exact versions, requires considerable effort and experimentation.
There are a number of modules with "paragraph" or "paragraphs" in the name. For anyone to help you they would need to know exactly which module (full name and version) you are using. Knowing which core version you are on is helpful too.
In composer.json there should be an installer path section that looks like this:
"extra": {
"drupal-scaffold": {
"locations": {
"web-root": "web/"
}
},
"installer-paths": {
"web/core": [
"type:drupal-core"
],
"web/libraries/{$name}": [
"type:drupal-library"
],
"web/modules/contrib/{$name}": [
"type:drupal-module"
],
"web/profiles/contrib/{$name}": [
"type:drupal-profile"
],
"web/themes/contrib/{$name}": [
"type:drupal-theme"
],
"drush/Commands/contrib/{$name}": [
"type:drupal-drush"
],
"web/modules/custom/{$name}": [
"type:drupal-custom-module"
],
"web/profiles/custom/{$name}": [
"type:drupal-custom-profile"
],
"web/themes/custom/{$name}": [
"type:drupal-custom-theme"
]
},You might want to check (compare) the two composer.jsons (hosted and local) and make sure the contrib modules are in the contrib path.
The mov files don't have sound in the Media Player embedded in Windows 11. Other mov files on my PC do play sound. No problem: I've looked at the mov files and learned what I need from it. I'm not chasing Windows Media player sound problems further down any rabbit holes.
I can now create simple galleries on my local system using the solo theme and subtheme (I customized the tszl subtheme you provided to another user and put it in a custom directory outside the solo directory so it won't get overwritten by further Composer updates). I can get the link field working and use some of the formatting options. Since I have well over 100 galleries and thousands of image files in those galleries I will need to work out a stable and repeatable conversion process. Links to all the galleries can be found in what will become menu--sidebar-first.html.twig on various pages in the site. It will take some months of experimenting with the many great options provided by the paragraphs bundles to figure out a good approach to this. What I have now is just an initial proof of concept.
The site I am starting from is at fkelly.org if anyone is curious about how photo galleries work there. It's based on the Juicebox contrib module.
Making some progress. It appears that, when setting up a content type to contain slideshows you need at least one paragraph bundle before you can exclude the slideshow section bundle. And then just use the slideshow bundle. The content type then looks like this:
Label Machine name Field type Operations
Entity reference revisions
slideshow here field_slideshow_here Reference type: Paragraph
Paragraph type: Slideshow*
and when you go in to create an instance of this content type the fact that Slideshow is parent to the Slideshow section will automagically create slideshow section(s) for you to insert image fields into. You should then be able to insert multiple images into one slideshow section or multiple slideshow sections (each with images of course) into a slideshow. I haven't worked out what the best practice for converting my many Juicebox galleries over to Solo/Paragraphs Bundles is, but it looks promising.
*getting slideshow in as the paragraph type is the key because this creates slideshow sections where the actual images will go.
Sorry for delay. I hadn't loaded screen capture software on new computer and had other fish to fry. Let's start at the beginning. First step is to create a content type with a paragraph field. For slideshows we want that paragraph field to be named "slideshow". Initially we want to exclude the slideshow section field from that content type. It is a child of the slideshow field.
File named
2024-04-12_17-18-53.png
is my effort to do that.
In the screen capture you can see that I went through the lengthy list of paragraph field types and used the "exclude from the selected below" option to try to exclude the slideshow section field type.
In the second screen capture (2024-04-12_17-22-01.png) you can see that doesn't work. Instead the paragraph field type that gets included is the slideshow section. This leads to further problems when you try to use this new content type. But all I have time for today is to illustrate this problem. If you try to exclude slideshow section it should be excluded. I think.
Thanks for quick response and apologize for delay in getting back to it.
So, I think that using "basic page" in the video can cause problems because that content type can be set up for other uses and have conflicting settings on a given users system: even in the very basic setup I have have for testing solo and paragraphs for slide shows.
That said, I am trying to replicate your suggestions in #3 and having problems with the exclusion of slideshow section. I created a content type that I named Slide_page. The type of item to reference is set to "paragraphs" and I limited the allowed number of items to 1. The reference number is "Default. Under Which Paragraph types should be allowed? I picked the "Exclude the selected below"
I get a long list of paragraph types generated from previous attempts at using paragraphs bundles feature. I click to exclude the "Slideshow section" and then click save. The resulting content type shows:
Status message
Saved slide configuration.
Create a new field Re-use an existing field
Label Machine name Field type Operations
Body body
Text (formatted, long, with summary)
Edit
List additional actions
slide field_slide
Entity reference revisions
Reference type: Paragraph
Paragraph type: Slideshow Section
Edit
List additional actions
I added a captured jpg file showing what happened. Basically when I try to exclude the Slideshow section instead of excluding it ... it gets included as the paragraph type.
Out of time for today. I'll be back soon.
As stated in the issue summary I installed Paragraph Bundles version 1.0.2 (using Solo theme 1.0.3).
Have been trying to make the slideshow bundle work properly by following the video step by step on a local system, checking each step as I go. (Hint to other users: the video go very fast and the forward and back keys < and > are very handy to move the video 5 seconds forward or back and keep it stopped so you can check steps out on your local system).
The problem I am encountering is that a "slideshow bundle" and a "slideshow section bundle" get created as paragraph types. Then when you go to create a basic page content item with a paragraph in it ... the video says to first disable (exclude) the slideshow section bundle. This does not work ... the slideshow section bundle remains in the basic page content type. Even if I "hack" at the list of paragraph types that shows on the para field of the basic content type I don't get the ability to add a slideshow bundle and the slideshow section bundle is not excluded. I understand that the slideshow section bundle is a "child" of the slideshow bundle and that I don't want the section bundle to be included in the basic page but I don't see a way to make this work the way that the current instructions or the way the system itself works.
This functionality looks very promising ... I think it has the promise of allowing us to eliminate an entire other contrib module for producing slideshows that in turn relies on an external non-open source (and not free) Javascript program. First though I've got to figure out how to make it work.
fkelly12054@gmail.com → created an issue.
As a supplement to the layout builder module you might want to have a look at the new Solo theme. And for advanced cases the paragraphs bundles module that goes with it. Lots of features and lots of flexibility. Some nice videos introducing the features too.
Problem is that "all the custom settings in all the modules" does not have a clear meaning to anyone "outside" looking at your situation. Is this dozens, or hundreds or what? It appears that you have /web/modules and then within that all the core modules and all the contrib modules you use. Some of those contrib modules will probably be identical to those posted on Drupal.org and some will essentially be contrib/custom (so you will have a mish-mash within /contrib of modules taken straight from Drupal.org and others that you've modified.
This raises the question of what you plan to do with your contrib module going forward. Anything on Drupal.org is going to continue to be modified to take into effect the constant deprecations and other modifications (improvements even) that happen over the course of time. If you do a composer require for an updated module (wherever it is located) it's going to wipe out your customizations. The only way around that would be to self-maintain the custom modules in a custom directory and never composer require the updates. And that's going to cause problems because, in at least some cases, the updates are going to be required to keep working with future core versions of Drupal.
I guess that if you have to have custom then you have to have custom. But it's going to be a headache regardless of which way you go.
I am not a composer expert, so other input would be welcome. BUT, the location of files is controlled by a composer scaffold section of composer.json. There is a sub-section of the scaffold area named "installer-paths". You can override this but I'd be cautious about that. The core developers and committers spend a lot of time setting up the expected paths. I'd recommend that you start out instead by putting the contrib modules you use in the modules/contrib directory of your composer.json and go with the flow, so to speak. I'm not sure what "your biggest problem" is but if you want to have an "idiosyncratic" directory structure it is likely to be a bigger problem down the road. In every module project you see on Drupal.org there are instructions on how to load the latest version of the module. These may not work properly if you modify the directory structure.
But, yes, having your own servers can be a great advantage and being able to perform the migration "slowly" and incrementally is a significant avantage as is not having to muck around with getting Wampserver or DDEV installed and working properly.
It is a worthwhile (and necessary) process you are undertaking but I'd emphasize the word "process". It will not be a one step affair.
I'd strongly recommend that you set up a local development system (the Drupal wizards are currently recommending DDEV, but Wampserver is also still available if you are using Windows) and there are other alternatives. If you can get a local copy of your site running, it will be much easier to experiment and make incremental improvements. You will want both Composer and Drush running locally. I went through about 6 "versions" of my local site using composer before I was ready to move the process to my shared hosting site.
You want to be really careful about deleting "modules" ... you can't just go into the /modules or /contrib directory and delete things: Drupal has configuration stored in your production database and you will trash your site if you start just deleting from the file system. Both Composer and Drush give you tools to inactivate and remove modules. This is one of the reasons why having a local system where you can different versions of your site active is so helpful. Have one version reflecting your current site and then incrementally add a version with a modified composer.json that reflects modules and themes at work in Drupal 10 and 11. Use the upgrade status module to tell you which modules are not consistent with updated Drupal core versions.
Start using the upgrade status module now. It will tell you the requirements for moving to 11 for both current modules including the two you are most concerned about. Then keep checking the project queues for those modules and you should get a good sense of how much progress the maintainers are making with getting those modules ready for Drupal 11.
comment number 1 created by Frank
fkelly12054@gmail.com → created an issue.
A new comment testing lastpass
I am closing this until we have a stable version to test the suggested changes against. Version 4.0.0-alpha does not include changes made after that code. These are numerous. We need at least another alpha, beta or even a stable release before using Drupal rector changes against that. No point spinning Drupal rector wheels on a dead end street.
Please disregard #5 through #12. These were created automatically (somehow) as soon as I came in to look at #2. I can't find anyway to delete issue #'s once they are created. Which I realize may be intentional on Drupal.org's part but really all I did was sign in via Lastpass can go in to look at #2. The watchdog patches should be taken care in patches for Drupal 10 that I have pending.
fkelly12054@gmail.com → created an issue.
re. #9 I installed the development release you suggested and it fixed the problem. Thanks.
I'm in the middle of getting the responsive, multi-level dropdown menus to work in the solo subtheme. It's a work in progress but I have my menus derived from the d8w3css them "working" ... you can read about what's required in the issue queue. As a new theme, Solo is a bit of a work in progress but a promising work in progress with good support.
The solution in #6 worked perfectly, almost. I was able to copy the file as you suggested. After clearing cache the resulting menu worked better. I went into structure/menu and edited the menu where I had appended ... (periods) to the shorter menu items and got rid of the ugly periods. Saved, cleared cache and retested the menu ... all seems fixed.
Almost. I uploaded a file showing one remaining problem. With the template from the base theme the link at the top of the Menu (to the right of the menu name) where you should be able to configure block. remove block or edit menu is "obscured". I could work around that by going into structure/menus and editing the menu there.
Eventually I'd like to use the "click" version of the sidebar template ... which has the name (I think) menu--responsive-menu-template.click.html.twig. Is that the right one to use in place of menu-primary-sidebar-menu-template.html.twig in the theme? By the way, the way PHPStorm manages files and caches your whole "project" means it doesn't have a convenient rename file capability.
My solo experimentation site is on my Wampserver locally so I can't give you a link to it.
Thanks again for your help. This is progress and promising.
Thanks for your help. Taking your suggestion in #4 I have the sidebar menus working in my solo subtheme on my local system.
One remaining issue: the left sidebar menus that I want to use have some very narrow (say, 5 characters or even less) fields. In
the theme settings I have
"The two columns' settings for main region
20%, 80%
The three columns' settings for main region
20%, 60%, 20%"
This helps a bit. But I still wind up with two separate menu items on the same line in the menu, for instance:
Juggling my thoughts I AM
where "Juggling my thoughts" is supposed to be one menu item and "I AM" another menu item on the next menu line.
The "same" menu works just fine on my live site at fkelly.org using the d8w3css theme /subtheme but of course it uses a different twig template. I worked up a temporary kludge solution by appending .... (periods) to menu items that are "too short" to force a line break, but that's ugly. I'm not really familiar with editing twig templates and don't see how the template menu--responsive-v.html.twig from the d8w3ss inserts line breaks where I want them while the template from the solo subtheme doesn't.
Otherwise my update to the solo theme is going very well. I am looking forward to trying out paragraphs bundles.
I have had d8w3css running for over 5 years and have been very happy with the way drop down menus are set up. On my production site @fkelly.org you can see the dropdown menus ... these are generated from the d8w3ss subtheme and use files from both the /navigation and /layout directories in the subtheme. Example from the layout directory "page.html.twig" and from the navigation directory "menu.html.twig" and "menu_responsive-v.html.twig". (I copied these from the d8w3css subtheme). I customized the settings in the Solo theme and subtheme but am not sure what the necessary steps are to make the menus work with Solo (or its subtheme).
I've uploaded a png of a working dropdown generated by the d8w3css theme and a not quite working one with the solo subtheme. I tried to follow the steps suggested in https://www.drupal.org/project/solo/issues/3420931 💬 How to Create a Custom Sidebar Menu in the Solo Theme, Ensuring that Sub-menus Remain Open if They Contain an Active Link Fixed but obviously came up short somewhere.
Can we use the code from the d8w3sss layout and navigation directories copied over to solo? Or how do we go about getting drop down menus to work as well in Solo as they do in d8w3ss? I'm coming from a contrib project named Juicebox where we use a LOT of photo galleries based on some 7 year old not open source Javascript code and it looks to me like we could use your slideshow capabilities from the paragraphs bundles module ... but first I need to get the menus from my d8w3ss based theme working in Solo.
In the subtheme settings I did "Tick this box to load the W3.CSS library locally" and I also loaded the Font Awesome library. I was thinking that the w3css library might get me the "chevron" generating CSS that I need. But so far that's not working. I've looked at view source and can't see where the bold code at the top of the not quite working ... screen capture is coming from.
Suggestions, directions welcome. (Incidentally the block copy module and instructions worked just fine. I had Solo up and running in a half hour using your video. thanks for that.)
fkelly12054@gmail.com → created an issue.
What Jaypan and Ressa said. No one can step through your entire composer.json for you. I see Bartik in there and it's not recommended for Drupal 10. You might want to install the upgrade_status module by itself and see what recommendations it makes. I think you may have some other outdated stuff in your composer.json that will give you problems. Also, try composer validate at your command line and see what recommendations it makes. And composer outdated "drupal/*". Or go through:
https://www.drupal.org/docs/updating-drupal/updating-drupal-core-via-com... →
which is the go to documentation (and now includes instructions for Drush).
An alternative is d8w3css ( https://www.drupal.org/project/d8w3css → ) theme. You may need to use a subtheme of the d8w3ss theme or want to use the new Solo theme they are starting to promote. There are a couple of posts about drop down menus in the issue queue for that theme. And, I believe, some documentation about how to implement drop downs. I have on click drop downs working on my personal site using the most recent (but not Solo) production version of d8w3css.
Documentation, support and issue resolution are pretty good. I can't say that's true for all contrib projects so read the issue queues for whatever you are considering carefully and critically.
Just guessing, but should this be an issue in the printable module issue queue? Do you have this module installed and are trying to update it?
4.0.x-dev is the current version of Juicebox. We are trying to get a stable version going forward from that for Drupal 10. I have code working on the latest Drupal 10 which, as of today is 10.2.3. The current Drupal core version is constantly changing, of course. I doubt we will be doing anything with Juicebox 8.x-3.0-alpha2. I certainly won't.
I went to the siteimprove web site and took the chance to install its extension in my Chrome browser, then looked at my Drupal 10 web site Juicebox Gallery. No real surprise, siteimprove shows accessibility issues. It would almost be a surprise if it didn't because the Javascript code generating the gallery is more than 5 years old. And we (Drupal) have no direct access to the Javascript code.
I am reducing the priority to Normal and the status to postponed. If there is someone out there who wants to work on this, most probably for a release focused on Drupal 10 and forward, post here. Granting the importance of accessibility, unless someone knows how we can address this it is not likely to be dealt with. Sorry.
How to run composer on server will be depending on how your server is set up. On mine using Inmotionhosting there is a bashrc file with the following (with certain files obfuscated):
# .bashrc
# Source global definitions
if [ -f /etc/bashrc ]; then
. /etc/bashrc
fi
# User specific aliases and functions
alias composer='/home/xxxxx/public_html/composer2/composer.phar'
alias drush='/home/xxxxx/public_html/vendor/bin/drush'
export PATH=$PATH:/public_html/composer2
export PATH=$PATH:/public_html/vendor/bin/drushThis lets me run composer and, as important, be able to update it with new versions. Likewise with Drush. And I use the terminal application there.
You need to talk to your web site host's support staff to find out where they put composer and how they suggest you use it. They should give you some sort of "terminal" or "command line" facility that you can log in to or access from Cpanel or whatever hosting package they use. You should be able to switch to your "public_html" or other "home" directory they use and update Composer independently of your host from there. That's where you should also be able to access Drush from.
Thanks Leo. I suspect that Drupal will not do well with an altered PHP configuration file. The second that you run Drupal, it is expecting to go through a standard order of executing things. It has to detect what themes and modules you have installed and take various other steps in a specified order. That's why you can't do things like, for instance, just delete a module manually from the file system. The module will still be listed in the database when you do that and Drupal will get very confused and emit errors. It's also why having Drush as a command line tool can be very helpful ... it knows what order steps have to occur in and makes sure that happens.
Just worth a mention. I finally got my d8w3sss theme straightened out between my local site and my hosted site today. It took all morning. The reason: way back when (5 years ago) before I used Composer I had put a copy of d8w3css in my /web/themes directory directory rather than in /web/themes/contrib. Then when I figured out Composer, it loaded d8w3css into web/themes/contrib. So I had essentially two copies of d8w3css although only the one in web/themes/contrib was so called "active". I use a product called Beyond Compare to help with file management ... it can bring up my directory structure for local on one side of the screen and hosted on the other side and show differences between files and directories and bring them into synch. It finally brought it into focus in my dim brain that I had discrepancies which I had to reconcile ... basically getting rid of the whole /web/themes/d8w3css directory so I had the same directory structure locally and hosted. And same exact set of files. Then I still wasn't getting the same set of "chevrons" showing in my menus ... when a menu item had children a down arrow (chevron) on the first level would show for items that had children. Turns out that in the theme settings there is as setting to load Google font awesome from the web and I had that setting for my local site but not my hosted site. That's fixed now too. Hopefully future updates will go more smoothly.
I did a few minutes reading up on ovhconfig. I can see where the wrong settings could cause problems if it caused your site to execute Drupal "in parallel". But I know little about it and never had heard about ovhconfig before and don't have the option to use it, so I will let it go.
d8w3css is definitely Drupal 10 compatible. They have a new version of the theme called "Solo" coming soon, I think. I've always had good luck with d8w3css ... good luck that takes a bit of work to make happen. Right now for instance I need to update my hosted site to the latest release. That may "shoot" a morning of time making sure my customized subtheme is in synch. When I found d8w3css a few years back it was after a period of looking for a theme that facilitated making multiple level menus. There were themes on Drupal that advertised this feature in the contrib space but none of them worked for me. Looking behind the scenes at the issue queues for these themes, they were not well supported. d8w3css was ... so I went with it. It has the advantage of being RELATIVELY simple as compared to bootstrap themes which require you to download thousands of files just to get started.
I don't understand what you are saying about PHP versus PHPCGI. I use a version of PHP 8.3 on both my local Wampserver and on my hosted version of the site on InmotionHosting. The hosted version is my "production" site. I just updated it to 10.2.3. before going away for this past weekend.
On themes, I use d8w3css ( https://www.drupal.org/project/d8w3css → ). I have the latest version on my Wampserver but need to update my fkelly.org production site. There is a little messing around to do to be the subtheme updated so I've delayed the update to 2.0.13 of dw8w3css on production. I don't like to promote my personal site here on Drupal but if you want to take a look at fkelly.org you can see what I'm up to. Basically I have a horizontal menu across the top of the screen. Each horizontal menu item represents on area of the site. The vertical menus go down the left side of the screen and mostly are a list of Juicebox galleries and sub-galleries. D8w3css gave me the opportunity to customize the vertical menus to indicate (and open) sub-galleries. These menus are in the subtheme.
(For what it's worth, there are some very recent issue queue posts in d8w3css about further customization of sub menus. I haven't had time to dig into it or see if this would be useful). The theme is well supported. I have a little problem, probably my own fault, with updates and keeping my sub-theme updated and in synch with the theme update. It just takes a little work after each update ... probably is is my own deficiency.
I am glad you are making progress.
Thank you for your persistence Leo. My day is going down a dark hole. I saw from your original post this morning that 10.2.3 was out. After mucking with Juicebox for a while and after rebooting my router I decided I'd do the update. After all it has been a whole 20 days since they did a core update! (yeah and I know 10.2.2 was a security update). So my theme needed updating too. Composer outdated "drupal/*" will tell you that.
I didn't want to update the Juicebox code however. I have patches posted in the issue queue where I've made changes to the code in PHPstorm and am waiting for the senior maintainer (who knows much more than I do) to review it. But composer still had an require for Juicebox that require was back at the last release level (before my changes). I thought maybe I could just eliminate the require in composer.json for Juicebox: but no way Jose. I took the require completely out. Composer knows all: it still wanted to update Juicebox. We had a little standoff. We need, I guess a "composer just-expletive-deleted-ignore-Juicebox command. Then I needed to update the theme I use. That gave me 2 hours of fits ... there's no instructions and I had made modifications to a subtheme that didn't carry across. I just finished picking up the wreckage from that.
Keep up the good work.
First, congratulations on your progress. Impressive work in a short period of time. I can't keep up (smiling).
I am having similar problems to yours with my theme (admin theme: Olivero) not loading completely sometimes. I am sometimes having problems with the "structure/content type/manage display" generating errors telling me to look at my developers console and then seeing some apparent Ajax errors there. I can't tell if it is due to changes from Chrome version 118 forward or not.
I will probably take the liberty of copying part of this into the Juicebox issue queue and activating an issue on it. When I have time. I also have concerns with my PC and network setup. I've been getting disconnected and seeing some indications that form submissions are not being returned fast enough before my PC gets disconnected. Then I reload the page and the form submission completes. I have fast connection both with a "hard-wired" Ethernet connection and wireless. The disconnects happen either way. I have to go down a rabbit hole with my router and see if there is some timeout parameter I can boost.
What theme changes did you make and what PHP read configuration are you talking about?
composer require 'drupal/juicebox:4.0.x-dev@dev' is the dev release with recent (December) changes. As noted in the project this is a test version, but that's what you are doing.
if you get you Juicebox gallery set up and are not seeing any gallery, you might try the uninstall then reinstall Juicebox trick I mentioned. We will need to refine that and I think not have it part of the installation but that is a Lleber issue.
You are making good progress in a short time.
Your browser versions look current. Good. I guess, because I'm looking into whether Chrome, starting with version 118 didn't do something to disable certain Javascript features. I see indications of this on my local system but need to confirm it on my hosted system before I reaise any alarms in the project issue queue.
I can confirm too that your gallery works in Firefox but not in Chrome. You would have to see whether Chrome is throwing any error messages.
It looks like you have the current version of the Juicebox install program. If you do modules/uninstall for Juicebox than reinstall it some field type errors may get cleared up. I need to talk to the maintainer of the project whether that fix type of code should be somewhere else besides the module install program.
Composer will put your files in a specified directory structure called a scaffold. The core modules will go under /web/core/modules. The contributed modules will go under web/modules/contrib. So your juicebox modules should be in web/modules/contrib/juicebox.
This is the standard layout for a composer based install. You are better off sticking with the standard layout (scaffold) because a lot of the utilities and documentation on drupal dot org will anticipate this. At the bottom of every module project in Drupal there is a releases section. For instance Juicebox has a recommended release with the following suggested line for composer:
composer require 'drupal/juicebox:^4.0@alpha'
You can use this but change the single quotes to double quotes if you are in a Windows command line.
In the project issue queue I am trying to develop instructions for setting up a content type for a Juicebox gallery. It's proving vexatious (a.k.a. difficult) because of the Chrome errors I am seeing on my local system. If Chrome has done something that "disallows" certain Javascript code and generates errors we are going to be in a world of hurt with Juicebox because we don't have access to the Javascript code to change it. But it's premature to identify this as an issue.
I'd recommend that you try to get a composer setup with the standard Drupal scaffold and practice with key Composer commands: such as composer self-update, composer validate, using the dry-run flag to get a preview without updating, etc.
Good luck.
I can confirm that the Gallery works on Firefox but not Chrome. So that's a positive step. What version of Firefox and what version of Chrome are you using? I am seeing some signs that Chrome may be making changes that could cause troubles with Juicebox but these are far from definitive right now. I have my Juicebox galleries working with Drupal 10.2.2 locally and on my hosted site and using Chrome.
What version of Juicebox are you installing? What's your composer.json require statement for Juicebox?
How are you creating your galleries? Do you use JuiceboxBuilderPro to create the gallery locally? Or how are you creating the gallery? If you are creating a content type through admin/structure and adding images it is possible to have problems depending on what field types you are using. I'm working on developing instructions for this.
Can you take a look at the juicebox.install.php program in your root Juicebox directory ... should be contrib/juicebox/install.juicebox. If you have the most recent fixes for juicebox there should be a code block at the bottom of the program that looks like this (sorry this is a bit long, but it is a critical fix)
function juicebox_requirements($phase) {
$requirements = [];
// Check on the installation status of the Juicebox library. Note that
// we do not do this check during the 'install' phase as the libraries API
// functions will not always be available then (if installing Drupal via an
// install profile, etc.).
if ($phase == 'runtime') {
// Get locally installed library details.
$library = \Drupal::service('juicebox.formatter')->getLibrary(TRUE, TRUE);
$requirements['juicebox'] = [
'title' => t('Juicebox Javascript Library'),
];
if ($library['installed']) {
$requirements['juicebox']['value'] = $library['version'];
$requirements['juicebox']['severity'] = REQUIREMENT_INFO;
}
else {
$requirements['juicebox']['value'] = $library['error'];
$requirements['juicebox']['description'] = $library['error message'];
$requirements['juicebox']['severity'] = REQUIREMENT_ERROR;
}
// Check to ensure that there are no media reference fields whose display
// configuration is invalid.
$juicebox_formatted_fields = [];
/** @var \Drupal\Core\Entity\EntityTypeManagerInterface $entity_type_manager */
$entity_type_manager = \Drupal::service('entity_type.manager');
/** @var array|\Drupal\Core\Entity\Display\EntityViewDisplayInterface[] $entity_displays */
$entity_displays = $entity_type_manager->getStorage('entity_view_display')->loadMultiple();
// Gather any fields that are configured to use the juicebox formatter.
foreach ($entity_displays as $entity_display) {
// Skip disabled displays.
if (!$entity_display->get('status')) {
continue;
}
foreach ($entity_display->getComponents() as $field_name => $component) {
if (array_key_exists('type', $component) && $component['type'] === 'juicebox_formatter') {
$juicebox_formatted_fields[] = [
'entity_type_id' => $entity_display->getTargetEntityTypeId(),
'bundle' => $entity_display->getTargetBundle(),
'view_mode' => $entity_display->getMode(),
'field_name' => $field_name,
];
}
}
}
// Check any fields for compatibility.
if ($juicebox_formatted_fields) {
/** @var \Drupal\Core\Entity\EntityFieldManagerInterface $entity_field_manager */
$entity_field_manager = \Drupal::service('entity_field.manager');
// Filter out all compatible fields.
$incompatible_fields = array_filter($juicebox_formatted_fields, static function ($field) use ($entity_field_manager) {
$field_definition = $entity_field_manager->getFieldDefinitions(
$field['entity_type_id'],
$field['bundle']
)[$field['field_name']] ?? NULL;
return !$field_definition || !JuiceboxFieldFormatter::isApplicable($field_definition);
});
// If any fields remain, they're incompatible!
if ($incompatible_fields) {
/** @var \Drupal\Core\Entity\EntityTypeBundleInfoInterface $entity_type_bundle_info */
$entity_type_bundle_info = \Drupal::service('entity_type.bundle.info');
$incompatible_field_messages = array_map(static function ($field) use ($entity_type_manager, $entity_field_manager, $entity_type_bundle_info) {
$entity_type = $entity_type_manager->getDefinition($field['entity_type_id']);
$bundle_info = $entity_type_bundle_info->getBundleInfo($field['entity_type_id'])[$field['bundle']] ?? NULL;
$field_definition = $entity_field_manager->getFieldDefinitions(
$field['entity_type_id'], $field['bundle'])[$field['field_name']] ?? NULL;
return new TranslatableMarkup('The %field_label field on the %display_label display of %bundle_label %entity_label is misconfigured!', [
'%field_label' => $field_definition ? $field_definition->getLabel() : '',
'%display_label' => $field['view_mode'],
'%bundle_label' => $bundle_info ? $bundle_info['label'] : '',
'%entity_label' => $entity_type->getLabel(),
]);
}, $incompatible_fields);
$errors_list = [
'#type' => 'inline_template',
'#template' => <<<TWIG
<ul>
{% for invalid_field in invalid_fields %}
<li>{{ invalid_field }}</li>
{% endfor %}
</ul>
TWIG,
'#context' => [
'invalid_fields' => $incompatible_field_messages,
],
];
/** @var \Drupal\Core\Render\RendererInterface $renderer */
$renderer = \Drupal::service('renderer');
$requirements['juicebox_field_formatter'] = [
'severity' => REQUIREMENT_ERROR,
'title' => new TranslatableMarkup('Juicebox field formatter configuration'),
'description' => new TranslatableMarkup('One or more juicebox formatted fields contain invalid configuration! See <a href="@change_record_url">Juicebox formatted fields can no longer be incorrectly configured by site builders</a> for instructions on how to resolve this.<br>@errors', [
'@change_record_url' => 'https://www.drupal.org/node/3403257',
'@errors' => $renderer->renderPlain($errors_list),
]),
];
}
}
}
return $requirements;
}If you have this, give it a try going to admin/extend and uninstall juicebox. You'll need: "http:/yoursite/web/admin/modules/uninstall" in the address bar. Ignore any warnings and uninstall juicebox. Then come back to admin/extend and reinstall juicebox. The section of code I quoted fixes field types that are incompatible with juicebox. I'm not sure the fix belongs in the install program but that's another issue. On my test system it gets juicebox galleries that were created through a custom content type (i.e., not JuiceboxBuilderPro) working.
I'm wondering if your statement "That site did not run at first site but after running there install again the site came to live" is an indication that the revised install program fixed up the field types in your gallery.
It is great that you have those programs you listed running on your pc. I am using Wampserver instead of Xampp. But then of course the Drupal gurus have moved on the something called ddev (which wants you to use Windows Powershell to install it. And Powershell won't even tell you what version you are running until you download separate help files). And then you'll want Windows subsystem for Linux before you can even get to ddev. Progress never stops. You can probably get by with a working Xampp for the time being.
Several community members, including myself have tried to help out in the form thread linked above. As mentioned in that thread, I can see Leo's web pages and Juicebox galleries. using a Chrome browser and I have viewed several of them in this current issue queue thread. Also can view them with Firefox.
While we (the maintainers and interested users here) are still working towards a stable Drupal 10 release of Juicebox having this current issue listed as critical is not appropriate. It really should be unable to reproduce. If further information merits it we can re-open it.
Thanks Jaypan. Aside from my previous comment "Composer is a process that doesn't happen overnight" the link you provided should help Leo. I suspect he just needs a site or site he can experiment with. I just clicked through the drupal sites he previously listed. They all look fine to me and I can see a couple of Juicebox galleries working on them.
We are still trying to finalize testing on a stable 10.x version of Juicebox but I don't see where Leo's issues affect that.
Believe it or not but I am 5 years older than you. I had an IT career but mostly in management. When I retired I learned PHP and MYSQL from a text book and wrote a web site for my bike club.
So, I have empathy for what you are going through. My Juicebox galleries work in Chrome and Firefox. The browser should (and to my knowledge does not) have any effect on the gallery display. You can see my galleries (extensive) at fkelly.org. This is all on 10.2 ... whatever the latest version of Drupal is. I also try to help out as a maintainer for Juicebox but thankfully we have someone who is more expert than I as the principal maintainer. Drupal is almost infinitely complex and we need his expertise to get us to a stable 10.x version ... though what is out there now works fine as far as I can tell.
Learning Composer and running web sites with Drupal and Composer is a process that doesn't happen overnight. That's why I recommended having a local installation so you can experiment with and just start over when things blow up.
I have viewed the galleries you initially posted in both Firefox and Chrome. I seriously doubt that the browser is causing the problem.
There are many resources on Drupal for learning Composer and using it. Ressa, VM. Gabor Hojtsy and others have contributed directions and help items. It's really not feasible to run Drupal, especially going forward, without knowing composer. I would recommend a local installation where you can experiment freely without doing damage to a production site. I know that I took like 6 months and went through at least a half-dozen site iterations to get halfway competent with composer. You've got to know how to tell what composer version you are using, how to update it, how to validate it and how to deal with problems. You have to know what composer.json and composer.lock are and to tell what programs in your composer.json are out of date and need to be updated ... and how to come to drupal dot org and get the most recent update instructions from the project (module) maintainers.
Somebody who knows what they are doing has set up your current Juicebox galleries very well. It doesn't happen by accident. I'd suggest working with them.