bytesource

Oliver, Thanks for your explanations that helped clear up a lot of questions. There already is an instance of Responsive Images, so I went with the following solution, adapted from the code in your last comment: $('.product-gallery').magnificPopup({ // ... callbacks: { change: function() { var target = this.currItem; var pathname = target.src; var newPath = $('body').responsiveImages( 'getURL', pathname, { swidth: screen.width, pwidth: $(window).width(), pxratio: window.devicePixelRatio || 1 }); pathname = newPath; } } }); However, newPath returns null. I also checked that this.currItem.src is indeed the current image path. Do you have an idea what the problem might be? Cheers, Stefan

Oliver, Thanks for your suggestions. Unfortunately, I had not that much luck with the examples. The first example that uses $(this.contentContainer) freezed my computer so that I could not even inspect the problem. The second example, as shown below, made all images on the page disappear (the image url was not modified by the plugin, either): $('.product-gallery').magnificPopup({ // ... callbacks: { change: function() { var pathname = window.location.pathname; var target = this.currItem; target.src = $('body').responsiveImages( pathname, target.src, { swidth: screen.width, pwidth: $(window).width(), pxratio: window.devicePixelRatio || 1 })); } } }); I probably just made a silly mistake, I just can't find it. Cheers, Stefan

Martijn, Yes, and it is an elegant solution to my problem that I might go with in the end. It's just that I have pulled my hair out trying to make the gallery work using the Responsive Images plugin that I don't want to just give up but keep on looking for a solution. Cheers, Stefan

Martijn, Thanks for your clarification. I have evaluated the Picturefill plugin before, which is similar to your solution. However, I found the Responsive Images plugin (RI) to be more convenient, as images of different sizes are created on the fly as needed. Using RI to handle the gallery images should be very well possible, but with my limited javascript skills I got kind of stuck. Cheers, Stefan

Martijn, I understand why I need to use the viewport width. However, I am not sure I can follow along the rest of your explanation. In the gallery, before clicking on a thumbnail, the url to the large image is the value of the href attribute of the surrounding <a> tag: echo "<a href='{$image->url}'><img src='{$thumb->url}' /></a>"; As far as I know this.currItem that is accessible from the change callback is not the final image, but an object I can retrieve the url to the large image from. This is why, in order to be able to call responsiveimages(), I created a temporary image. Not sure, if that works, though. You said this problem had nothing to do with adaptive images, but as I am using the Responsive Images plugin (which essentially produces adaptive images), I guess the urls to the large gallery images should also be handled by this plugin. Please correct me if any of my assumptions are wrong. Cheers, Stefan

@Oliver Making Responsive Images work with the Lazyload plugin has been relatively easy, but I have been struggling to achieve the same with the Magnific Popup gallery on opening dynamically created images. My latest attempt at tackling this problem can be found here: https://processwire.com/talk/topic/7623-olivers-responsive-images-plugin-some-questions/#entry74160 If you have some time it would be great if you could take a look at this code, as I believe my way of calling responsiveImages() is not correct. Cheers, Stefan

On taking a closer look at the Magnific Popup API I realized that in order to get hold on the current item, I probably should use the change callback. Also, as the large gallery images will be displayed at near full-screen size, I decided to call responsiveImages directly and simply set pwidth to equal the width of the screen. Unfortunately, the following code results in the image url of the large image being set to http://localhost/sovonex/top-drive-services/undefined So I guess I am still not calling resonsiveImages correctly. $('.product-gallery').magnificPopup({ // ... callbacks: { change: function() { var pathname = window.location.pathname; var target = this.currItem; var $tempImage = $('<img />'); $tempImage.attr('src', $tempImage.responsiveImages( pathname, target.src, { swidth: screen.width, pwidth: screen.width, // ** pxratio: window.devicePixelRatio || 1 })); // ** // For simplicity, pwidth equals screen width, // as we are dealing with images displayed full-screen. target.src = $tempImage.attr('src'); } } }); Any suggestions from anyone familiar with the Responsive Images plugin are highly welcome! Cheers, Stefan

I inspected the item object that is passed to elementParse when clicking on a thumbnail, and this is the result: container: undefined item: Object el: x.fn.x.init[1] index: 0 parsed: true src: "/sovonex/site/assets/files/1037/top_drive_services_in_nigeria_2_186.jpg" type: "image" __proto__: Object this: MagnificPopup bgOverlay: x.fn.x.init[1] container: x.fn.x.init[1] contentContainer: x.fn.x.init[1] currTemplate: Object direction: true ev: x.fn.x.init[1] fixedContentPos: true index: 0 isAndroid: false isIE7: false isIE8: false isIOS: false isLowIE: false items: Array[6] popupsCache: Object preloader: x.fn.x.init[1] probablyMobile: false scrollbarSize: 15 st: Object supportsTransition: true types: Array[4] wH: 146 wrap: x.fn.x.init[1] __proto__: Object So I guess there is not much I could do with this object. Makes me wonder were to bind the responsiveImages function to. Cheers, Stefan

I have been trying to make the Responsive Images (RI) plugin work with the Magnific Popup (MP) image gallery. The basic markup of MP is as follows: echo "<a href='{$image->url}'><img src='{$thumb->url}' /></a>"; The url of the thumbnail is modified by RI as usual, but the url to the larger image is not detected, as it is not the value of an image's src attribute. The idea is to call the MP's elementParse function, then call RI on the url to the large image, and replace the current value of the href attribute with the new modified url. In the documentation, elementParse is described as follows. The following code does not work. It returns 'undefined' for container and a 404 error for the url: This is the code I have come up with (elementParse is the important part): $('.product-gallery').magnificPopup({ delegate: 'a', // child items selector, by clicking on it popup will open type: 'image', gallery: { enabled: true, // set to true to enable gallery preload: [1,2], // read about this option in next Lazy-loading section navigateByImgClick: true, arrowMarkup: '<button title="%title%" type="button" class="mfp-arrow mfp-arrow-%dir%"></button>', // markup of an arrow button tPrev: 'Previous (Left arrow key)', // title for left button tNext: 'Next (Right arrow key)', // title for right button // tCounter: '<span class="mfp-counter">%curr% of %total%</span>' // markup of counter }, callbacks: { elementParse: function(item) { var container = $(item).parent(); // test element alert(container.attr('name')); item.src = container.responsiveImages('getURL', item.src, { swidth: screen.width, pwidth: screen.width, pxratio: window.devicePixelRatio || 1 }); } } }); Unfortunately, I have almost no JQuery skills, and cannot even say for sure if the above code is syntactically correct. Therefore, I would be very grateful if someone could take a quick look at the code and point me to the most obvious errors. Cheers, Stefan

Thanks for this information! I placed the cookie inside <head> and the JQuery part of the plugin before the closing <body> tag. So far it seems to work just fine. Cheers, Stefan

I just wanted to mention that I opened a new thread here: Oliver's Responsive Images Plugin: Some Questions Cheers, Stefan

Hi, I am currently evaluating the Responsive Images plugin that dynamically provides adaptive images and that was introduced in this forum by Oliver, its creator, some time ago. I will probably have some more questions while exploring the features, but for now I just wanted to ask if it was OK to place the javascript portion of the plugin at the end of the body tag instead of in the head section as mentioned on Github. On the site bildbau.net that uses the plugin, the javascript is located at the end. I, too, prefer placing my javascript in one minified file at the end of a page, but I am not sure if then all images would load as usual before the plugin could do its work. Cheers, Stefan

@kongondo Using Google site search is a great idea! I will try it out on my next question. Cheers, Stefan

Having moved my current Processwire installation to a vanilla LAMP stack, the Responsive Images plugin is finally working! After testing it out and making it work with my picture gallery and maybe even the Lazyload plugin, I will come back with some feedback. I also might consider opening a new thread focussing on the plugin's latest features. Cheers, Stefan

@cstevensjr, WillyC Thanks for pointing me to the source of the problem! And of course you were right, I had a typo in my DB credentials. To be honest, I should have stumbled about this myself, so I apologize for bothering you. @pwired I made it a habit to go through the forum posts first before asking a question. In this case I searched for SQLSTATE[28000] but could not find any solution that fit my problem. At least that is what I thought.

Hi, In the course of moving my local Processwire installation from Bitnami to a classic Lamp stack, I installed Processwire 2.5 using the installed, and logged in at http://localhost/sovonex/processwire/admin to check that everything worked. Then I replaced the /assets/, /templates/, and /modules/ folders of the fresh install with my own folders, and imported my database. On page reload I got an internal server error, and the log showed the following error message: Assuming there might be a bug in Proccesswire 2. 5, I deleted all files of the fresh install, moved over all of my files, and updated the database credentials. I also deleted the Modules* cache files, as suggested in the upgrade instructions. Still I received the same error message. I know there are similar posts on this forum, but I could not find a fix to this problem. Therefore, any suggestions are highly welcome! Cheers, Stefan

@horst I will be installing a classic LAMP stack when I am back home later this day. Then at least we will have roughly the same installation base which should reduce the number of unknowns. @Oliver This sounds truly fantastic! I cannot wait to test it out. Cheers, Stefan

Uncommenting Rewrite Base /processwire/ in both .htaccess and htaccess.conf and opening http://localhost:8080 leaves me with the Bitami welcome page.

By adding some garbage text at the top of the file, I just found out that .htaccess is not even called! In /home/my_home/Programs/rubystack-2.0.0-12/apps/processwire/conf/httpd-app.conf I changed <Directory "/home/sovonex/Programs/rubystack-2.0.0-12/apps/processwire/htdocs"> Options +MultiViews AllowOverride None to <Directory "/home/sovonex/Programs/rubystack-2.0.0-12/apps/processwire/htdocs"> Options +MultiViews AllowOverride All After that, .htaccess was called, but with an error. Adding the following rewrite base fixed that: /home/my_home/Programs/rubystack-2.0.0-12/apps/processwire/htdocs/.htaccess RewriteBase /processwire/ However, now I am back to square one, as with regards to the Responsive Images plugin I get the same 404 errors as before. Cheers, Stefan

In the Bitnami install I found another copy of Processwire htaccess directives, as well as more configurations inside the following folder: /home/my_home/Programs/rubystack-2.0.0-12/apps/processwire/conf/ -- httpd-prefix.conf -- htacces.conf -- httpd-app.conf -- httpd-vhost.conf I attach all files here in case they might be relevant (had to replace ".conf" with ".txt" to make the upload work). On line 85 of htaccess.conf, the rewrite base is set to /processwire/, which is not the case in the "normal" .htaccess file located in the root folder: # OPTIONAL: Set a rewrite base if rewrites aren't working properly on your server. # And if your site directory starts with a "~" you will most likely have to use this. # RewriteBase / # RewriteBase /pw/ RewriteBase /processwire/ # RewriteBase /~user/ I am feeling these additional htaccess directives might be the key to the problem, but I don't see how this all fits together. Cheers, Stefan htaccess.txt httpd-app.txt httpd-prefix.txt httpd-vhosts.txt

Horst, Please find attached a screenshot of my Processwire root folder. The full path is given at the top. I cannot find any additional /processwire/ folder. I installed Processwire through Bitnami, which lets you install the whole LAMP stack + Processwire (+ Ruby in my case, as I wanted use SCSS) as a self-contained entity, separated from other programs on the computer. This is why you don't see the usual /var/www/<processwire root>/ path here. Maybe there is some other magic going on during installation, but this is just an assumption. Also, looking at other htaccess directives, I can see that index.php is called in the same way I have been trying to call responsive-images.php: # Pass control to ProcessWire if all the above directives allow us to this point. # For regular VirtualHosts (most installs) # ----------------------------------------------------------------------------------------------- RewriteRule ^(.*)$ index.php?it=$1 [L,QSA] So, in theory, it should just work. Cheers, Stefan

@horst If it is confusing for you, then you can imagine how confusing it is for me As for your question, the homepage on my computer is called as follows: http://localhost:8080/processwire/ Cheers, Stefan

@felix Browser support for the <picture> element is still lacking, but there is a JQuery plugin, Picturefill, that imitates the function of the <picture> element where it is not supported yet. Also, aside from serving images of different sizes for different devices, I have the following two additional requirements that neither Picturefill 1, nor Picturefill 2, seem to provide: 1) I am using the Magnific Popup image gallery and want to serve adaptive images not only for the thumbnails, but also for the large image views. This is not possible with Picturefill by default, as the HTML for the large images is created dynamically whenever a thumbnail is clicked, and therefore does not contain the required <picture> markup. 2) The adaptive images solution should work well with the Lazyload plugin. There exists a custom implementation for Picturefill 1 that is said to work with Lazyload, but I ran into problems on pages with a lot of images. Picturefill 2 does not seem to have such an implementation yet. I am not sure if the Responsive Images plugin can solve these problems, but judging from its implementation it looks like it is doable. This is also why I so desperately want to try it out. Cheers, Stefan

@horst Thanks for your patience! I think I finally understood what you mean. The path on my computer is the same as the output from $config->paths->root above, plus the the relative paths you already mentioned for each file (I did not move anything). This means the respective paths are as follows: /home/my_home/Programs/rubystack-2.0.0-12/apps/processwire/htdocs/index.php /home/my_home/Programs/rubystack-2.0.0-12/apps/processwire/htdocs/.htaccess /home/my_home/Programs/rubystack-2.0.0-12/apps/processwire/htdocs/responsive-images.php /home/my_home/Programs/rubystack-2.0.0-12/apps/processwire/htdocs/site/config.php I hope this information helps. Cheers, Stefan

Horst, I am afraid I don't quite sure what you suggest me to do. Do you need me to replace the current root ("/") with %{DOCUMENT_ROOT}/ for all files and folders in htaccess? But then again, Processwire is working fine with the current directives, it's just this one file, responsive-images.php, that does not seem to get called. I am starting to wonder if maybe the rewrite conditions doesn't match, so we never reach responsive-images.php to begin with. The Regex looks fine, but I still would like to test it out. Does anybody know of a way to verify a rewrite condition on localhost? If you want to know the root path, on localhost it is as follows: <?php $config->urls->root // => /processwire/ $config->paths->root // => /home/my_home/Programs/rubystack-2.0.0-12/apps/processwire/htdocs/ ?> Cheers, Stefan