LostKobrakai

In your first version you can use ->find() on $prCodePages again to filter by single code in memory. This way you retrieve codes in one sweep from the db and filter them later to get results by single code.

Issue 1/2/3(/6) are all settings processwire doesn't have control over, as they are dependent on the webserver setup of your specific hoster. Issues 4/5 are probably follow up issues of your issue no 3. If your image/file uploads aren't working correctly it's easy to get in a state, where your assets/files folder and your database are out of sync, which can cause all kinds of errors if your code didn't account for these kinds of edge cases or the system is simply not meant to be usable in that state. That's where a (correctly installed) fresh install does help. It ensures that you start from a clean (known to be working) state.

I'd evaluate if the image really should be a background image in the first place. Otherwise this is the only way to have dynamic css backgrounds. I've added a bit more flexible version of yours below. <style type="text/css"> <?php // Selectors overwrite each other (by order) so no need for different mq selectors // Eg. xlarge (true) -> large (false by mq) -> medium (false by mq) => xlarge image // Eg. xlarte (true) -> large (true by mq) -> medium (true by mq) => medium image // Reverse order (default still first) when using min-width mqs foreach (['xlarge' => "", 'large' => "1499px", 'medium' => "849px"] as $imgSize => $mq) { if(strlen($mq)) echo "@media screen and (max-width: $mq) {"; echo ".image-$item->id { background-image: url('" . getImage($item, $imgSize) . "'); }";; if(strlen($mq)) echo "}"; } ?> </style>

Background images do not need anything new. Just use media queries to target viewport sizes.

I'd suggest you to not waste your time and use srcset/picture element. If you really need to worry about browser support add picturefil to your page as well. Selection of best image size is simply best left to the browser and anything else probably isn't better than the picturefil polyfill.

Yep, you'd need to translate each string on it's own. And keep in mind that translatable strings need all to be on a separate line for parsing reasons.

That's because PageTables do not have any kind of field-specific api. They're just another form of page field.

$u->save() should return false (instead of an user object) if there were any issues while saving the user.

There are also field access settings, just to be sure you're aware of them.

I always though graphql would only be for qraph databases, but really this looks damn rad.

If you enable $config->advanced you can have a look at the system tab in each of your templates. There you can prevent pages of a template to be trashable. But I'd be cautious with enabling the trash for the user template as you might find issues with trashed users not behaving exactly like non-existing ones.

First this must be merged/approved by Ryan

With the new .csv option for exporting translations of multiple files combined it wasn't to bad to get something working: https://github.com/processwire/processwire/pull/52

Blackfire is nice, but ProcessWire is not as linear as this Screenshot does look like. ProcessWire's graph is more circular as most method calls go through Wire::__call() to be hookable.

That's the bad part about module translation. There's no standard way to share those translations and even less a way to install those automatically, as there's no notion of a "Dutch Language" in ProcessWire. Simply export the translation (as json format if PW <3.0) and add it to your modules files. People can then import it on their own.

There's no need for an additional $pages->get() here. $pages->find() will already retrieve those pages. $items = $pages->find("some=selector"); foreach($items as $item) { // $item === $pages->get($item->id); echo $item->title; }

That file mentioned in the error doesn't seem to belong to processwire.

index.php ProcessWire Bootstrap Module Init (Hooks to ProcessWire::init) init.php ProcessWire Core ready Hooks to ProcessWire::ready ready.php Template Rendering prependedTemplateFiles template.php appendedTemplateFiles Hooks to ProcessWire::finished finished.php Shutdown This should be almost complete, but I don't guarantee about anything

That was the wrong way. Do not try to use a hook on Pages, but rather look at ProcessPageEdit and it's hooks.

Read up on this part of the hooks docs: https://processwire.com/api/hooks/#all_or_one

Where's $form from?

ProcessWire's session / authentication does not work without cookies. I don't even know of other projects which would do so.

It's the language choosen for that user in the backend. For non logged-in users it's the language of the guest user.

You could also simply add a notification on your homepage, where you suggest users an link to their browsers language instead of forcing a redirect on them. Then you'd only have to get a different language for the notification and everything else can stay automatically translated.

I'm not sure why a redirect should be bad. I mean lot's of pages to redirect to www.* pages or from http:// to https://, or from an old contents location to a new one. Also regarding the session: Everybody does get a session, which doesn't mean that all of them are actually logged in.