We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
MODX Community Forums Archive

Javascript effects not being loaded

    • 5357
    • 30 Posts
    citrus Reply #1, 18 years, 4 months ago
    We’ve created a number of MODx sites in the past without any problems. However, we’re trying to incorporate MaxiGallery for a client and cannot get any of the ’embedded’ image effects to load and, instead, the larger image is simply displayed inline.

    The asset paths are correct and the module is loading correctly as we are able to use the manage pictures function, sort, etc. The pages have been published, aren’t set to cacheable and we obviously reload to test. We’ve re-uploaded the MaxiGallery fileset to make sure the original install wasn’t corrupted and, when the gallery is generated, the JS calls aren’t dynamically added to the site’s template <head>. Even when hard coding the JS calls the effects are still being ignored.

    The following calls are being used:

    Container:
    [!MaxiGallery? &display=`childgalleries`!]

    Document
    [!MaxiGallery? &display=`embedded` &embedtype=`slimbox` &pics_per_row=`4` &max_thumb_size=`100` &max_pic_size=`450`!]

    Using MG v0.5.2 and MODx 0.9.6.1p2

    Any ideas would be appreciated as this is driving us nuts and, yes, we have checked the Wiki to make sure!

    Thanks,
    Jim
      • 7923
      • 4,213 Posts
      doze Reply #2, 18 years, 4 months ago
      If the javascript is not added to the <head> but the output of MaxiGallery is the way it should be for slimbox, then there is a problem that the regClientScript modx functions are not working for some reason. If that’s the case, you can add the necessary JS scripts to the site template in the <head> section manually.


        "He can have a lollipop any time he wants to. That's what it means to be a programmer."
        • 5357
        • 30 Posts
        citrus Reply #3, 18 years, 4 months ago
        Have tried the manual route as well but still doesn’t kick in the effects which is weird.
          • 7923
          • 4,213 Posts
          doze Reply #4, 18 years, 4 months ago
          Can you give a link to the site for me to check?


            "He can have a lollipop any time he wants to. That's what it means to be a programmer."
            • 5357
            • 30 Posts
            citrus Reply #5, 18 years, 4 months ago
            PM sent...
              • 7923
              • 4,213 Posts
              doze Reply #6, 18 years, 4 months ago
              You were having 2 (or three) issues:

              1. You have added the images to the main page, eg. to the page that has the childgalleries call (id: 2) and it did not have any embedtype. I added &embedtype=`slimbox` to the call.

              2. The links to the slimbox JS and CSS files in the site template were not correct and missed some files (can’t remember what was missing.. maybe it was the setup/lang file), I updated the links to what they should be for slimbox.

              3. MaxiGallery is not adding the JS / CSS scripts to the head automatically. This has been a bug in MODx in some version, but has been fixed many times.. I have on test installation running MODx 0.9.6.1p2 and the scripts are added automatically to the template <head> ok.. Maybe you could try and take all other stuff off from the <head> part of your site template to see if there’s something that messes up the regClientXXX.. MODx functions.

              The pictures in the main paintings document opens now in slimbox. You need to add pictures to the child document before it appears in the main paintings document as a childgallery. But I guess you know that already if you have been using MaxiGallery before.

              Do you know that the test version for v0.6 release also has &childembedtype parameter what you can set for example to slimbox, so each child gallery will open in it’s own slimbox for browsing..


                "He can have a lollipop any time he wants to. That's what it means to be a programmer."
                • 5357
                • 30 Posts
                citrus Reply #7, 18 years, 4 months ago
                Thanks for investigating. wink

                We hadn’t originally added &embedtype=`slimbox` to the container call as was following the Wiki precisely to make sure everything was done in order.

                Will try to see if we can force the dynamic head loading as hard coding isn’t ideal and may even do a fresh install. We’re running under PHP 5.2.0: would that be causing any conflicts?
                  • 7923
                  • 4,213 Posts
                  doze Reply #8, 18 years, 4 months ago
                  Quote from: citrus at May 10, 2008, 11:29 AM

                  We hadn’t originally added &embedtype=`slimbox` to the container call as was following the Wiki precisely to make sure everything was done in order.
                  Yeah.. the problem was only that you had added the pictures to the container document (doc ID 2) and not to the child document (doc ID 6, IIRC). If you would have added the pictures to the child document, it would have appeared in the container document automatically as child gallery (with one thumbnail) which links to the child document and the pictures in the child document would have opened in slimbox (or actually they would have opened just in a new window, because the javascript is not automatically added in the <head> in your installation).

                  Quote from: citrus at May 10, 2008, 11:29 AM

                  Will try to see if we can force the dynamic head loading as hard coding isn’t ideal and may even do a fresh install. We’re running under PHP 5.2.0: would that be causing any conflicts?
                  I don’t think that the PHP version is an issue.. but if MODx re-installation doesn’t help anything, I bet it’s some server setting that causes this.. or did you try to remove everything from the <head> section of your site template already? There might be something that chokes it up. If you cannot get it to work, you can go around it by making a snippet that checks if the current document is a gallery document and if it is, return the links for css/js.. and run that snippet in the <head> section of your site template. That causes small overhead as it requires additional DB query on each page load, but don’t think it’s such a big issue.. and you can always turn on document caching, which is a good way to setup things anyway.. It would be always good to have as much caching as possible and to clear the cache only when something has changed (documents edited, pictures added, etc.). Ofcourse you cannot access the picture management in MaxiGallery if the snippet is running cached.. (note to self, create back end widged to handle pictures smiley).


                    "He can have a lollipop any time he wants to. That's what it means to be a programmer."
                    • 5357
                    • 30 Posts
                    citrus Reply #9, 18 years, 4 months ago
                    Have done another install, plus tried removing different/all elements from the head and still no joy with the dynamic calls. For now, think we’ll resort to the hard coded option as that is working.

                    Thanks for taking a look though, appreciate it. wink
                      • 5357
                      • 30 Posts
                      citrus Reply #10, 18 years, 3 months ago
                      Subsequent to this problem, installing the SVN version has rectified all the issues, so guess something was up with the 0.5.2 release we had installed (and re-installed).

                      Might help someone...