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.
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