LostKobrakai

Maybe you could show us a bit more code / information. It's not that easy debug by guesswork.

Sure a low quality image is better compressable (lots of same color values), but it's still 3888 x 2592 x 8bit x 4 (rgb + alpha) to just hold the image in memory. Maybe some other operation in the proces is memory intensive.

Alternatively you could provide methods in your module, which return the needed markup when called from manually created template files.

Did you try to log the contents of $_SERVER['HTTP_X_REQUESTED_WITH']? Maybe this header is stripped out anywhere on the way to your local server.

That's just not how images work. You optimize the image size by using compression methods. But to manipulate (scale, …) an image it has to be decompressed first, so your optimization should in theory do next to nothing in terms of memory footprint. Also @horst already did his best to improve the image sizing tools as far as possible to detect memory exhaustion before actually hitting the limit. But there are just limits to what's detectable beforehand. P.S.: It's not advices to optimize source images at all, because the quality of thumbs will suffer (more than the compression did your source image)

Submit the form against the url without any pagination segments. Eg. action="/search/", instead of action="."

I recently looked into using chunked uploads to allow for file uploads beyond php limits. What I found is that it's not really simple to get the "actual" max upload filesize of php (more here). Also the max-dimensions are not really meant to prevent too big files. Anyway the results of my dive into chunked uploads can be found here: https://gist.github.com/LostKobrakai/ddb11c64dcb0f1bf1c8eed4dd534a868 I'll try to implement it in the core as soon as I find some more time, but currently it's tough to get to any open-source work.

The syntax error is detected by simply reading the file, while a php class showing up as module does require a bit more steps to be correct. So you're modules folder does have the same name as the xxx.module file and the module class? Your module is extending Process or implementing Module?

Do I understand this correctly, that the client does test the site on a different server than you local one? The question is not only if headers are correctly sent, but also if those headers make it to the server. Some hosters have crazy setups with nginx or even varnish in front of the actual webserver, so things could easily get lost on the way.

I'm quite sure that pages2pdf does not execute any javascript. You might be able to get what you need using google's static maps api, where maps are rendered as images, but that's not part of the mapmarker module. Also I'd suggest reading the terms of service in detail, not that such operations are prohibited by google.

You might want to read this: https://processwire.com/blog/posts/introducing-iftrunner-and-the-story-behind-it/

Depends on the use case. Think of a hero banner type of component showing a product fullsized right on the frontpage. That might easily need that size if it's retina ready.

First of all $users->find() is not interchangeable with $users->get() (just like with $pages). The first does return a list of users. While the second one does return the first found result. So $users->find() will find both your users, but returns them in a list. To limit your query like you asked to use $users->get("email=$email, roles!=superuser") I wouldn't say so. It's perfectly fine to allow for non-unique emails if one is aware of the consequences.

Also if coach_provincie is a page field, where you select provincies directly, this selector works as well: "coach_provincie=$page"

<div class="row"> <?php $coaches = $pages->find("coach_provincie=$page->title"); foreach ($coaches as $coach) { echo '<div class="col-md-6"><a href="'. $coach->url .'">'. $coach->title .'</a></div><div class="col-md-6">'. $coach->coach_locatie .'</div>'; } ?> </div> What about that?

It is, but it's not adviced to do so, because of the security risks involved. E.g. Ryan did recently move the php code for page fields out of the backend and replaced it with telling people to use hooks. But to run arbitrary php code look at eval().

Also you might skip the closing ?> if it's at the end of the file to keep trailing whitespace issues away.

Try this: https://github.com/processwire/processwire-issues/issues/28#issuecomment-252870084

Only if it's executed before or after template rendering, which is most of the time, but not always. That's why I go with this in places, where I cannot be sure about the state of output formatting: $page->getUnformatted('image')->first()->url

Sanitization does not have much to do with queries per se. You sanitize user input not the query. And to answer the question about automatisms. When editing a page the fieldtypes of the fields add their own sanitisation based on how things are set up (see Fieldtype::sanitizeValue and child classes). Elsewhere there's nothing automatically sanitized.

I've to agree with adrian. I'd also like to see api access to those theme colors, so if one does need to add custom styles in modules, they update with the theme settings.

It's mentioned in the linked docs page. You'd need to edit your php.ini. In case of an ubuntu os it's somewhere in /etc/php[7.0]/

There is, but it's not recommended, because you'd need to load all submitted entries into memory, which does not scale well. FormBuilder (and it's storage method) is not particularly well suited for such needs. You'd want to use pages for that use case as pages can be searched in db for particular field values.

<? ?> is removed in php 7.0 is only available with short_tags enabled in php, which it isn't by default, use <?= ?>, which are always available. See here: http://php.net/manual/de/language.basic-syntax.phptags.php

Yeah, but please also consider the subset of users not even using AOS.