Responsive Images

[Oliver]

The error at least tells us, that the responsive-images.php is called by the url, as it sends an appropriate image content-type with the http headers, what causes the browser to show the error you mentioned.

You can try to set the debug setting in responsive-images.php to true, so there will be a log file created by the script itself in the site’s root folder.

As I can’t check your setup from here, it’s hard to say what’s the problem.

Anyway, the jQuery plugin does seem to work as it changes the image urls. So I’ll give you the settings that work with all of my PW setups so far:

Paths:

/responsive-images.php

/site/assets/cache/image_cache

/site/templates/img/transparent.gif

.htaccess

...
# -----------------------------------------------------------------------------------------------
# OPTIONAL: Redirect users to the 'www.' version of the site (uncomment to enable).
# For example: http://processwire.com/ would be redirected to http://www.processwire.com/
# -----------------------------------------------------------------------------------------------

RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^ http://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# -----------------------------------------------------------------------------------------------
# Responsive images
# -----------------------------------------------------------------------------------------------
RewriteCond %{REQUEST_URI} \.(gif|jpe?g|png)$ [NC]
RewriteCond %{HTTP_REFERER} !/?processwire/
RewriteCond %{REQUEST_URI} (^|/)(site|site-[^/]+)/assets/files/.*(\.s([0-9]+)\.p([0-9]+)\.r([0-9]+))?\.[a-z]{3,4}$
RewriteRule .* responsive-images.php?swidth=%4&pwidth=%5&pxratio=%6 [QSA,L]

# -----------------------------------------------------------------------------------------------
# Access Restrictions: Protect ProcessWire system files
# -----------------------------------------------------------------------------------------------
... 

Paths in responsive-images.php

...
* Configure values below
*
* SITE_PATH: Document root file system path
* SITE_URI: URI from document root
*/
define('SITE_PATH', rtrim(dirname($_SERVER['SCRIPT_FILENAME']),'/'));
define('SITE_URI', rtrim(dirname($_SERVER['SCRIPT_NAME']), '/'));
/**
* PATH_CACHE: directory where resized image versions are stored
* file system path
*/
define('PATH_CACHE', dirname(__FILE__) . '/site/assets/cache/images_cache');
/**
* PATH_PLACEHOLDER: placeholder image to be delivered before replacement
* url
*/
define('URL_PLACEHOLDER', SITE_PATH . '/site/templates/img/transparent.gif');
/**
* pixel interval to determine width of image to be served (width = ceil(imagewidth / interval) * inteval)
* the smaller the number, the more versions of each image are likely to be generated and cached
* in number of pixels
*/
...

Remember, this is not a PW plugin. Within responsive-images.php you don’t have access to the PW api and its own logging functionality.

[bytesource]

I replaced the current .htaccess directive with the one you just posted, as it was different from the previous one. All other settings were already as you suggested. However, it is still not working.

I am also using ProCache, but judging from how the plugin is implemented,  should work anyway. Also, I am currently logged in the admin, so ProCache is off.

Cheers,

Stefan

[bytesource]

For some reason responsive-images.php never gets called. That's why Processwire tries to handle these images but cannot find them:

GET http://localhost:8080/processwire/site/assets/files/1277/440x295xdesert-rig…rig_18_033.440x295.jpg.pagespeed.ic.8erBgJazj2.s1366.p400.r1.jpg?141056768 404 (Page Not Found)

I assume the problem lies in my htaccess file (please see attachment). I removed the directives at the top for mod_expires, mod_headers, and mod_deflate, but nothing worked.

I am getting out of options, but clearly I overlooked something.

Cheers,

Stefan

htaccess.txt

[Oliver]

You can’t be sure. The URL called is correct. The rewrite rule in the .htaccess file should rewrite the request to the responsive-images.php. Be aware, that if the php script isn’t able to locate the original image file because of incorrect path settings, it also responds with a 404 Page Not Found error.

Just to be sure, got to line 

	$path = getPath($url);

and add 

    die($path);

and then call the image url you posted above directly in the browser. If responsive-images.php is called, you should see the path of the original image. 

[bytesource]

I added the line, copied the image address

http://localhost:8080/processwire/site/assets/files/1277/440x295xdesert-rig_-_rig_18_033.440x295.p400.r1.jpg?141056768

into the address bar, and loaded the page. But all I got back was the 404 error page of my site. Unfortunately there wasn't anything else.

[horst]

 The rewrite rule in the .htaccess file should rewrite the request to the responsive-images.php.

@bytesource: does this match like Oliver said?

RewriteRule .* responsive-images.php?swidth=%4&pwidth=%5&pxratio=%6 [QSA,L]

or should be better something like:

RewriteRule .* %{DOCUMENT_ROOT}/processwire/responsive-images.php?swidth=%4&pwidth=%5&pxratio=%6 [QSA,L]

[bytesource]

Host,

The rewrite rule from Oliver should match, but as it just seems responsive-images.php doesn't get called, I am tending to assume it does not match.

I also tried the alternative rewrite rule you suggested, but I still get the same 404 error messages for each image.

I still have got one question: Why do I need to add /processwire/ to the rule? It does not appear in any of the other rules.

Cheers,

Stefan

[horst]

I have got it from your provided htaccess file somwhere around Line 220, conditions for ProCache.

[horst]

@bytesource: please can you fill in the following gaps?

add the fullpath for all requested files or directories here, but for the not web accessible part use the alias "docroot". So your webroot will be written: docroot/

   - where is your processwire index.php:     docroot/

   - path to the Processwire .htaccess file:    docroot/

   - path to the site/config.php:                      docroot/

   - where is the responsive-images.php:      docroot/

Cheers,

Horst

[bytesource]

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

[horst]

@bytesource: obviously there is some (more) confusion working (and I was to try to clear them out, -ts,ts)

What I want you to do is NOT to edit your .htaccess, but just to answer my post and write "into your post here in the forum" the full pathes for those. To avoid displaying sensible data here in the forums I want you to use an alias for your servers docroot. But as you are working on a local machine, we make this now obsolete.

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/
?>

Please can you write for me the "full pathes" (where it is stored on your disc! nothing within PHP or PW, just the plain pathes from your HD) of the following files:

• PWs index.php
• PWs .htaccess
• your site/config.php
• the responsive-images.php

[felix]

Y U NO USE ZE picture element?

[bytesource]

@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]

@bytesources: thanks for the help.

Now you let me alone with two questions:

Why does the $config->urls->root output "/processwire/" ?  Looking to the full pathes, it should be only "/".

But looking into your provided .htaccess file at the ProCache section it clearly shows that the urls->root should be "/processwire/". But then all the full pathes should be look like this: /home/my_home/Programs/rubystack-2.0.0-12/apps/processwire/htdocs/processwire/{index.php}

This is confusing, or I am wrong?

How do you call the homepage in the browser? http://localhost/ or http://localhost/processwire/ ? 

[bytesource]

@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

[bytesource]

@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

[horst]

Are you sure that the pathes you have pasted are correct?

• /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 assume htdocs is the servers DOCUMENT_ROOT, and when you enter your website at localhost:8080/processwire/ this doesn't make any sense.

Please have a look if you have those files too on your disk:

• /home/my_home/Programs/rubystack-2.0.0-12/apps/processwire/htdocs/processwire/index.php
• /home/my_home/Programs/rubystack-2.0.0-12/apps/processwire/htdocs/processwire/.htaccess

Do you have two copies of PW there?

[bytesource]

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

[bytesource]

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

[bytesource]

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

[horst]

OHO!

check to comment out the "Rewrite Base /processwire/" in the extra Bitnami conf

and also the new one you has added!

Now you should be able to call PW with the browser url http://localhost/

Does that work?

[bytesource]

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

[horst]

Oh!

[Oliver]

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.

Actually I wrote the plugin with cases like this in mind. When I started, there were no picture fill and the picture tag had still a far way to go. The good thing about my solution is, that you just have to upload the maximum resolution of an image. So you don’t have to create or even define any other image resolutions. In case you have dynamically generated parts like when using light boxes, popups and stuff, you just have to get your hands on the new/changed dom elements to call responsiveImages on. Magnific Popup provides several callbacks so you could do it like this:

$('.image-link').magnificPopup({
  type:'image',
  callbacks: {
    elementParse: function(item) {
      // Function will fire for each target element
      // "item.el" is a target DOM element (if present)
      // "item.src" is a source that you may modify
      var $container = $(item).parent(); // maybe you can instead access this.contentContainer, if the option is accessible from callback
      $container.responsiveImages({
        ...,
        callOnUpdate: function() {
          // do what ever you want as soon as responsive images are loaded and sources are set
        },
        reset: true // if an instance already exists on the element
      });
    }
  }
});

As I don’t know Magnific Popup, this may not be the best solution for it, but it should give you an idea how to deal with a case like this.

[LostKobrakai]

Oh!

Bitnami Stacks are quite shitty to customize from what I remember. There are settings scattered all over the place and it's real pain to search for the right file to alter behavior.