- Issue created by @fkelly
- πΊπΈUnited States fkelly
Thinking through my previous comment that (basically) if you haven't saved a url then you can't have a preview it occurs that, with other content types (for example articles) the preview function works just fine. I'm now trying to track down the difference between when you add an article and when you add one of my "quick juicebox" types. Using xdebug. So far I have not been able to zero in on why we are getting the deprecated function message in preg_match from urlgenerator just for the quick juicebox content type (and not for the article content type. Seems like that, if you can do a preview for one content type, you should be able to do it for another.
- πΊπΈUnited States fkelly
Work in progress, note.
Curious to why an article content type with an image field would work in preview mode while a quick juicebox content type would give an error in urlgenerator, I did close comparison of the two content types. I had a field that was named (machine name) "jimage" but was an image field in the quick juicebox content type. In the manage form display screen, you have the option to choose preview image style. I had chosen Juicebox Gallery for the preview image style. So, then I added a field named just plain "image" and chose "thumbnail" for the preview image style. That works!
The work around I suggested earlier for just disabling preview is kind of funky. Changing preview image style for "image" field seems to work with the preview function. I thought maybe go back and change the preview image style for the "jimage" field to thumbnail would work, but even after clearing cache the preg_match error persists. So this remains a work in progress.
To be continued.
- πΊπΈUnited States fkelly
Throwing up my hands at making the preview work. The problem is in:
if (!preg_match('#^' . $token[2] . '$#', $mergedParams[$token[3]])) { $message = sprintf('Parameter "%s" for route "%s" must match "%s" ("%s" given) to generate a corresponding URL.', $token[3], $name, $token[2], $mergedParams[$token[3]]); throw new InvalidParameterException($message); }
Which is the dogenerate function of urlgenerator, which is in Drupal Core. Somehow based on what a Juicebox image field passes to urlgenerator the variable $token2 is null and this causes an exception with preg_match. urlgenerator is called multiple time in any one Drupal page load by many different "programs" in the Drupal system. I can isolate it with xdebug to see the value of variables after the preview function of my "quick juicebox" content type is submitted, but I can't work around the error message. Even if I suppress (comment out) the preg_match area of code I still get a Juicebox config file not found error.
On the other hand, if I suppress the preview function for my juicebox related content type then I can save a bunch of images as a Juicebox gallery and view that gallery. So embedding a juicebox gallery without using JuiceboxBuilder pro does work. I can live without the preview function and Juicebox users may need to also. Unless there is a programming wizard out there who can figure out what's going on.
It is unlikely that we will have the opportunity to make a change to a core program anyway to deal with a Juicebox exception.
- Status changed to Fixed
12 months ago 10:07pm 30 November 2023 - πΊπΈUnited States fkelly
Lleber, our maintainer, has a fix for this issue. The problem lies in JuiceboxFieldFormatter where the system is trying to apply a Juicebox based format to fields where that doesn't work. He has put a temporary place holder for a image file that might be displayed in the preview screen and avoids trying to "juicebox format" fields that aren't compatible. This fix will be in the next Drupal 10 related release coming soon.
I am still trying to "nail down" how we can apply Juicebox formatting options (e.g.. captions below images, etc) to XML that's built entirely within Drupal. If I can come up with a satisfactory explanation and examples, I will post it with the documentation.
Some time ago I started "triaging" the documentation to de-emphasize Drupal releases prior to Drupal 10 (while still keeping Drupal 7 documentation available as long as the Drupal 7 is supported). We will continue on that "project" to have it completed for a stable Drupal 10 release.
I'm going to close this issue as "fixed" in anticipation of the the next set of code that will be released.
Automatically closed - issue fixed for 2 weeks with no activity.