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.

If you just want to try the sample, you can clone the repo to any directory within your local web server folder without changing anything. But if you want to use Responsive Images with your PW setup you should change the path settings in responsive-images.php to: define('PATH_CACHE', dirname(__FILE__) . '/site/assets/cache/images_cache'); // /** * PATH_PLACEHOLDER: placeholder image to be delivered before replacement * url */ define('URL_PLACEHOLDER', SITE_URI . '/site/templates/img/transparent.gif'); //or whereever you want to put the gif The cache dir will be created by the script. The .htaccess rewrite rule should be added to the .htacces in your PW root, where the responsive-images.php is located, too.

Hi Stefan, thanks for giving it a try! Hopefully I can help you with getting it to work. I implemented a lot of improvements since this post was created back then. So, let’s have a look. Usually I put responsive-images.php into the site root or the same level where the .htaccess is placed. As you would have to adjust some path settings in .htaccess and responsive-images.php, I recommend to stick to putting responsive.php into the root folder of your PW setup. The sample folder can be ignored. It’s just an example page where the setup is tested. If the script path is correct in your template, you have to address the images you want to be managed by the jQuery plugin. $(function() { // take care of all images $('body').responsiveImages({ respondToResize: true, // if you want to load other image sizes on resize, respondToUpscaleOnly: true, // load other sizes only on upscale resolutionInterval: 50, // load image size of closest multiple of 50px (rendered 430px -> load 450px) imgSelector: 'img', // if you want to be more selective, change it loadingClass: 'is-loading', // add a class to img while loading callOnUpdate: null, // optional callback when images are updated callOnEach: null, //optional callback called for each images after loading debug: false // set to true to enable console output }); }); Try it and let me know if it works. BTW: This site uses my plugin: www.bildbau.net.

Adrian, this is definitely a module a lot of people have been waiting for! Thanks for this! +1 for this one. Especially when you’re collaborating with another developer on a project it is hard to keep track with each other’s changes to templates, fields, etc. without passing on countless db dumps with every commit. It would be great to have a module–even if I think it should be a separate and specialized one–documenting such changes in importable text/json/haml files. Similar to migrations used with Rails.

As I’ve been playing around with Ruby on Rails lately, I really like this approach, Harmster! Have been trying to implement a similar–but by far not as sophisticated–structure in my PW projects. I especially like the possiblity to define what scripts and styles are loaded in what order for each view. Also the “scaffolding” helpers in admin panel are a great idea. Keep on the good work. I will test it and try to implement it in one of my on-going side projects. BTW: I forked your repo, Harmster, to play with your code and get a better understanding how your ideas work: https://github.com/oliverwehn/MvcModule/tree/dev I don’t really get the way you get everything together and rendered in the _create_mvc method. But I’m diggin’!

Thanks for your feedback on this. Even if the case you describe (cookie set and js disabled afterwards) is very unlikely to happen–if not intended–, I’ll try to set a very short expiration time for the cookie. I guess, that’s the only thing that might work here. Regarding your question about the “predefined pixel interval”: You can set the interval as an option of the jquery plugin, when you call it on the matched images. Let’s say you set it to 50, the plugin will set the image sizes by determining the nearest higher multiple of 50. So if the needed image size is 710, 725 or 745 pixels, a 750 pixel cache image will be served. Setting the interval lower will lead to some saved kilobytes in bandwidth and to a lot more cache files. Setting it higher will save you disk space but may cause more traffic on image delivery. I’m aware of the cache issue. To optimize that, I plan to append the parameters to the file name and change the url rewrite to take care of them. Currently the solution just takes care of providing a unique url for each image even if the query string is ignored/cut off when its cached.

I called it “responsive” because the strategy doesn’t adapt the resolution once to a fixed value like screen/window size. The javascript part of my solution uses the actual styled layout context the image element will be rendered in to determine the adequate image size. Also it is able to load a higher resolution image later on window resize or orientation change (if you want it to). As it is therefor more “active” and “event-driven” than e.g. Adaptive Images, I thought “responsive” would be more accurate.

Because I’ve never been really happy with the current strategies (I know) to deliver images the right solutions in responsive layouts, I lately started to work on my own approach. Other solutions like for example Wilcox’ Adaptive Images just rely on the screen resolution/window size or require additional (and manually added) data attributes or even js/noscript hacks in the markup. For me it was important to have a solution, that is installed once and then just works. So I took some ideas from other stratgies and put something together that seems to work so far (but I still have to test it in older browsers). Feel free to give it a try. I’d love to get some feedback on this. For detailed info have a look at the README. https://github.com/oliverwehn/Responsive-Images

I store each of my PW projects in separate repos. When it comes to updating the version of PW used for a project, I'm sure there has to be an easy way to merge the master or dev branch of the PW repo into am update branch of the current project's repo. I already added the PW repo as remote source. But as I'm far from being a git pro, I haven't found the right way to do an update appropriately without getting everything messed up. It would be great if one or two of you guys would sketch their approach to updating a PW installation using git and github in a few words.

Hey Hani, I tried your select field module, as I need just a drop down with three options and I don't want to setup a Page field with three pages for a case like this. Setup worked out fine. But the value entered on page edit isn't saved to the fields db table. Any idea why?

The key fits, problem solved! Thanks, Soma!

It's great that you can choose the fields of template that will be displayed in the Page List in admin pannel. But I really miss the possibility to use a field of a page reference field of a template to be displayed, too. A current website I'm working on uses a «project» template with a page reference field «client». As the title of the projects are often very similar or even the same, it would be a big help for editors to have the referenced client's page title added to the project's title in Page List. Like: List of fields to display in the admin Page List title client->title But I guess I've to create a little module to get this working, hm?

Is there any way to manipulate the form created by ProcessField's not hookable method buildEditForm? It's used by the hookable executeEdit method. But by adding a hook after executeEdit, I just can access the rendered HTML code executeEdit returns. Changing the markup is definitely not the way to go here. Adding a hook before is also useless, as the buildEditForm is called after the hook would have been executed. The only idea I got is to set the form property through a hook before, as it would be used by executeEdit if it already is set. public function ___executeEdit() { if(is_null($this->form)) $this->buildEditForm(); ... But as I can't access the protected buildEditForm method from outside the class, it seems there is just the way to copy buildEditForm completely, change it and use it to set ProcessField's form property before executeEdit instead of just accessing the form to perform minor changes or additions. Anyone a better idea? Or would it make sense to make the form generation more accessible for hooks?

Ha, should have known it's that easy again? Thanks Soma!

Is there a certain reason, why there is no way to add a module reference field through the usual field creation process in backend? It doesen't appear in the list. I'm aware of the fact that it mostly stores process modules for backend. Nevertheless there are some cases when a module reference field is a nice thing to have in frontend pages. Lately I tried to create a Fieldtype extending FieldtypeModule, but the extension failed because of the order the modules are loaded depending on their status flags. So there is no way to make the module reference field accessable for field setup but by changing status flags manually or creating a copy of the fieldtype with a different status flag?

Is there a reason for Page::path being hookable in the master branch of PW but not in dev branch?

If you first installed PW seperately on your remote server and later imported your database tables from your local dev setup, I guess the userAuthSalt strings in your local and remote config files (right at the bottom of them) differ. As the string is used to encode your password when saved in the database as well as the one entered on login, this may cause your well-known password being rejected, when the userAuthSalt was changed. EDIT: Ah, I just saw that the topic is also addressed in the thread Arjen pointed you to.

Thanks for the feedback. Ryan, using constants is a nice idea. I'll implement that as soon as I find the time. Regarding hookable methods: I don't think making the native ImageSizer methods hookable is necessary. But maybe I should make them and the extendes one's hookable through the module?

Oh, don't think, there is a reason for it being autoload. It was a quick hack, so I guess I just copied the value from another module and just forgot to change it.

In a current project it became necessary to implement more extended image manipulation functionalities as I needed to fix image orientation of photos where the orientation data was just stored in images's exif data set. As it was just one more manipulation among several other's the ImageSizer was already taking care of, I thought it would be nice to be able to extend the native ImageSizer class by individual methods. But as I - of course - didn't want to change core files and the ImageSizer itself isn't a “module” that seemed hard to achieve. But after I did some research, I found a solution using an instance of ImageSizer encapsuled within a module using magic methods to direct native method calls to the ImageSizer while providing extended methods from the module itself. It's far from perfect. The code is still messy and I just added methods to check for orientation data, fix orientation and therefor of course image rotation and flipping. Haven't been testing everything yet, but I uploaded the module to github. Could be useful as a starting point. https://github.com/o...geSizerExtended It is used the same way as the original ImageSizer: $sizer = new ImageSizerExtended($path); $sizer->method();

rtfm.processwire.com is the modx way, isn't it? But I like this one, still.

Pidelux, I also think, a wiki like manual could absolutely be built on PW itself. And in view of contextual help: why shouldn't the manual provide alternative read access to its articles via json or xml, so the information could be used by e.g. a module providing contextual help in backend?

I tried this: $templates = implode('|', $templates->find('name^=post_')->getArray()); $posts = $pages->get('/beitraege/')->children('template='.$templates.', post_confirmed=1'); if($user->id != $config->guestUserID) { $posts->import($pages->get('/beitraege/')->find('template='.$templates.', user='.$user)); } $posts_page = $posts->find('sort=-created, limit=20'); But it results in all posts being shown. Changing the last line to: $posts_page = $posts->sort('-created')->find('limit=20'); results in the first page's content being shown no matter what page I page to. A problem with the template pagination setting? It did work, when I've been using a simple selector to get my pages directly from the $pages template var.

ryan, does the $items = $pages->find("confirmed=1")->import($pages->find("owner=$user")); solution work with pagination? I tried, but it didn't seem to bring the results I expexted.

One more selector challenge to face: Currently I'm trying to show a list of pages which's common template owns a “confirmed” field set to true or false and a “user” page reference field. I need to select all pages that are confirmed OR owned by the user currently logged in, even if they aren't confirmed. And all this paginated and sorted by creation date. When I'm not totally wrong, there is just “,” as kind of an AND operator, but not OR but for cases like “title|headline=value”. Or did I miss something here?