LostKobrakai

Also the original image is never changed except if the image field does have max. dimensions set and the image is larger.

It's not about pages or repeaters – which is irrelevant – but about the way you handle them. For the most part any method you call directly on the $pages object will result in a database query, whereas all the other find() or get() calls are only searching pages, which are already in memory. That's the differentiating factor.

Are you talking about the CKEditor link editor?

This module is already sticking around for some time, so probably it got never updated to use separate Date and Time format strings.

Even if the date would show up it would just be a quite unreadable timestamp. I'd suggest formatting the date which will additionally make sure it's a sting and not parsed as anything special.

Browser caching does not have anything to do with the image resizing process. Browser caching is just about downloading the already resized image each time. Actually you cannot deactivate the server side caching of images. It's just about if the generation of the resized images happens directly after the upload or on the first request to the image.

It might actually be I'm really not sure if there is a option to rotate images already. Haven't had the need for by now.

Except maybe a way to correct the issue in the admin.

Yeah. The repeater field is returning an PageArray, which you're then searching. It's like $pages->find("some=pages")->find("now_search_on=runtime"). The latter one is less powerful/convenient than the first one.

Your version is not working because the runtime selector currently does not support parsing "today" to it's timestamp like the db selector engine does. $pages->find("template=repeater_events, end_date>today, sort=end_date, limit=2"); $pages->get("template=events")->events->find("end_date>" . time() . ", sort=end_date, limit=2");

I wasn't talking about having this done on demand. No matter when this resizing does happen it's a hit on the server's resources. Even generating the one thumbnail for the admin backend (on upload) can take around a second, not talking about multiple thumbs per file. Imagine someone throwing 10 images in the image field and going to grab some coffee before he can continue. As always it's up to the individual to implement such a system on their own if really needed.

@pwired It's not about fitting images, but about serving images in an appropriate size to each user. Mobile users will thank you about not needing to download that 1920 * 400 herobanner your using on your biggest layout breakpoint. @rick Such things would probably already be in the core if image resizing wouldn't be such a resource consuming task on multiple fronts.

Asleep in the midst of the day? There's probably only 1h time difference to your location.

$templates->get("package")->fields->getField("body", true); $templates->get("package")->fields->getFieldContext("body");

That's a problem nobody here can really solve. You surely wouldn't expect an old amiga to be able to process todays images. Optimizing image processing further down the stack may be possible, but the code we control can only make sure to prevent any unneccessary parallel memory usage and that's about it.

The processwire forms api just breaks down as soon as you need flexible non-form markup between different form fields, which is why I'm not using it.

The other option is to build an interface for the sites to communicate over, like a json api or similar. With 3.0 you could try the multi instance support as well, but it's not very well tested by now.

I'm not sure, but probably the image resizer just reads the exif data before resizing, turns the image if needed and discards them afterwards.

You're basically coding this logic on the server: - Put the string "…" in the response - wait 3 seconds - set redirect header for the response - send response to the user

Image resizing does need to load the whole file into the ram memory, which means the image's data cannot benefit from any compression, like saved images do. That's why images need way more space to be resized than their raw file size would suggest.

In my opinion the biggest hurdle here is building the forms and processing their inputs. There are various tools trying to solve that part, but personally they've never fit my workflow to stick. Also, while processwire does have a forms api, it's not meant to be used in the frontend and therefore does only solve this issue partly.

That's not really something that would need to be fixed, as the file it's refering to does not use the wire() function as constructor. It's already the right way, but it seems php7 is not picking up that fact because there's no __construct() function present.

As the error suggests, did you check if fopen does work and isn't blocked?

Disable content encoding and just insert the raw html into the table. Just make sure you're entity encoding the html on your own if needed.