Aha. After much fussing, including getting xdebug running in ddev (which didn't provide an immediate solution) ...
Here is what you need for embed code on a ddev site:
--START JUICEBOX EMBED--><script src="https://compm.ddev.site/sites/all/libraries/juicebox/juicebox.js"></script><script>
new juicebox({
baseUrl : 'https://compm.ddev.site/sites/default/files/jboxgalleries/greylock09',
containerId: 'juicebox-container',
galleryWidth: '100%',
galleryHeight: '110%',
backgroundColor: '#222222'
});
</script>
<div id="juicebox-container">
</div>tailored of course to what you've named your site. This means Juicebox will run under Drupal 11.1.2 and recent changes to Ckeditor are not getting the in way. The Juicebox I'm running is 4.0.0-alpha2. Trying to synchronize the setup of a Juicebox Gallery content type (used as a location for embed code for each gallery) between a test site and a production site is kind of a p.i.t.a. but ultimately it works.
Ultimately I think we need a more robust gallery solution for Drupal going forward. The statistics we get on contrib module usage seem to be highly misleading judging by the lack of participation in the Juicebox issue queue.
Quick and incomplete update. Migrate module looks like a dead end for this purpose. Way too complicated for what we (I) need.
Issue could be with ddev or with ckeditor 5. https://www.drupal.org/project/drupal/issues/3410100 🐛 [10.2 regression] CKEditor 5 breaks when "Source"/Source editing button is added and "Manually editable HTML tags" are specified Needs review ... reading this it appears that it is a very involved ckeditor 5 issue. I think that if you have pre-existing juicebox gallery content items with embeds that activate JB gallery javascript and then you edit 'em in a ckeditor 5 environment the embed code can get broken. I think I can "prove" this by editing a gallery embed or two on my live system.
Given the lack of participation in this Juicebox gallery issue queue I wonder if anyone is still using Juicebox Gallery and intends to continue using it through Drupal 11.
I will post back if I can confirm that this is ckeditor 5 related. They are up to 102 posts in that ckeditor issue queue that I listed without a resolution ... and it's not clear if that resolution will fix our Juicebox embed issue.
I made some progress on Sunday 2/9 getting closer to the recommended format on my dev site. But I think I'll explore the migrate module so see if I can copy all instances of my JuiceboxGallery content type from my live site to my new dev site.
Experimenting with DDEV and updating to Drupal 11. This comes with ckeditor 5. Despite all the good things that ckeditor 5 is supposed to do for us, it may also disable Juicebox galleries that are linked using the recommended approach. Specifially the embedding recommendations call for putting code such as:
<!--START JUICEBOX EMBED--><script src="/web/sites/all/libraries/juicebox/juicebox.js"></script><script>
new juicebox({
baseUrl : '/web/sites/default/files/jboxgalleries/greylock09/',
containerId: 'juicebox-container',
galleryWidth: '100%',
galleryHeight: '110%',
backgroundColor: '#222222'
});
</script>
<div id="juicebox-container">
</div>
<!--END JUICEBOX EMBED-->Ckeditor seems to "squash" the embedded code. Instead of the code shown above I get code like this:
<p>
<!--START JUICEBOX EMBED--><script src="/web/sites/all/libraries/juicebox/juicebox.js"></script><script><br>
new juicebox({<br>
baseUrl : '/web/sites/default/files/jboxgalleries/greylock09/',<br>
containerId: 'juicebox-container',<br>
galleryWidth: '100%',<br>
galleryHeight: '110%',<br>
backgroundColor: '#222222'<br>
});<br>
</script><br>
<div id="juicebox-container"><br>
&nbsp;<br>
</div><br>
<!--END JUICEBOX EMBED-->
</p>
<!--START JUICEBOX EMBED-->
<p>
</p>
<p>
<!--END JUICEBOX EMBED-->
</p>This is strange. My hosted site is at Drupal 10.4.1 and ckeditor 5. My local site is at Drupal 11.1.2 and ckeditor 5. I may have missed some steps in setting ckeditor up on the local ddev based site.
I would be cautious on upgrading to the latest and greatest until we can sort this out.
fkelly12054@gmail.com → created an issue.
Thanks for all the work. Minor tweak: "ddev get ddev/ddev/phpmyadmin && ddev restart" results in
Command "get" is deprecated, use 'ddev add-on get' instead should result in
ddev add-on get ddev/ddev-phpmyadmin && ddev restart
which loads up phpmyadmin perfectly. Which finds my mysql database perfectly.
Suggest you read the issue queue for Color. There is a dev release but even that does not appear to be suitable for Drupal 11. Looks like Color was targeted at the Bartik theme, which is deprecated for Drupal 11. In the issue queue there are several posts that indicate Color may not work with Drupal 11, even using the dev release. Worth noting that the dev release is dated two years after the last stable release.
I would recommend either (a) avoiding use of the color module or (b) clarifying with the developers whether this has been tested with Drupal 11.
I will close this at your request. I can see that your "other" sites have many images and galleries working.
As a side note: since your sites seem to be "commercial" in nature, you might want to spring for the Juicebox Pro option if you intend to revisit this.
Like you @holljac I have been using Wamp (aka Wampserver) for years. I've installed many updates to Drupal core and modules over the years (from Drupal 8 to testing Drupal 11) and learned how to use Composer in conjunction with that. I've been reading how Ddev is the "way to go" and finally last week (and tentatively) bit the bullet and started with it. There is great documentation out at
https://www.drupal.org/docs/develop/local-server-setup/windows-developme... →
but your apprehensions are at least partially justified. You are not just installing ddev but also a Linux distribution and something called Docker and learning how Windows terminal and Powershell differs from the "shells" that come with WSL (Windows Subsystem for Linux) and many other nitty-gritty tasks. It took me about a day to get a core version of Drupal 11 running in WSL and to get a PHPstorm project using that Drupal 11 site working. But that's just core. My plan now is to do my contrib modules with composer requires, one by one to avoid getting stuck in dependency hell. As I do, Drupal will add 'em to my composer.json.
As Ressa says, the color module is not supported by Drupal 11. You can look at the info.yml file for any module or theme and see what is really supported. Upgrade status is not perfect. I'd tread lightly on adding contrib modules unless (a) you really need 'em and (b) you know they are compatible.
Sorry to cut this short, life calls. Good luck.
Like you @holljac I have been using Wamp (aka Wampserver) for years. I've installed many updates to Drupal core and modules over the years (from Drupal 8 to testing Drupal 11) and learned how to use Composer in conjunction with that. I've been reading how Ddev is the "way to go" and finally last week (and tentatively) bit the bullet and started with it. There is great documentation out at
https://www.drupal.org/docs/develop/local-server-setup/windows-developme... →
but your apprehensions are at least partially justified. You are not just installing ddev but also a Linux distribution and something called Docker and learning how Windows terminal and Powershell differs from the "shells" that come with WSL (Windows Subsystem for Linux) and many other nitty-gritty tasks. It took me about a day to get a core version of Drupal 11 running in WSL and to get a PHPstorm project using that Drupal 11 site working. But that's just core. My plan now is to do my contrib modules with composer requires, one by one to avoid getting stuck in dependency hell. As I do, Drupal will add 'em to my composer.json.
As Ressa says, the color module is not supported by Drupal 11. You can look at the info.yml file for any module or theme and see what is really supported. Upgrade status is not perfect. I'd tread lightly on adding contrib modules unless (a) you really need 'em and (b) you know they are compatible.
Sorry to cut this short, life calls. Good luck.
Puzzled, so rereading your initial post. It says "Went to the Manage Display page for our featured media paragraph type. Changed the format to Image with Dimensions and set it to Juicebox medium."
I don't see an option in format for Image with Dimensions. I believe that the format would need to be one of the Juicebox Gallery formats. Sure enough if I set the format to "original image" I no longer get a Juicebox gallery (only one of the images is shown with no thumbnails). If I go back into Manage Display and reset the format to juicebox gallery, I get a juicebox gallery again (with thumbnails shown and clickable).
Maybe give that a try. ?
Thanks for the update @jsimonis.
To start at the end: here is a link to a gallery based on media images that I created on my live site.
https://fkelly.org/web/node/266
It's a real Juicebox gallery with all gallery features.
Next, here is there is a png file for the content type setup showing the manage fields screen. Then a png for manage display and finally a png for the screen where I add the images to the content type (capture.png). The link (above) shows how the completed gallery is presented on the web page. In manage display I have tried with image style set to Juicebox Pro but also just plain Juicebox Gallery. Both work okay.
I don't think that having the Juicebox Library set to Lite 1.5.1 should have any way to affect this but I don't have any way to test that.
Sorry about the formatting issues with my post. Maybe try adding the images without them being in a paragraph. This was my first effort at using the field formatter and it worked pretty much right away. I can see that you have the "raw" images on your page: maybe try just adding them as "instances" of image fields (i.e., setting allowed number of values to unlimited) and see if that works.
Thanks for the clarification. I had not used the field formatter previously so I used a spare content type named Experiment on my "live" web page where I have many uploaded galleries. I read through and followed the documentation that Rjacobs provided oh so many years ago ... located at
The result you can see at:
https://fkelly.org/web/node/267
I have 4.0.0-alpha2 of the Juicebox module loaded.
The content type, which I named Experiment has one field named Image field for gallery (sorry for my lack of imagination) and allows for an unlimited number of values ... alt field enabled. The documentation page kind of recommends using media items but I haven't used many of those and have many "normal" image files lying around that are not media items.
Sorry for formatting issues in this post, don't have time to be capturing png. files for display here.
Field Label Format
image field for gallery Above Image style: Juicebox medium (1024x1024)
Thumbnail style: Juicebox small (800x800)
Caption source: File - Filename (processed by fallback text format)
Title source: Image - Alt text (processed by fallback text format)
Additional Juicebox library configuration options may also be set.
Having done that the Juicebox gallery seems to work as shown in the link at the top of this post.
Do you have the gallery embedded in a content type following instructions on the project page? For instance, on my sites I have created a Juicebox gallery content type. Here is what's in the view source of one of those content type items:
<script src="/web/sites/all/libraries/juicebox/juicebox.js"></script><script>
new juicebox({
baseUrl : '/web/sites/default/files/jboxgalleries/greylock10/',
containerId: 'juicebox-container',
galleryWidth: '100%',
galleryHeight: '110%',
backgroundColor: '#222222'
});
</script>
<div id="juicebox-container">
</div>When I click on the url for that content type item (preferably from a menu) it will find a greylock10 xml file that is in the location in the baseUrl and run it through the juicebox.js program that's in the first line of the code I listed. There has to be a connection (association) between the juicebox.js file and the xml file for the gallery to "work". Otherwise you just have a list of images ... which is what it appears that you have now.
Today, 1/27/2025, I finally got a "clean" run of coder/PHPCS on my local Wampserver system ... both with standard=Drupal and standard=DrupalPractice. That is one step towards resolving all coding standard violations.
Next, I am going to do some functional testing on my local system, which means first copying some Juicebox galleries from my so-called "production" system at fkelly.org and trying out all the Juicebox functionality that I've used.
Quite honestly there is a code "stench" (for want of a better word in the whole src/controller directory). Tnere are even comments in the 7+ year old code that indicate the original author may have thought the code was not / or even may never be used. Just for instance see the xmlcontroller function in JuiceboxXmlControllerBase.php which says outright:
// If we have xml-source query parameters this indicates that the XML can
// probably not be generated here from scratch. Instead, we must depend on a
// sub-request to another Drupal path (e.g., the gallery page) and search
// for embedded XML there. This is an experimental method for special cases.
I suspect that if we had a way to determine whether the code was reachable, we might be able to eliminate a bunch of "junk". But, with thousands of possible Juicebox users and no way to tell who uses what or how often, that's a perilous step to take.
I will report back.
I've been using a local Wampserver instance with code in PHPstorm to debug Juicebox '4.0.0-alpha2' I realized that I was trying to use my local site for conflicting purposes (I was also looking at alternatives for photo galleries besides Juicebox) and was experimenting with alternative themes. So I bit the bullet and set up a 10.4.1 Drupal site just for Juicebox using what was essentially '4.0.0-alpha2' Plus ... plus referring to PHPstorm based changes to the code. All went "swimmingly" well until I tried to clear cache on the new local site and got:
( ! ) Fatal error: Declaration of Drupal\juicebox\Controller\JuiceboxXmlControllerViewsStyle::access() must be compatible with Drupal\juicebox\Controller\JuiceboxXmlControllerBase::access(): bool in C:\webpage\compg_7\web\modules\contrib\juicebox\src\Controller\JuiceboxXmlControllerViewsStyle.php on line 63
Using suggestions from Phpstorm I was able to at least temporarily suppress this error. However this led me to a 7 or 8 year old thread on the issue queues
https://www.drupal.org/node/2849674 →
which basically told me that the beginning section use statements in the viewstyle program may be problematic. And, from working recently with the src/controller code directory in Juicebox I am not sure that this whole section of Juicebox code does anything useful.
In the original Juicebox code, some 10 years ago, the basic thought (I believe) was that you'd build your galleries outside of Drupal using JuiceboxBuilderPro software on a PC or Mac. Then upload the xml files, which contained "specs" or "options" for a Gallery and then a list of graphics (jpg's usually) files to be processed by the Juicebox.js file. After that, I suspect, it was thought that "maybe it would be a good idea to build the xml file totally within Drupal". I'm not sure if anyone ever used those capabilities but there are some complex programs that allegedly make it possible.
So basically, I can "make" the error I showed above go away but I'm not sure after reading through 2849674 that it's worth the effort. And then, if you look at the comment in JuiceboxXmlControllerBase. php (line 91 and following):
public function xmlController(): Response {
$xml = '';
// If we have xml-source query parameters this indicates that the XML can
// probably not be generated here from scratch. Instead we must depend on a
// sub-request to another Drupal path (e.g., the gallery page) and search
// for embedded XML there. This is an experimental method for special casesIt makes me wonder if we aren't chasing our own tail here a bit, trying to fix code that's never even used. This may not be definitive but PHPstorm seems to thing that the function xmlController() is never even used.
I use a large, inexpensive hosting service named Inmotionhosting. They use Cpanel. Cpanel comes with a terminal application. When you are signed into Cpanel you can access terminal (no ssh). Change directory to public-html and run composer. Also drush. Works fine. Google "cpanel terminal" and you'll see that terminal comes with cpanel. I guess some hosts might disable terminal.
The direction that Drupal is going you will need a host that gives you access to composer.
Thrashing away at this as time permits. Using the code that was recently uploaded (committed) to "
Issue #3433346: Automated Drupal 11 compatibility fixes for juicebox" I'm fairly sure we still have Drupal calls should be avoided in classes, at the pasted results from PHPCS below show. In other words we don't have all coding standard violations resolved.
C:\webpage\compg_6>phpcs --standard=DrupalPractice web\modules\contrib\juicebox
FILE: ...\web\modules\contrib\juicebox\src\Controller\JuiceboxXmlControllerBase.php
--------------------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
--------------------------------------------------------------------------------
124 | WARNING | \Drupal calls should be avoided in classes, use dependency
| | injection instead
--------------------------------------------------------------------------------
FILE: ...ontrib\juicebox\src\Plugin\Field\FieldFormatter\JuiceboxFieldFormatter.php
--------------------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
--------------------------------------------------------------------------------
344 | WARNING | \Drupal calls should be avoided in classes, use dependency
| | injection insteadLooking for a fix for this, I'm fairly sure that the code in JuiceboxDisplayStyle.php may provide a solution we could adopt. That program has a " public static function create(ContainerInterface ... " which should provide access to services that can be injected. I will see if I can tackle that in the next few days modeling fieldformatter and xmlcontrollerbase display style after those.
For what it's worth, it might save time to run coder/phpcs locally before uploading it the Drupal site? If it doesn't pass phpcs standards locally it's not going to pass in the gitlab test runs.
Just an update. Two days ago I thought I had PHPCS using both standards down to one "Drupal calls should be avoided in classes" error and that I could patch together code from Juiceboxformatter.php into JuiceboxFieldFormatter.php to resolve that. After doing that it seemed to remove the errors from Juiceboxfieldformatter when using --standard=DrupalPractice. But then I reran PHPCS using standard = Drupal and came across a whole bunch of formatting errors that I had reintroduced by making some so-called minor tweaks that PHPstorm pointed out. Sorry if this is getting deep into the weeds for some, but I wanted to explain part of why these updates are taking so long.
The next day, trying to deal with the new "standard=Drupal" errors I somehow reintroduced similar errors in JuiceboxFormatter ... which had been resolved (allegedly) for some time.
Working through the code it appears that we are also dealing with a lot of "technical debt" since this module has not had regular, ongoing attention from a fully qualified Drupal developer (which I am not) for years. Luke has provided patches that have made the product work with Drupal 10 (and I think with Drupal 11 though I've not had time to test that). But there are all sorts of errors in the code such as variables that never get assigned a value and code that attempts to filter out html codes that should not be in a completed xml file that is used by Juicebox. PHPstorm points out obsolete or incomplete html codes in that PHP code but it can't tell us how to fix them.
And, just to emphasize the technical debt further, when I looked up "trustedcallback" to understand more about how it worked, it appears that the developers and core committers are busily in the middle of deprecating it and subtituting in a slightly different approach. See:
https://www.drupal.org/project/drupal/issues/3274867 📌 Add TrustedCallback attribute Fixed and related issues.
I will continue doing what I can to produce a juicebox version that will meet all standards tests for Drupal 10 and 11 and buy us more time. But I increasingly think it is time to move on from Juicebox as a whole and find a slideshow approach that is fully supported and based on media files rather than a bunch of unmanaged files uploaded by FTP.
A question for the user base: does anyone out there use Juicebox features that allegedly build xml files containing sections that have the options for a gallery preceding sections for images and sections listing the thumbnail files? I ask because there is a lot of complicated code that alleges to do that and I'm not sure it's ever used.
I'd look on the commerce ticketing module page and see if they don't have a version that supports at least Drupal 10.4. Oh, I looked on the module page. They have a dev release that looks like it might support 10.
composer require 'drupal/commerce_ticketing:2.x-dev@dev'
But you have to deal with the same caveat as you do for all dev releases ... not recommended for production. Reading quickly through the issue queue it appears that support for this module is at best "iffy". You'll have to do your own research and I'd recommend you try it on a test or local system.
Just to supplement (not contradict) what Jaypan said ...
I use a large hosting provider, InMotionHosting. They work well for me but I'm not endorsing any particular hosting here. Five or six years ago they hesitated to provide Composer. Then their hesistancy evaporated, possibly because the Composer folks improved the efficiency of the program. InMotionHosting, like many hosting providers uses a set of programs called Cpanel. And Cpanel provides "terminal". Basically terminal works the way the command prompt does on Windows. No ssh needed. You just bring up terminal after you sign in to Cpanel, change into the public_html directory make sure you are using the latest Composer version and do "composer outdated 'drupal/*'. Then proceed with your updates. There are plenty of instructions on Drupal.org for doing this. I usually update a local (Wampserver) copy of my site first just to see if there are any problems.
Google or otherwise search "cpanel terminal" to see what it has to say. Your situation may be unique in some way I can't imagine, but otherwise I'd only use a hosting service that provides a terminal session and allows composer. In most situations it is a few minutes task to update a site through Composer.
Building on #29 I decided to look at JuiceboxFormatter.php and see if anything we did in there would help with the Juiceboxfieldformatter.php problems. Voila I saw that we had added some trustedcallback code after the create statement in juiceboxformatter. More specifically:
public static function create(ContainerInterface $container, array $configuration, $plugin_id, $plugin_definition): FormatterBase|JuiceboxFieldFormatter|static {
// Create a new instance of the plugin. This also allows us to extract
// services from the container and inject them into our plugin via its own
// constructor as needed.
return new static($configuration, $plugin_id, $plugin_definition, $container->get('entity_type.manager'), $container->get('link_generator'), $container->get('request_stack'), $container->get('juicebox.formatter'), $container->get('renderer'), $container->get('entity_display.repository'));
}
/**
* {}
*/
public static function trustedCallbacks(): array {
return [
'preRenderFieldsets',
];
}
/**
* {@inheritdoc}
*
* @throws \Exception
*/
After putting that in, I reran PHPCS standard=DrupalPractice and the "\Drupal calls should be avoided in classes, use dependency
injection instead" error message went away. I need to try this on a website and see if it actually works outside of PHPCS.
This all is beyond my level of expertise and all I'm trying to do it get Juicebox running with Drupal 10 and 11 to give people (including myself) more time to find an alternative.
I have been using PHPCS locally, with the Juicebox code in a PHPStorm project that is consistent with 4.0.x-dev (or started that way). I made changes that resolved all PHPCS issues using --standard=Drupal. However --standard=DrupalPractice still throws an error no matter what I try. E.g.,
:\webpage\compg_6>phpcs --standard=DrupalPractice web\modules\contrib\juiceboxFILE: ...ontrib\juicebox\src\Plugin\Field\FieldFormatter\JuiceboxFieldFormatter.php
--------------------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
--------------------------------------------------------------------------------
332 | WARNING | \Drupal calls should be avoided in classes, use dependency
| | injection instead
--------------------------------------------------------------------------------
The code I'm looking at is in;
:\webpage\compg_6>phpcs --standard=DrupalPractice web\modules\contrib\juicebox
FILE: ...ontrib\juicebox\src\Plugin\Field\FieldFormatter\JuiceboxFieldFormatter.php
--------------------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
--------------------------------------------------------------------------------
332 | WARNING | \Drupal calls should be avoided in classes, use dependency
| | injection instead
--------------------------------------------------------------------------------
and I've run line by line comparisons between that and the code starting from 4.0.x. Looking through some issue logs, we had similar problems a year ago with code in Juiceboxformatter.php that related to the layout of the services.yml file. Those were resolved and I'm not aware of any recent changes to services.yml.
Don't try. Using composer is required. There are dependencies between and among modules, themes, core and programs in the vendor directory that can only be managed by Composer.
A few years ago hosts had the excuse/rationale that Composer was too resource intensive. That excuse is gone. Users objected to the learning curve. That won't cut it any more either.
There is still a learning curve. I'd recommend practicing on a local site.
I have run all the code in Juicebox through PHPCS locally. Using the latest version of coder. I also applied many changes suggested by PHPstorm ... most of them cosmetic and/or spelling type "things".
I don't want to mess up the merge process so would like some direction. Where should I put the changed files. A new merge? And for what version?
I can see that there are other tests that we have failures on besides PHPCS, but this should be a start. Running "C:\webpage\compg_6>phpcs --standard=Drupal web\modules\contrib\juicebox" from the DOS prompt comes back clean.
The program named JuiceboxGalleryInterface was a real nightmare. Some of the code in it was deprecated by PHP changes about 8 years ago.
I've been running phpcs locally and using its automatic fix feature (phpbcf option) and making the changes locally in my PHPstorm copies of the files. PHPstorm has a LOT of other suggestions too and I've been making them.
The JuiceboxGalleryInterface.php program has been giving me fits. I've literally spent hours on it. PHPCS doesn't recognize the doc comment at the top. If I let it (phpcs) try to fix it then it doesn't recognize its own fixes as valid. I've looked at how other Drupal programs handle this and don't get any bright lights shining on what to do. Literally spent 2 to 3 hours this morning on a half-dozen lines of code and probable a dozen approaches. Looked in the Drupal coder issue queue and the usual search engines.
From some of what I've fixed it seems like there are sections of code that go back to 2015 and Drupal 7 days. I think I've found fixes for those but am not sure they are even being used anymore.
Not sure if you @koustav_mondal are actively working on this ... if so we should coordinate efforts. If I can get the JuiceboxGalleryInterface program fixed I will be just about ready to push something up for a merge. This only takes care of a section of the test failures shown through various code inspection tools.
Thanks Avpaderno. It's no big deal. I was kicking myself for replying to a closed issue without noticing that it was closed.
Bigger fish to fry.
Not sure what the point of changing the issue summary was (or is). The 11 year old tutorial in #5 and even the version of Drupal and the version of Juicebox mentioned in the tutorial are not going to get much support now. The process for installing the Juicebox Javascript library is detailed in the Juicebox project page itself. Project support is difficult enough without trying to support years old versions of Juicebox or outdated Drupal versions.
In the year 2000, detection of the Juicebox library was modified to NOT rely on a separate libraries module but instead put inside the Juicebox module itself. If you are working with a recent Drupal 10 version and either the juicebox 4.0.x-dev or recently released juicebox 4.0.0-alpha2 version and have followed the Library Instructions in the Juicebox project page then please post the details of what error messages you are seeing as well as the Juicebox and Drupal versions you are using and we'll try to sort things out.
Updated my "production" site (fkelly.org) to 4.0.x-dev alongside updating it to Drupal core 10.4.0. The good news is that the update "generally" worked. Afterwards I manually compared code. I thought it was strange that the code in my hosted fkelly.org site, the display of modules in the "extension" screen and even drush pml didn't show a version for Juicebox. On my local system there is a version of info.yml:
# Information added by Drupal.org packaging script on 2024-12-19
version: '4.0.0-alpha2'
project: 'juicebox'
datestamp: 1734574881Looking at info.yml files for other contrib modules, the version info seems to be present. So I'm not sure whether this is a problem or not.
At any rate the version info is missing from the code in the hidden branch juicebox-3433346. I guess that if the packaging script is going to add it then we don't want it in the file? Otherwise, the coding changes in the recent commits are now on my production system. And Juicebox 4.0.x-dev seems to work in testing I've had time for so far. At any rate, there is no version in the hosted version of the info.
I haven't gotten to testing any Drupal 11 versions yet. That may take a while since I need to install it locally.
copy and paste gone awry? From #12?
require drupal/colorbox:dev-4.0.x
composer require 'drupal/juicebox:4.0.x-dev@dev' You mean?
I used the latter earlier this morning and it installed the latest Juicebox just fine. Unfortunately my local (Wampserver) test site has some other problems so I have work to do before I can test.
Having the composer install process available to all of us is a great convenience. Thanks Luke!
I can see that you have a gitlabci.yml in the 4.0.x-dev version and that it runs the tests okay. So, if it helps, I'll change the status to rtbc. If I understand the process correctly we need a gitlabci.yml that updates the one I did about a week ago in the 4.0.x directory.
Educate me if I misunderstand this process and I will be as much help as I can. If we can get a working 4.0.x version (or whatever we call it and including Drupal 11 changes, I can run it locally for further testing). Looks like 10.4 is released and I'll update my sites to that (both locally and live (hosted) and give the latest Juicebox version a try there.
Coming from the Juicebox module for slideshows where jpg files for images where ftp'd to sites/files/... directories that were built to contain juicebox galleries (lists of jpg files) and an xml file with a list of slideshow options went along with the jpg files. The xml file was used by an external javascript program to present the galleries. The combined xml file and jpg's were embedded in a content type item and then a menu item pointed to the resulting "gallery". In my case there are well over a thousand jpgs in over 100 galleries.
It's pretty apparent that all new slideshow generating software on Drupal is using media rather than plain jpg and xml files. So I need (and have been experimenting with) this file_to_media module to aid in this effort.
The problem is that the view, while it finds existing files and lists them only allows one media item at a time to be generated. And it requires an alt field to be input for each one. Perhaps worth noting that I understand the accessibility concerns that underlie this requirement, but my galleries are replete with captions that were created and carried forward from the initial Lightroom/Photoshop copies of the carefully curated photos.
My request is that there be an option to bypass the alt field input requirement and just "batch process" the media field process to create one media field for each pre-existing image file.
fkelly12054@gmail.com → created an issue.
In order to make tests run, we need to integrate gitlab-ci.yml into the branch we are trying to test. A few days ago I put a gitlab-ci yml into the 4.0.x branch but that's not sufficient. We somehow need to replace the drupalci.yml file (Now obsolete) with a gitlab-ci.yml file in the branch we are trying to use for the update.
I am not familiar with all the steps and "privileges" needed to do this. The code that milan, shashi and manishaity are proposing may do this but we need to correct an up-to-date gitlabci.yml file to make it happen.
I will ping (email) our senior maintainer, Luke, to see if he can help move this along.
Personally I am spending all my Drupal time trying to find/develop an alternative recommended approach to using Juicebox for slideshows within Drupal. Nearly 10 years ago the Drupal wizards switched over to using a media module instead of just ftp'ng jpg and xml files up to sites/files. All the recent developments for slideshows are using media. I think that the patches now pending may get us to a stable Drupal 11 release but I recommend that we plan to make Juicebox obsolete after that.
Sorry for the delays and for my lack of expertise.
fkelly12054@gmail.com → made their first commit to this issue’s fork.
I would suggest using entity usage here.
I suspect that there should have been a link with the word "here"?
And no big deal and I hope you don't mind me piggybacking on a closed issue but in
https://www.drupal.org/project/file_to_media/issues/3211648 →
where the user had problems enabling the module and the solution was to clear cache, yesterday (12/15/2024) I found that it was also necessary to go to the extend screen and enable the module. I suppose Drush could have enabled it too, but just clearing cache didn't do the trick. (I had run update.php after the composer install but that didn't enable the module either).
Preaching to a very limited size choir that has the authority to make changes to the Drupal dot org home page, unfortunately. The Drupal CMS for ambitious marketing or whatever they are calling it on a given day. I suspect that if they could eradicate all beginning users they would.
All they need is a link to drupal.org/forum in the top line of the Drupal home page and all would be fine. They could continue to ignore the forums, (and not put any resources into them) as they have for years. How about letting users post a file to a forum discussion like they already can to the issue queues (and to Slack for that matter)? How about letting users filter results by date so that if we want to filter out all posts related to Drupal 6 or 7 we could do so easily. Those two tasks would take maybe a day or two. Or maybe create an read only archive area "/forum/archive" for everything Drupal 7 and older (given that Drupal 7 will not be officially supported after January 2025?). That might take a little longer. Then include date filtering in what remains.
Or more subversively, how about encouraging everyone who visits these forums to post in the issue queues? That might incentivize the developers and committers to devote a few resources to the forums, just to get us off their backs.
Received the following in email. December 8, 2024
I am moving a website from Drupal 7 to Drupal 10.
I have a form where I add an image to the front of a Juicebox gallery (taking only the first 42 images) in a node with the following old code:
$imageinfo = image_get_info($newfile->uri);$newimage = array(
'fid' => $newfile->fid,
'uid' => $newfile->uid,
'filename' => $newfile->filename,
'uri' => $newfile->uri,
'filemime' => $newfile->filemime,
'filesize' => $newfile->filesize,
'status' => $newfile->status,
'timestamp' => $newfile->timestamp,
'rdf_mapping' => Array(),
'alt' => $form_state['values']['user_name'],
'title' => $form_state['values']['title'],
'width' => $imageinfo['width'],
'height' => $imageinfo['height']
);$update_node = node_load(278);
array_unshift($update_node->field_picture['und'], $newimage);
$update_node->field_picture['und'] = array_slice($update_node->field_picture['und'], 0, 42);
node_save($update_node);I wrote the code over 10 years ago. I can't work out where to find the equivalent information to update the code. I have successfully installed the Juicebox module and have a working gallery on a node of the test site and a form that uploads an image file, but that's about it.
Can you help?
With best wishes and very many thanks,
Jane"
Requests need to be put in the issue queue.
It is not clear from this request what needs to be done. Images that are displayed in a gallery are listed in an XML file, which in turn is embedded in a content type item. A Juicebox javascript program which you have linked to the Juicebox module code in turn processes this xml file and displays a gallery. There is a lot of documentation for this process in the Juicebox "project" on Drupal.org (where you are viewing this post). "Normally" and most reliably, the list of gallery items is kept in an xml file which is produced on your computer using the JuiceboxBuilder program. Instructions for this are in the project too. Support for the JuiceboxBuilder program has been moved around (it has always been "outside" of Drupal) several times. Support for JuiceboxBuilder in turn depends on code originally developed by Adobe (Adobe Air). I'm not sure what the status of that is.
Here is the first few lines from a sample xml file:
<?xml version="1.0" encoding="UTF-8"?>
<juiceboxgallery
enableAutoPlay="true"
autoPlayOnLoad="true"
>
<image imageURL="images/001.jpg"
thumbURL="thumbs/001.jpg"
linkURL="images/001.jpg"
linkTarget="_blank"
sourcePath="D:\Pictures\2009 to 2010 pics including at sharis\001.jpg">
<title><![CDATA[001]]></title>
<caption><![CDATA[]]></caption>
</image>
<image imageURL="images/002.jpg"
thumbURL="thumbs/002.jpg"
linkURL="images/002.jpg"
linkTarget="_blank"
sourcePath="D:\Pictures\2009 to 2010 pics including at sharis\002.jpg">The imageurl, thumburl are really the key fields ... the sourcepath doesn't matter and will be different depending on where your site is located (hosting, local site etc.).
Theoretically, you could edit the xml file and add images "manually". That process might be "fraught" as we say.
But it could be that is not what you are after. I can't tell from your email.
Even though I'm personally listed as a maintainer, I am concentrating my efforts at finding a different way to do photo galleries ... different from Drupal. I spent yesterday morning seeing if I could use Google photos for this purpose. The galleries themselves work okay, however the PH.D computer scientists at Google have totally screwed up the way captions work ... or I should say don't work. I can link a working Google photo gallery to an article content type on Drupal and view it okay ... but without captions. This is a show stopper, at least until I find a work around.
I have looked at alternatives in the contrib module area of Drupal. None of them are well maintained or ready for prime time, IMHO.
Maintaining contrib modules here is difficult. The ground is constantly shifting under a contrib maintainer's feet. Code that worked fine gets deprecated and needs to be modified, tested and set up for users to download. The testing process itself changed radically from Drupal 10 to Drupal 11.
If I find a reliable alternative I'll post it here. You can see a work in progress at:
https://www.drupal.org/project/vvjs →
and some testing I am doing there. It is not ready for prime time either but it is a much simpler approach than Juicebox without the "extended" mess of dependencies inherent in Juicebox.
fkelly12054@gmail.com → created an issue.
Toggling the section
{# Only show navigation elements if there are more than one slide
{% if total_slides > 1 %}#}
at the bottom of views-view-vvjs.html.twig that turns off formatting for slideshows seems to work for turning the formatting on and off seems to work on my local system but I doubt that it's the "correct" solution. It gets down to a discussion of use cases and how people want to use the vvjs module. In my case I would almost always just present one slideshow (that is is one set of slides from one of my gallery content items with one specific (and unique) title field). And users would initiate this from a menu item somewhere on the site that would link to a contextual filter that uses that title field as a link ... probably with a URL alias to that content type item.
But I can see "use cases" where people might want several slideshows from one running of the view. Probably toggling the formatting on or off based on the number of slides is not the most "robust" approach.
It appears that you gave the middle finger to all your beginner users by removing the Drupal Forums without any notice or mention. They were a long neglected feature on the Drupal dot org site but still sometimes useful to beginner to intermediate users.
I can understand getting rid of them, but perhaps tell people and maybe have an archive somewhere?
On further testing: pretty sure that putting in a filter for the Slideshow title breaks the formatting for numbers, dots, arrows etc. So, if in your filter criteria you have
Filter criteria
Addfilter criteria
List additional actions
Content: Published (= Yes)
Content: Content type (= gallery)the slideshow will work properly but if you add in a filter on the title as per:
Filter criteria
Addfilter criteria
List additional actions
Content: Published (= Yes)
Content: Content type (= gallery)
Content: Title (= Avignon)
The slideshow formatting features get suppressed. You still get a set of images that belong to the gallery content type with the title of
"Avignon" but no formatting features. Interesting: when you go to set up the filter criteria in the view the list of filters looks like:
"Update Title Title Content
Update Title (field_title) Title (field_title) Content Appears in: gallery."
In structure/content types the Title field only appears in my gallery content type and has the machine name "field title". The title field itself is only shown in the view as being part of generic "content" ... but that field ("title" as opposed to "field title") has to be used as a filter and it returns the slides (images) that belong to the correct gallery (but of course causes problems, somehow) with the slideshow formatting.
For practical purposes I would almost always want to present slideshows for one title at a time.
... Looking at the code in vvjs.js it appears that the variable totalSlides might have an ambiquous meaning when the user is trying to present several slideshows at once. When I don't filter by a slideshow title, I get several slideshows presented consecutively with numbers, dots and arrows working properly for each. But when I do filter, the slideshow formatting gets lost. Retaining the formatting is good but I don't think that there is really a use case for presenting a bunch of slideshows consecutively with one "running" of the view. If that makes any sense.
On further testing: pretty sure that putting in a filter for the Slideshow title breaks the formatting for numbers, dots, arrows etc. So, if in your filter criteria you have
Filter criteria
Addfilter criteria
List additional actions
Content: Published (= Yes)
Content: Content type (= gallery)the slideshow will work properly but if you add in a filter on the title as per:
Filter criteria
Addfilter criteria
List additional actions
Content: Published (= Yes)
Content: Content type (= gallery)
Content: Title (= Avignon)
The slideshow formatting features get suppressed. You still get a set of images that belong to the gallery content type with the title of
"Avignon" but no formatting features. Interesting: when you go to set up the filter criteria in the view the list of filters looks like:
"Update Title Title Content
Update Title (field_title) Title (field_title) Content Appears in: gallery."
In structure/content types the Title field only appears in my gallery content type and has the machine name "field title". The title field itself is only shown in the view as being part of generic "content" ... but that field ("title" as opposed to "field title") has to be used as a filter and it returns the slides (images) that belong to the correct gallery (but of course causes problems, somehow) with the slideshow formatting.
For practical purposes I would almost always want to present slideshows for one title at a time.
Resuming experimentation. If I start with a "fresh" copy of the view provided by the vvjs module named VVJS Example I can successfully generate a slideshow using the formatting features provided by the module ... i.e., arrows next to slides (Slide Navigation Arrows), the slide indicators (numbers or dots), the time in seconds for each slide to show, etc.) But at some point, when I try to set up filtering ... say to filter on a specific title of a gallery item, all the formatting gets "lost" and all I get is a display of slide images with none of the vvjs formatting applied.
Update: going back thru the video intro. to this and working back and forth between my live site and my local site, I have made some progress in formatting the slideshow produced by the view in the vvjs format.
I will post again when I have the time to follow up more. It will be a few days before I can get to it. Thanks for your patience.
Found 1.0.9 this morning. Updated to it and enabled it locally. Uploaded 1125_1.09. png file showing results. Still not getting vvjs formatting with numbers or dots next to images to take effect. The png files shows both the menu with contextual links for gallery content types I'm trying to use and a truncated display of the images. The images themselves, both in the view preview screen and on the menu screen just display vertically concatenated one above the next.
For what it's worth, I updated vvjc this morning to 1.08 and the formatting for that appeared to work a little better. However, vvjc is not what I'm after right now. I have tried all the options I can see for the vvjs to set the formatting for numbers and dots and none of them seem to be being applied.
The approach being taken in vvjs is just what I need ... especially with no dependencies on other code.
The reversions shown in:
https://git.drupalcode.org/project/vvjs/-/commit/d16924b6f3e25df405c845c...
do not seem to be part of 1.0.8 but are present in the dev release. I have the dev release installed on my local system. But the slideshow with the "dots" or numbers reflecting the slides does not work properly.
Slideshow appearance features are not working with the VVJS example view. See the file named capture_album.png in files. I can correctly generate a view of a particular named "gallery" content type (in this case using the filters content type = gallery and title = 2009-10) but the slideshow formatting (dots, numbers etc) is lost. It looks like the reversion may have been part of a work in progress?
I experimented with manually reverting the vvjs.js and vvjs.css changes that were made on November 18. I seem to be able to restore some of the formatting and I can restore the working of contextual links embedded in a menu but all is still not good. The formatting with dots and numbers doesn't work. Since I don't fully understand the code, that's not surprising and why it is best kept on my local system for experimentation. The link out on my "production system" (using vvjs 1.08) works with a contextual link to a particular gallery but loses the formatting that was present in 1.0.7.
In issue https://www.drupal.org/project/vvjs/issues/3480190 🐛 Bugs with vvjs slideshow Active I posted several screen captures of slideshows developed using the VVJS module. Most of the features in the VVJS module seemed to be working properly. I created Gallery content types which contained multiple images and could use the formatting features built into the module and the associated view to display the module. I could set up a menu with a links to the slideshow(s) and then click on the link and see a properly formatted slideshow (with dots or numbers to help scroll through the images). I thought I was ready to promote this to testing on my "real" site where I have many menus and slideshows and where I could demonstrate progress more publically (than just with screen captures). This was going well: I could flip between my Wampserver site (local on my PC) and my hosted production site (fkelly.org). I even created a test gallery content type and modified a menu item to point to that. It seemed to be working well, though needing refinement. You can even see a primitive version at:
https://fkelly.org/web/avignon
But somewhere in the updating process relating to Drupal 10.3.7 and 10.3.8 and 10.3.9 (all of which came out within a week and which fouled up Drush for me) and vvjs 10.0.8 ... the special formatting features of vvjs got lost.
What you see in the link I posted is basically a series of images formatted by the vvjs view. The formatting (dots or numbers) that lets you step through the slides is gone.
I will go back to my local system and see if I can find any solutions or determine what I might have done wrong. But the formatting, for now is also lost on the local system. I may even revert back to vvjs 10.0.7 and see if that restores things.
fkelly12054@gmail.com → created an issue.
Have a look at:
https://www.drupal.org/project/drupal/releases/10.3.8 →
The core folks have apparently fixed the problems addressed in this forum thread. Get familiar with the core isssue queues especially after new releases "hit the street".
https://www.drupal.org/project/issues/drupal?status=All&categories=All →
I usually wait a few days before upgrading to a new release to see if their are any new pain points. The developers and release managers do a great job but occasionally a bug slips through. Then you find a 10.3.8 release a few days after a 10.3.7 release. As an "end user" and not a developer, save yourself some pain and wait a week after a release then read the issue queues carefully and make sure the release was ready for prime time.
Re. updating by ftp (and tar.gz) see:
https://www.drupal.org/project/drupal/issues/3285191 🌱 [meta] Deprecate tarballs, because they are incompatible with Composer-managed dependencies, Automatic Updates, Project Browser, and release managers' health Active
the tar.gz files are on their way out and composer is in. This has been happening for years and is very near to being official policy. Read the issue queue for yourself.
I got caught by this problem/error in trying to run and revise a custom subtheme of a contrib theme (Solo). All done on a local site. I searched in PHPstorm and found that I could apply the patch from Git / Patch / Apply patch from clipboard after copying the patch code from #26. An afternoon of pain quickly disappeared. Hopefully the code, or a version of it, gets applied to a future core version.
Thanks to those who contributed.
I loaded up the dev. release ... thanks! My slideshows (two of them so far) are working well on what is very much a test page. I can create a link to them on a menu and then whichever link is chosen will show the appropriate slideshow using the view and contextual filters.
I am working towards having the Solo sub-theme be the primary theme code that I use but I need to get the appropriate menu code in the right places. Traveling for the next week so progress will be slow. At this point I have very little use for Hero slideshows although I know they will be popular in some "use cases".
For what it's worth. I have been working on this. I had to transition my local web site (running on wampserver) over to using the latest Solo version and make the transition to using a subtheme (using tszl as the name) in a custom directory and get a primitive but semi-functional block layout working. Then make the vvsj view respond to contextual links so that I could summon up one of two galleries I have running, from a menu and depending on user input on the menu. This works using the advanced contextual links on the views page so a user can select whichever (of the two I currently have running) gallery they want. The goal is to have many galleries that users can access and view through a menu. It is a proof of concept at this point but it seems to work ... I wasn't sure that I could link a menu through a view to a user-selected gallery.
The slideshow from view png file I uploaded shows this "in action". The view part is on the left and the slideshow that is selected from this view is on the right. It is cycling through the slides.
Obviously there is a lot of work to get 100 + galleries working this way, but since I already have the jpg files organized in a directory structure that corresponds to the gallery structure I want, it is not insufferable.
There is an extensive discussion (unresolved at this time) at https://www.drupal.org/project/drupal/issues/3280848 🐛 Shortcut links without a title cause deprecation notices. Needs work
with regard to the strnatcasecmp() error and I'm not sure if it affects the copy blocks functioning. In fact it doesn't even appear that strnatcasecmp() is even called directly from Copy Blocks. Copy blocks gives me a message that 13 blocks have been copied from w3css theme to solo.
The latest version of Solo (1.0.11) has the following regions listed in its info.yml file (I truncated the list)
regions:
highlighted: 'Highlighted'
popup_login_block: 'Popup Login Block'
fixed_search_block: 'Fixed Search Block'
header: 'Header'
primary_sidebar_menu: 'Primary Sidebar Menu'
The latest w3css theme 2.0.14 has the following regions in its info.yml (again truncated);
regions:
header: 'Header'
primary_menu_vertical: 'Primary Menu Vertical'
primary_menu: 'Primary Menu'
welcome_text: 'Welcome Text'
top_first: 'Top First Container'
This is the code that remains after copy_blocks has run. So, I guess that copy blocks does what it says: copy blocks, but doesn't alter the region layout of a solo based theme to match the old layout of w3css? And the recommendation would be to copy your blocks but don't alter the region layout? Just put your blocks in an appropriated (and equivalent) region in the new solo theme?
fkelly12054@gmail.com → created an issue.
I am taking the liberty of re-opening this for review.
#1 ... as the screen shots I have uploaded show, you can put multiple images in a given content type item and have them show as a slideshow. From my perspective this is great. The slideshow that is generated from vvjs view works very well ... at least for now. I am working on figuring out how to pass a parameter from a menu to the contextual filter on the view to allow different slideshows to be generated from the view.
#2 ... the implicit bug report relating to
public function validate() {
$errors = parent::validate();
if ($this->options['hero_slideshow'] && !$this->usesFields()) {
if (isset($form_state)) {
$form_state->setErrorByName('hero_slideshow', $this->t('Hero Slideshow option requires Fields as row style.'));
}
}
return $errors;is still relevant and at least merits a review. The php error is reproducible on my local system.
Bug report only: back in #2 I reported:
'In the process of testing this I encountered PHP errors with the hero slideshow option as from the PHP error log:
[11-Oct-2024 11:07:31 America/New_York] Uncaught PHP Exception Error: "Call to a member function setErrorByName() on null" at C:\webpage\compg_6\web\modules\contrib\vvjs\src\Plugin\views\style\ViewsVanillaJavascriptSlideshow.php line 328
This happens when "force using fields" is not requested and a hero slideshow is.
On my test system I modified the function validate to read:
public function validate() {
$errors = parent::validate();
if ($this->options['hero_slideshow'] && !$this->usesFields()) {
if (isset($form_state)) {
$form_state->setErrorByName('hero_slideshow', $this->t('Hero Slideshow option requires Fields as row style.'));
}
}
return $errors;
}
where there is an isset check around $form_state.
I wonder if you could see if this makes sense in this context.
Not to put too fine a point on it, but I uploaded another file: slideshow capture from view. This builds on the slideshow that is generated from the "pure" gallery content type and which uses the Imagefield Slideshow formatter from within that content type. No need for a view at all with that approach but still another module to maintain and update.
Using the VVJS module and a view we can display a different version of the slideshow. This uses:
Format: Views Vanilla JavaScript Slideshow | Settings
Show: Fields | Settings
together with a couple of filters to just get the gallery content type with a specific title.
With some tweaks, this display is a bit "prettier" than the Imagefield Formatter. I and also create a Page from this view which could be used as a link on a menu.
Obviously we don't want a separate copy of the view for each gallery so it will be necessary to find a way to get contextual filters into the menu items that are outside the view.
I'm not sure if I am not misunderstanding you when you say: " VVJS is designed to create slideshows from multiple content items, rather than from an image field with multiple images" but having a content type instance with multiple images seems to work just fine.
Thanks. I installed the ImageField Slideshow Module and it works. It could be a solution. Or its formatting capabilities could be part of a solution.
However, I decided to have another go at the VVJS module. I know that in other contexts I have retrieved and displayed multiple content items including images from a view. I started with a content item with four images and moved on to one with (for stress test purposes) 20 images. I had to adjust PHP settings to accommodate the 20 images request.
But they worked. What's nice is that even in the Gallery with 20 images, I get a main image displayed with a row of thumbnails below it that are clickable. And below the thumbnail items there are "prev next" links. Almost no effort to get at least a starter level gallery working. I could also select the images from a list of images with basically one click since I already had them in a single directory in sites/ default/ files.
And in the manage display tab of structure / manage display / format I can use the Imagefield Slideshow formatter on the image field and have to gallery content type automatically transition through the 20 images while setting the transition times etc. There are many options and learning to use them properly will take some experimentation and time. The key thing for me is that I can quickly move from a bunch of images in a Juicebox gallery to having the same bunch of images in a gallery content type and have the software scroll through the images. And I can leave my existing images in sites/default/files intact without making media copies and just reuse them. And given that the gallery images are already in a logical gallery structure in the order I want, it is just a few minutes work to make a working gallery this way.
I will look into the ImageField Slideshow module. Thanks for the reference.
The VVJ suite contains unparalled capabilities, I am sure. But I have to start slowly and get things working incrementally.
Following up on the previous posts I loaded up the VVJ suite carousel module. In five minutes I had a basic carousel slideshow working. The settings from the view applied immediately and I could get a carousel based slideshow with the four images I mentioned previously working. The view settings from the slideshow version of the module did not work.
I am fairly sure that the settings for the view are not being correctly passed from the slideshow module. Simple enough to test, create a content type with a handful of images, do some settings for them and see if the settings are applied.
The statement "the first approach uses the Juicebox gallery or ImageField Slideshow module to create a slideshow from multiple images within a single content piece" may be technically true, but it oversimplifies the situation. I have hundreds of content pieces which are each individual galleries and can't be mixed and matched. Each of them has a single link that's placed on (and can be accessed from) a menu.
details ...
The content type named gallery displays properly with a title and four images arranged vertically below the title. (I am trying to eventually use the title and content type of "gallery" as views filters).
Using the vvsj example view leads to errors and does not display the slideshow properly using the Format:
Views Vanilla JavaScript Slideshow | Settings
The filters for content type = gallery and content title = 2009-10 work properly in the view.
However the styling for the view requested in settings in Format:
Views Vanilla JavaScript Slideshow | Settings
are ignored. These settings would arrange the four images horizontally with < and > on the left and right sides of the images to allow horizontal scrolling through a list of images.
In the process of testing this I encountered PHP errors with the hero slideshow option as from the PHP error log:
[11-Oct-2024 11:07:31 America/New_York] Uncaught PHP Exception Error: "Call to a member function setErrorByName() on null" at C:\webpage\compg_6\web\modules\contrib\vvjs\src\Plugin\views\style\ViewsVanillaJavascriptSlideshow.php line 328
This happens when "force using fields" is not requested and a hero slideshow is. This error may not be related to the main thrust of this bug report but still should be resolved. The variable $form_state at line 328 of ViewsVanillaJavascriptSlideshow.php is not defined.
More serious, even when a hero slideshow is not requested, there are still ajax errors being generated when switching back and forth between a "normal" slideshow and a hero slideshow. After trying to switch to a hero slideshow I get "Error message
Oops, something went wrong. Check your browser's developer console for more details. " and the screen freezes. I have to manually click the error message screen closed. On the developer console I get:
"Uncaught Drupal.AjaxErrorUnderstand this error"
/admin/structure/views/ajax/display/vvjs_example/default/style_options?_wrapper_format=drupal_ajax:1
Failed to load resource: the server responded with a status of 500 (500 Service unavailable (with message))Understand this error
js_UkjpasEXtOWw58FysL0ZsdSW_iR_cR9W6OBzRDhV-2s.js?scope=footer&delta=0&language=en&theme=claro&include=eJx9j1EOwyAMQy9E4Qw7SeWGqMqWAYK06_E3VaMS-9hXrGfHUSgn48M2aIh1K1BPF5lU0qM5ypW7CTLZ-TQGHgWaV487joE3g_FYYViUY8XqduFXmzcJXXjEp6QhTVkVpbEjRc2dJuzTp6c5y1kX1PCdjv6900M_S54bofDtvL3IOhcpHLp4A1f0b9I:250 Uncaught Drupal.AjaxError
After closing the developer console, I can get back to the view editing screen and rerun my requested "not hero" slideshow. But this still does not apply the styling that should be associated with "Format: Views Vanilla JavaScript Slideshow | Settings" in the view.
fkelly12054@gmail.com → created an issue.
Just to add to what Ressa said: I use an inexpensive shared hosting service that provides terminal access to my site without the hassle of setting up ssh. You just change directory to public_html and then you have the ability to update and manage your own composer version, run composer and even run drush right from the terminal.
For many reasons you don't want to update or install modules (extensions) by url. There are just too many dependencies in today's software world.
Your settings.php has the code you need to connect to the database. If any of the database settings are wrong (database name, localhost, username, password) Drupal won't connect. You can get "stuck" on the install screen. Look in the PHP error log and you'll probably see some failure to connect messages. Fix the connection settings and let installation proceed.
I use Wampserver on a local site. It has PHPmyadmin built in. You can use PHPmyadmin to review your database settings.
If you have a D10 site, why not just upgrade it to D11? The nodes should be carried over.
Have a "primitive" local site working. For galleries alone I have approximately 11 thousand image files, though half are thumbnails. About 400 galleries that those files are distributed in.
I can create my custom content type named gallery with an image field. Save galleries with multiple image fields each. The views (vvjs) that you provide as a sample in the module works to display those multiple image fields. If I customize the title field to be equal to the old gallery name I can use it as a contextual filter.
The image files were just copied over from an old version of the site. They are NOT media files. I do use IMCE and I believe that's responsible for putting them into the sample galleries I've created so far. I have not run PB Import on this site and I'd like to avoid using media or files managed or any of the other helpful stuff Drupal has added since I started with Juicebox galleries and ftp'ng files nearly 10 years ago.
Next I want to see if I can stick a link into a vertical menu item that will point towards a single "album" that is an instance of a gallery content type that's inside a view. Seems like views contextual filters should support that.
Thanks for the response. I've had to rebuild my local (Wampserver) sites resulting in a delay. That's done.
So, where I left off, I had added some images to an article content type. I used IMCE (I have always used IMCE for editing and adding images to content types). Then used a copy of the view you provided with module. My initial attempts to use contextual filters seemed to work but I had some additional steps needed to confirm this.
It appears from other discussions that IMCE does much the same thing as PB Import does in terms of making image files work properly with Drupal core.
Next step for me, which will take a few days to get to: use a specialized (separate) content type: not article and add images to it using IMCE. Test out how they work with the vvjs module. If IMCE does the same "magic" to the images that PB Import does then I have no need for a separate PB Import conversion step. All my 2000 or so images are already nicely organized into two "gallery" directories in the /files directory on my sites. Each individual gallery has a separate xml file that lists all the images (full size and thumbnails) within that gallery. So creating the "gallery" content types should be fairly straightforward.
The overall views javascript module has some amazing capabilities. Someday I may have time to take advantage of them but right now I have to focus on just getting a couple hundred existing galleries converted from Juicebox to software that will be supported over time.
In the root directory of 4.0.x our principal maintainer wrote a program called juicebox.install. You might want to run that "manually" ... it should be run as part of updating to 4.0.x. It fixes some problems with image types that may be inherited from older Juicebox versions.
A year ago when we more actively debugging Juicebox, Luke (the maintainer) wrote this. I don't fully understand what's going on with it but I know that I was running into bugs I couldn't pin down and the program fixed them. Worth a try. I'm concentrating my efforts on finding an alternative to Juicebox.
Even though I've been working on galleries in Drupal for years, I wasn't aware of the ImageField slideshow module. Looks very capable and well maintained. I have to do some work on my local sites to test the VVJ suite modules further. In total the VVJ Suite gives an extensive set of capabilities ... my problem is that I just need a very simple set of capabilities but I have to make it work with an extensive set of images.
I know this seems like a very basic question but if you indulge me: but when you say "if your content is tagged, you can expose filters" I'm not sure what "content is tagged" means. What would be an example? In very basic testing I've done it does appear that exposed filters are working: if I have two content items with different titles it looks like I can filter on the titles and then just use the images from whichever content item has the title I want for a given slideshow.
I believe that this problem was resolved in:
https://www.drupal.org/project/juicebox/issues/3318067 🐛 Call to a member function isDisplayed() on null error Fixed
and a change was committed to 4.0.x. You list 4.0.0-alpha1 in your bug report.
You might want to replace 4.0.0-alpha with 4.0.x and see if that resolves the problem. The composer require for this looks like:
composer require 'drupal/juicebox:4.0.x-dev@dev' single or double quotes depending on your operating system
This project is not being actively maintained. Personally, I am spending my time looking at alternatives.
Settings.php only reflects the database password that HAS ALREADY BEEN SET outside of Drupal. IF you are using a hosting service there will be a database setup area where you put in a password. IF you are running locally you may use PHPmyadmin to set up the password (and for that matter to create databases). There are also command line approaches to managing database passwords.
Continuing onwards! It appears that I can use contextual filters. If I have two instances of an article content type (one with the title Irongate and the other with the title "Bound") and then I use a contextual filter I can select either using the filter for title ... say mysite/web/Irongate or mysite/web/Bound) and get the slideshow with images that belong to the Irongate or Bound galleries.
In rushing to get a local site up to test this feature with I have disabled all vertical menus but next up I will enable them and see if I can put a link in them for /vvjs/Bound or /vvjs/Irongate .... where vvjs is my copy of the VVSJ view example.
I love the fact that the JS for all this is in the Drupal code because, with the Juicebox module I've been working with for more than 5 years, the Javascript belongs to a third party and hasn't been updated in more than 5 years and the code that's used for generating XML files that contains the images and options for the slideshow is maintained by a fourth party (and is partly dependent on code from a fifth party). It makes for a very extended and fragile supply chain.
Picking up from " https://www.drupal.org/project/vvjs/issues/3476868 💬 Demo suggestions Active "
... 1. You modify the default view of "VVJS Example" naming the modified copy "vvjs2" to avoid unintentionally corrupting the base view that is installed with the module
2. You have a content type of article with a few images
3. For fields I limited the display to images
4. for filter criteria I used published = yes and content type = article
Since in my local demo site I just have one article, only one displays on the results. It shows the images and works properly as a slideshow. Good start.
I use a page display with a path of Path: /vvjs2
That page displays properly. Formatting refinements can wait.
My question is "what if I have 100 slideshows? " I might be able to filter the article type results by title or something. But that would be Hardcoded in the view. And I might need 100 views to display 100 different slideshows. I probably would have a content type of "gallery" to avoid mucking up the article content type, but I still have a problem. I don't want 100 different views for 100 different slideshows.
In my current Juicebox based gallery set up, I have links to the galleries embedded in vertical menus throughout the site. Each link points to a url alias which in turn points to a specific instance of a Juicebox gallery content type. That instance is a node.
I'm struggling to figure out how I'd translate this to the vvjs based approach. Suggestions welcome.
fkelly12054@gmail.com → created an issue.
The latest commit on this project was in March 2018. Unless you can find a developer who is qualified to test changes (not a simple process for beginners) and someone who is willing to take on active maintainership, I would not spend my time chasing after this module.
Drupal changes and will continue to change and unless you have a maintainer who understands and is able to apply the changes suggested by Drupal (they show in the issue queues as "automated Drupal X compatility fixes") the project should be considered dead.
First, I have uploaded a png file illustrating the documentation issue. I think it was just a copy/paste that needed to get modified for "import/para".
Second I will work through your debugging suggestions over the next couple of days. I can say that when I create a slideshow section and select a jpg file the file I am selecting is from my "sites/default/files/jboxgalleries/anygallery.jpg" location. I can verify this using the Chrome inspect feature. But after I save the newly created gallery the file it embeds is from "sites/default/files/2024-08" directory where register files has put it. This shows when I inspect the page, but also in the directory listings on Windows and in PHPstorm. I will provide additional detail per your suggestions.
fkelly12054@gmail.com → created an issue.
fkelly12054@gmail.com → created an issue.
Going back to 2016 I have used photo galleries in my web page. I use the contrib module named Juicebox, which I am also a maintainer (though not a very proficient one). I have about 130 galleries and almost 10000 jpg files. With Juicebox you basically build the galleries on a PC or Mac (though there are some less than satisfactory ways to do it all within Drupal) and then upload the gallery and an XML file and embed it in a content page. Problematically, the Juicebox Javascript code software is not open source and a full featured version costs $50. There is other gallery building software which has now been "outsourced" to a second company and that software is dependent in turn on Adobe software .... which has been problematic. Starting in the late 20 teens, Drupal core developers worked on converting several contrib media related modules to media in core. That was released in the later stages of Drupal 8 and has been enhanced since. However it is a break with the older method of "FTP your own images to sites/default/files" and manage them yourself.
More recently https://www.drupal.org/project/paragraphs_bundles → (paragraphs bundles contrib module) and the solo theme ( https://www.drupal.org/project/solo → ) provide a way to develop slideshows right within Drupal. They rely on the newer core media module. That approach makes sense but converting (or reloading) a couple of thousand jpg images to media items is a stretch. Still, I think you might want to take a look at these two projects before going off on your own theme approach.
You might also want to look at alternative CMS approaches (including software as a service ones) that might provide better and more easily customizable slideshow related modules.
Thanks for the clarification on slideshow bundles. That will be helpful if I can ever overcome the file duplication issue.
Here is what happens. Creating a slideshow I get to the part where I add a slideshow section body. I've created a paragraph type named slide_image and am trying to embed it in the slideshow section body. I get a form (see file attached to this issue) to "Add a new file" with a "Choose files" option. In PHPstorm I've traced this down to "web/core/modules/file/src/Plugin/Field/FieldWidget/FileWidget.php" the file widget program from core. (I put an "xxx" before the text for "Add a new file" in the program and the xxx shows up in the data entry box).
So I know that the program is going to FileWidget from core and I can tell from what's in my sites/default/file directory that, if you try to add a file that duplicates a file that is already in sites/default/files, it will simply rename the file with a extra characters to avoid creating duplicate files. (e.g., you wind up with "three_kids_dance.jpg" "three_kids_dance_0.jpg", "three_kids_dance_1.jpg" etc.)
That's clever to avoid duplicate files but what we really want is to create a link to one existing file wherever it is already stored in sites/default/files. Which in my case would be a gallery directory in a separate area.
So, yes the image content type does work to avoid creating media items where they aren't wanted or needed but it doesn't help with the duplicate files issue. Nor does it allow you to link existing image files in to a slideshow. And,if you look at the list of files in the png file I've uploaded, what would really be cool would be to be able to bring up an existing gallery image directory, select all the files, and link to them as a series of files in a slideshow section.
Sigh
Well, the images I'm using from sites/default/files/jboxgalleries ... x_gallery (where x gallery is one of many galleries there) are not getting created as media items. So that's a plus.
However, they ARE BEING duplicated over into sites/default/files/2024-07 so that's kind of better than them having to be media items but still not allowing the reuse of existing images within the slideshow/. If these were a few files, okay, I'd deal with it. I have 2950 image files being used in galleries (slideshows).
The appropriate and efficient use of slideshow sections and slideshow section body is not clear to me either. I can have a slideshow section with say, 6 images nested under it and when I view the slideshow those will show consecutively and individually. But if I create a slideshow section body and nest 5 images under it, they show stacked one above the other vertically. I've also had situations where multiple images in one slideshow section (not a "body") stack vertically. When I go in to add a file to a section or the body and click on choose a file I get a list of files in the most recent directory. And I can select multiple ones of these. I could picture a situation where I could basically load an entire gallery of 20 or 30 images with one selection action. They'd would also be in the order I want them to be because the list is in that order. That would be too cool.
Maybe some documentation on how "slideshow section" versus "slideshow section body" is supposed to work. If you have multiple images do you put them in the slideshow section or the slideshow section body. What's the difference between these?
The information in https://www.drupal.org/project/paragraphs_bundles/issues/3456431 ✨ How to Create a Paragraph and Attach a Background Image in Drupal | Paragraphs Bundles Tutorial Fixed and the videos attached to it, help resolve the problem of using images from sites/default/files rather than media files. As an added bonus I appear to be able to select a number of images with one selection ... especially since my images are organized by the gallery names that they are contained in. That will save me a lot of work! It is great that we don't have to use media.
I still have some details to work out but this looks very promising.
I guess that the question then, can I start using composer now on an old site that has never used it"
Short answer is yes. In the late 20 -teens that's what many people did to make the transition to composer. On my local site (a replica of my shared hosting productions site) I set up a series of directories ... named 'em /compa, compb, compc ... got all the way up to compg before I had it sort of perfected. You can find articles on the web with searches for Drupal and "composerize". It's helpful to study up on composer commands and look at the Drupal.org issue queues on updating with composer. The reference article is https://www.drupal.org/docs/updating-drupal/updating-drupal-core-via-composer →
I use it every time I run the monthly core updates.
This discussion thread has stretched out over 10 months and is not getting anywhere. What Gisle said in his initial post still stands. You just need to use Composer. Hosts have no excuse in 2024 not to support it. If yours doesn't, find one that does. I run it with a local site using Wampserver on my PC. That's for testing. Then I run it on inexpensive shared hosting on a host that supports hundreds, if not thousands of sites. They provide a terminal session through CPANEL and the ability for me to update my own version of the Composer code (and use Drush from a command window by the way).
No one is likely to be able to diagnose, let alone fix, the problems you will encounter trying to do manual updates.
Found paragraphs bundles node reference. Able to link between the slideshow setup and an "old" set of images that were in sites/default/files .... for a Juicebox slideshow. The content type becomes PB Node Reference. But it allows me to pull in an image from sites/default/files ... and display it. Will continue on to see if this will work for multiple images in a slideshow while leaving the original 1000+ jpg files in place and not converting them to media.
Quoting myself from #7 "I can, at least, avoid using media." ... maybe not
Found this : media and files →
Others have gone down the same apparent dead end path I am trying to follow. It seems. It's logical that Paragraphs would use media in a post 2020 era ... rather then just stuffing files (however well organized into directories) into sites/default/files... On the other hand having a logical directory structure for a large set of files would also be handy. There are some media_directories contrib modules as well as some modules and devel generate functions that might bridge the gap. I doubt that the juice is worth the squeeze.
I am still trying to work through the suggestion(s) in #6.
Very helpful, thanks. I am part of the way there after an hour of tracing through the slideshow and experimenting on my local system.
I can, at least, avoid using media.
However, I have an existing structure for the galleries in sites/default/files. I have two "root" directories for galleries. Each of these root directories has a series of subdirectories and in each of these subdirectories there is an xml file that specifies the files and options that go in each gallery and then a series of jpg files. Let's just say for one gallery:
root1
gallery #1
xml file 1
jpg file 1 ... 2 ... 3 etc.
gallery #1
The xml file will have no bearing on the new "paragraphs" based arrangement.
Following the instructions in the video, I can upload jpg1, 2 and 3 and they work in the gallery. But the files that are uploaded are duplicated over into a sites/default/files/2024-07 directory. But I would like to use jpg1, jpg2, jpg3 in the gallery and not upload duplicates into 2024-07 (and use those duplicates in the gallery). (i just did a file comparison and the files are identical).
I will keep experimenting and look at the other options you mentioned. If there is a way to just link to existing files that would be great. I would love to be able to preserve my existing data structure for the gallery files and reuse whatever is already there.
Thanks again.
A few days ago I said:
Doing file comparisons between the original jpgs and what is converted into a media item: they are exact duplicate files. There may be other reasons media items are needed but I don't see what they are.
Experimenting on my local system I see that involving the media module and creating "media" versions of original jpgs creates not only "duplicate" versions of the jpgs but also webp versions of the same files stored in a sites/default/files/styles/pb_original_size/public/2024_06/somefile.webp and that it is this webp which is displayed as part of the gallery.
Granting that webp may be an improvement over jpg and that the media module may assist in "responsiveness", this is still a long way around rosey's barn (so to speak) for a conversion of older galleries to paragraphs bundles slideshows. I suspect that this is triggered by defining the image field as
Image pb_content_image Image pb_content_image
Entity reference // Reference type: Media // Media type: Image (PB) // Entity reference // Reference type: Media Media type: Image (PB)
and I don't know if it would be possible or technically desirable to just have a plain image field in a simplified (non media module related) version of the slideshow.
Looking further: been wondering why images need to be converted to media items before being put in a slideshow. As I mentioned I have several slideshows (about a half dozen) converted on my local system and each creates media files (jpgs) that mirror the original jpg files that I used in the original version of the slideshows.
Doing file comparisons between the original jpgs and what is converted into a media item: they are exact duplicate files. There may be other reasons media items are needed but I don't see what they are. The creation of media items adds an extra and tedious step to album creation and unnecessarily creates duplicate files ... as far as I can see.
What I need to create an album is:
1. album wide options, such as title, album width(with intelligently chosen defaults to reduce duplicate input)
2. a file matrix (rows and columns of image files) basically
3. Some other options for the whole content type of "slideshow". These options could be left to individual web sites. For instance, I use a field called "order of album" to sort albums when presenting them. Then a field for each album called "representative image" ... selecting one image from each album ... so that if I want to use a view to list a group of albums on a menu I can just sort the view display by "representative image".
This approach would all be done, as paragraphs seems to be done, within the base Drupal content types and structures without any need for ancillary Javascript. And of course we'd rely on Drupal's current (great) approach to making responsive pages using image styles.
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.