LostKobrakai

I'd not expect to much of the project as it's been in the state the website does show for about a year now? Can't remember correctly.

No problem. Just as you post your ideas I can post my concerns.

As someone maintaining a project with lots of different frontend templates I'd imagine you'd get into trouble way fast with such an approach. As soon as you've more than a few of those calls in your code base it'll get hard to reason about what's currently visible and what's not part of the markup, as you've to go through all those steps in your head. There's no scope of interaction. Each of those calls could potentially change everything in your page. I don't think it's a good idea to let you junior dev remove some class in some part of your website, which by accident could break other parts of it because the class is duplicated. With the current markup implementation you're at least bound to a (hopefully limited) number of named regions. I imagine it a bit like those early jquery webapp javascript files: a mess of spaghetti code which nobody but the creator can understand in a reasonable timeframe.

The question is what information do you need to pass into the js config?

You'd want to do a $session->logout() before deleting the user.

See Ryan's answer here:

You can put emoji in the database (use it in text fields), but you need to use the utf8mb4 charset for your tables, which you can choose on install. You can change it later as well, but I think there's no official upgrade path to do so.

The primer on the topic:

You could always turn those xml data into custom wire objects / a big wirearray. That way you could at least use the runtime selector engine of processwire. Not as powerful as selecting from the db, but still quite useful.

Afaik that's what Ryan does for the weekly processwire newsletter.

You could also just use the field access settings to not show the field to anyone besides superusers.

Yeah.

It depends. The admin.php is only executed if you visit the admin backend. If you add pages as part of any other page in your website the hook would need to be in site/ready.php. Also your hook was not correct. There's no Page::added hook (nor function), and in the Pages::added you can retrieve the saved page from the functions arguments. $this->wire()->addHookAfter('Pages::added', function($event) { $page = $event->arguments(0); if($page->template != 'xxx') return; $page->setAndSave([ 'page_select_field' => 1042, 'text_field' => 'Default Value' ]); });

$msg->children("sort=-created, limit=3")->reverse(); Is this what you're looking for?

I'm sure below 1000 of those clients you shouldn't really notice it. Especially as you're only loading the id's and not their whole pages. You could always improve that part later if you see any real life issues.

client.id!=1230|1230|1230 should work.

How about using a $pages->find() to just get the clients of your needed type for the timeframe (might be far less than the number of acps) and then use their id's to limit the count?

ProcessWire's image sizer engines can only work with files via the filesystem, so you'd need to mount S3 into it. Just keep in mind that this would slow down any image processing (download upfront and upload afterwards) and it means that all files need to be go through your mountpoint as files and images are in the same folders. Edit: And you should really evaluate to which degree your page does need image processing. If you can avoid it, you could just extend FieldtypeFile, which is way easier to work with than when you need the image sizer to work as well.

You'd create a Process module, which then triggers your custom function. Process modules are the modules, which render any information in the backend / show up as menu items in the navigation.

Your best bet would be to look at the PageFinder class. It's doing all the work of transforming selectors to mysql requests.

Both infos are stored in the "pages" table in the db: "parent_id" and "template_id". There's also "pages_parents", which lists all parents for each page, which is faster to query then building that table at runtime for each query. The template thing is probably quite easy to replicate for virtual pages, but searching pages by their parent-child relationship (deeper than 1 level down) is mostly dependent on the db.

I'm currently using the template access redirect feature for the first time in a while and noticed, that the redirect seems to be a permanent redirect. That seems odd especially as it does cause an "to many redirects" issue if I redirect the user back to that page after a login was successful.

There's no way to answer that question. It depends on what one might find "noticable", what version of php is used, which database and version of it is used (mariadb != mysql) and in the and also on the hardware used. Yeah they're all loaded. But really fieldsets are probably the fieldtype with the smallest footprint anyways.

That's true for the "1 or 2" fields question, but at bigger scale there can be harm, as it's more fields to load (each request does load all fields) and therefore also a bigger memory footprint.

There's also this, which I found far more convenient to hide some files, because it doesn't pipe all other file requests through php as well: http://modules.processwire.com/modules/fieldtype-secure-file/