MadeMyDay

We are talking about linked images. Not images that are shown on page load. If I click on a link which targets an image (for example in a shop) I perhaps WANT to have a detailed version of the image I clicked/touched on and want to pinch and zoom to see the details.

No problem. Most modern lightboxes allow ajax driven requests. So just define a picture template and link that. Add the page id, image field name and count to it like <a href='/mypicture/?id=12&imagefield=images&count=2'><picture...></a> Or just keep inking to the (big) image. Even on smartphones this could be a desired way of showing details of a product. No need for a smaller version here (most of the time).

yep. http://dimsemenov.com/plugins/magnific-popup/ nope. Just use something like enquire.js and define your lightbox logic only for bigger screens. No need to get rid of the linked image, that is just fine: http://bradfrostweb.com/blog/post/conditional-lightbox/

Today the second site out of a series of 4 went online. This project is a bit different than the usual websites I do. The client had 4 websites, 3 of them running on a very old school proprietary CMS and one on MODX Evolution. I developed a layout which gets adapted by all three of them with minor differences and functions. I am running these on one installation of PW with the multi site module "Soma edition", originally by Apeisa. No problems so far with that. I imported around 1500 documents for both of the sites by fitting the CSV importer module to my needs. I could also manage to import images/PDFs which were hard coded in the shitty CMS by extracting the src from the markup. The PW-API surprised me a lot while doing this, just try&success ;-) The sites share a lot of templates, I tried to build it as modular as possible. As always, the CropImage module is loved by the clients and it also serves different image sizes for the sliders, while the picture polyfill loads the correct one dependent on the visitors screen size. The only thing I am struggling at the moment is the performace of the backend. Sometimes no problems, sometimes significant loading times. I am not quite sure if this is a server performance issue or is something related to PW. I also customized the backend a bit for quick create/edit pages: Ryan, if you read this: Do you think it is possible to get ProCache up and running for multi site environments? I think it would be a good benchmark, because the last site which gets converted will be the biggest one. And I am a bit concerned about perfomance (will be 10000+ pages). So, here are the two (warning: german and pretty boring, something with public vehicles and something with pests & ugly banners): http://kommunaltechnik.net http://schaedlings.net

Interesting discussion, happy to chime in here. I am a bit ambivalent here. For one, I would welcome any PW-related approach as a new InputField or alike. But in my experience all of the approaches - client or server side - were trying to fill a gap which had no standardized solution yet. But since W3C filed the specification for srcset attributes and picture elements my way is to go with exact that (even not implemented) syntax. Chrome implemented those lately (in Canary, behind dev flag), others will follow. I used the picture polyfill a lot in version 1, where it was more of a likely implementation of the proposed picture syntax. In version 2 we can use it right away with the correct syntax and from my observation it works great. So I would suggest not to build a custom (hacky) solution and reinvent the wheel but use that polyfill for not supported browsers (all at the moment, but less in the future). What I usually do is use the CropImage plugin for handling those different sizes. That works great. For example a slide show I am building the markup for each image looks like this (picturefill v1, so no picture syntax here yet, but works the same): <span class ='image' data-picture data-alt='{$slide->title}'> <span data-src='{$slide->sliderimage->eq(0)->getThumb('fullpagesmartphone')}'></span> <span data-src='{$slide->sliderimage->eq(0)->getThumb('fullpagetablet')}' data-media='{$tablet}'></span> <span data-src='{$slide->sliderimage->eq(0)->getThumb('fullpage')}' data-media='{$desktop}'></span> <!--[if (lt IE 9) & (!IEMobile)]> <span data-src='{$slide->sliderimage->eq(0)->getThumb('fullpage')}'></span> <![endif]--> <noscript><img src='{$slide->sliderimage->eq(0)->getThumb('fullpagesmartphone')}' alt='{$slide->title}'></noscript> </span> So it supports JS-disabled browsers as well as older IEs. You have total control over the images which those browsers get served. BTW: My media queries get imported by a global JSON file, I use that in CSS as well as in JS, but that ist another topic. Just consider for example $desktop be something like "screen and (min-width:1024px)". Advantages: I have full control and only have to configure CropImage for serving the different image sizes. Even art direction is possible (for example 2:1 on desktop, 1:1 on mobile). In that example I have no 2x configuration but that is also possible with srcset in picturefill v2 or with a media query like "screen and (min-width:1024px) and (-webkit-min-device-pixel-ratio: 2)". What I think regarding PW and responsive images: Try to keep the markup out of the solution or just provide a standard markup which everyone can change. Like PW always does. I would also rather extend the great CropImage module than trying to build something new. For example put a configuration in CropImage for 2X images. Could be done easily I think like: smartphone,200,200,template,2x so both, the 200x200 and a 400x400 version is generated from the same crop. The advantage of CropImage definitely is the art direction possibility. I wouldn't like to lose that ;-)

Getting wet a little. Again. Awesome.

There are a lot of options, either on server or client side. I have made good experiences with picturefill, which in version 2 adapts the syntax of the yet to be implemented picture and srcset tags: https://github.com/scottjehl/picturefill should be possible: http://patchwork.stylehatch.co/ Isotope has an add function, lazy load is nothing different than loading an adding serveral elements to the stack imho. Cheers

The sites are looking very nice. But I would consider this "show content once everything is loaded"-approach. On ciraphelan you have 117(!) requests and load 9.2MB(!!!) before the visitor sees anything. Honestly, usually I wouldn't wait that long before I see something of the content. On a mobile phone I would even hate you for letting my mobile data plan to be reduced by that huge amount of data only for a first look at your website ;-) What you can/should do: 1. Reduce the size of the images (600x300 with 300kB for an image is way too much, especially when having so many images) 2. Show Retina version only if needed 2. Show at least the first images once they are loaded, don't wait until everything is loaded 3. Use lazy loading for loading the images if the user scrolls and only wants to see more 4. Reduce the requests Cheers

Well, this could be done. But ProcessWire doesn't work with common language strings. If a developer codes a module all he has to do for being translation-ready is to put something like __('this is my string I want to translate') in his code. This is very handy because you don't deal with cryptic language variables. The downside is, you (or someone) has to use the language translation module to point to the file with the translation but then has a very comfortable way of translating it. Once a language file is translated a json is generated which can be used by everyone. The problem is, this file is located somewhere in the file system (look at the url while translating, identify the id, look in site/assets/files/id where you find all the translation files). I think what we (and Ryan) could do is to encourage module developers to create an (even empty) language file and ship that with a module (like ModuleName/lang/en/site--modules--ModuleName-module.json. So the only thing you have to do is to upload this/these json file(s) to your language and translate it. After that you could do a pull request to the project, so it could be easily integrated for others. Another problem is that these language jsons are named by the module path. And if not installed by ModuleManager, everyone can at least name the folder differently. But providing (even empty) jsons would be a good start I think.

So I still don't understand what you want to do ;-)

Don't really understand the question (or the problem ). Why not add a parameter to each link and react on that on the form page? <a href="form.php?formid=82828"> form page: $formid = $input->get->formid; // get the title of the page or whatever $myValue = $pages->get($formid)->title; form: <input type="hidden" value="<?= $myvalue ?>" name="Referrer"> Or do I misunderstand the question?

Just use the wonderful CropImage module. Say, you have a 300x300 image in your template. Define one 300x300 called "thumb" and one 600x600 crop called "thumb2x". Now you can use the picture polyfill like this: <picture> <img srcset="<?= $page->myimage->eq(0)->getThumb('thumb') ?>, <?= $page->eq(0)->myimage->getThumb('thumb2x') ?>, 2x" alt="<?= $page->myimage->eq(0)->description ?>"> </picture> Adding additional breakpoints with <source> is also possible (from the picturefill docs): <picture> <!--[if IE 9]><video style="display: none;"><![endif]--> <source srcset="examples/images/large.jpg, examples/images/extralarge.jpg 2x" media="(min-width: 800px)"> <source srcset="examples/images/small.jpg, examples/images/medium.jpg 2x"> <!--[if IE 9]></video><![endif]--> <img srcset="examples/images/small.jpg, examples/images/medium.jpg 2x" alt="A giant stone face at The Bayon temple in Angkor Thom, Cambodia"> </picture> So you can also do some art direction where you output not only different sizes but also different formats (for example 2:1 on mobile, 1:1 on desktop etc)

Well done Macrura! Clean and nice presentation. One thing though: On Retina displays the images and graphics look very blurry. Perhaps you can add some 2x resolution versions. Take a look at https://github.com/scottjehl/picturefill, so you are also prepared for the future. The loading animation also could be better fitting the overall impression. This little animated gif seems so outdated (and very blurry on Retina) ;-) But this is nitpicking... Like the site very much!

Finished two more: http://www.viamedici.de (english version http://www.viamedici.com ) Mutli language, multi site ( http://www.innovationday2014.de running from the same installation ), Form Builder and some other modules. http://www.delker.com Pretty much standard modules, multi lang upcoming in a few weeks. Stock photography not my decision, also the partner logos are not perfect yet (mostly low res). Always so much fun to work with PW

Well it resizes exactly for iPad. Which is one of many possible resolutions. And above 1024 until 1280 I get an ugly horizontal scrollbar. Can't see a reason why to build it that way. If the iPad (and only in landscape format) is your only concern, better stick with a zoomable version instead of breaking it for all other devices. No offense, just want to point to possible problems.

Looks nice on desktop. But since you didn't implement a responsive version I would suggest to remove the viewport meta tag, otherwise it looks broken on mobile.

You can use this fieldtype described by Ryan here: https://processwire.com/talk/topic/417-extending-image-field/#entry3225 (scroll down for the packed fieldtype) Just use a field for each language and in your template and display the description according to the current language. Not very elegant but works.

No problems here with current stable release of PW. Do you use Soma's version? Works fine.

thx Soma

Using Soma's version of multisite (which works great) I stumbled upon weird issue. Using form builder I cannot display the f2nd language form while the standard language works fine. Cannot present a link, but the issue comes from a wrong iframe URL. The german version is fine: <iframe frameborder="0" id="FormBuilderViewport" allowtransparency="true" style="width: 100%; height: 682px;" src="http://sub.domain.ch/form-builder/is_kontaktformular/" scrolling="no"></iframe> while the english version shows up like this: <iframe frameborder="0" id="FormBuilderViewport" allowtransparency="true" style="width: 100%; height: 700px;" src="http://sub.domain.chis_kontaktformular/"></iframe> so apparantly "/form-builder/" is missing in the iframe URL. I don't think it is a form builder issue (since multilang forms work usually), rather a problem with URL generation of multisite. I think the problem is here : public function embed($formName, array $vars = null) { $out = "\n<!-- " . FormBuilderMain::RCD . " -->\n"; if($formName instanceof FormBuilderForm) { $form = $formName; $formName = $formName->name; } else { $form = $this->load($formName); if($form) $formName = $form->name; else $formName = ''; } if($formName) { $page = $this->pages->get("template=" . FormBuilderMain::name); $url = $page->httpUrl . $formName . '/' . $this->embedQuerystring($form, $vars); $out .= str_replace('{url}', $url, FormBuilderMain::embedCode); } else { $out .= $this->_('Form not found'); } return $out; } I am not sure what goes wrong here. Either the selector for finding the form builder template (which I duplicated in the subsite's tree) or the generation of the URL because of the multilang situation. Any ideas?

Please show the whole code.

I already reported that somewhere and Ryan said that image fields are not supported (yet).

I can't see this selection. I only can select from about 15 domains I have configured in my GA account.

Hi Wanze, thx! That did the trick. But no matter which account I choose, there are no records displayed. No errors in console.

I can't get this to work. Always getting the attached screen from Google. Client_ID, URLs and secret are triple checked, no success. Any ideas?