LostKobrakai

If you don't need sessions on your frontend you can disable them. Otherwise this seems fine.

You're correct that data string values are only translated for find queries, but not runtime selectors. But processwire just uses `strtotime` so you can easily use that on your own: strtotime('today')

This might be a quick fix, but for me this rather looks like a FieldtypeUnit, which fully deals with the fact that you're storing an amount of a unit. With the unit being available alongside the integer at runtime would give you the additional ability to handle the value to it's full extend like being able to converting weeks to days or grams to kilograms. A integer is just a single number but e.g. 60 seconds are just a different representation of the same value of 1 minute.

Imo the overall backlash on jQuery is less about jQuery vs. vanilla, but jQuery vs. less messy abstractions. For ajax there's no need for jQuery anymore with other libraries taking their turn being just as good without being bundled with all the other jQuery stuff. And for DOM manipulations I feel twofold: For simple stuff jQuery is hardly shorter/easier to write than vanilla js + 2 or 3 small helper libraries (e.g. for event delegation) and for everything more advanced jQuery code most of the time is just a mess of one-off manipulations and implementation details mixed with a bunch of event callbacks. These are the places where I feel react / vue / ember or for a really vanilla feel svelte are far better equipped.

Just look at the modules code. It's just a few handful of code and a single hook.

http://modules.processwire.com/modules/process-page-list-multiple-sorting/

The problem is that those issues are a hard problem to deal with, which is why there are dedicated software solutions out there just dealing with search. Especially the spelling mistakes are really difficult to come by. Also generalised solutions mean this is a issue of the database, so MySQL for processwire, but in your case (small scale) you could also try to improve things from the PHP side.

And be sure to use https as always

Fuzzy matching like one is expecting nowadays of a good search field is actually quite difficult to do with mysql. If you need a fast search returning relevant content for such short search terms you're most often better served using something like elasticsearch or angolia.

The best thing with it are all the pull-requests happening for this piece of code, which won't probably be run anymore.

In ProcessWire each page is defined in a single db table, while each field you create does have a own table, where data is linked to a page. So "denormalization" to having each image be a single page with image/description/notes/… will still be stored kinda like in your old setup. The page-tree / templates don't actually represent any db based normalization as they're basically the pages, pages_parents, templates tables in the db. They've no influence at all about how actual data is stored.

It's ProcessPageView::getPage(), but it's a protected function and therefore not for public consumption as per right now.

$input is a wrapper for superglobals like $_POST and both do not support reading the request body.

All the logic you're talking about here is already there that's true, but it's quite inacceasable in the ProcessPageView class.

This question does not really matter, as there just are no page level permission in processwire and propably never will be. ProcessWire is build around template level permissions reaching deep into quite a bit of core functionality and page-level permissions are not really a requirement for a simple cms anyways (we're not talking enterprice grade). Though there are actually quite a few 3rd party modules to make access management more granular in various ways.

You're mixing up routing and $pages->get($path), which are totally unrelated. The Pages class is using the PageFinder to retrieve pages from the database. In no way is that operation concerned with url segments or any routing operations. Url segments are resolved as part of the ProcessPageView module, which is doing the initial matching of request url to an actual page in the database.

I'd use two endpoints for each modal (or one if you want to differenciate by content type header). One would return the modal content (if I understand that correctly, that's what your users create) and one for "modal settings", which would just return a json string of those options. Your external system can then use an ajax request to query the options - sanitize them and merge with own options - and start the modal with the results. Edit: Having the modal page itself pass the options probably won't work as the modal first needs to be opened before the iframe is even loaded - at least that's what I would expect.

You're dismissing the page-tree, which really is the primary tool for getting to visible/editable content in processwire from the start, but then wonder why it's so difficult to add functionality for editing content elsewhere because you just removed most of what was already there. That's a strange conclusion to draw. Setting up custom pages for sections of your page can be done with process modules as you've already gathered. People have been using custom page-trees or custom listers (lister pro if you don't want to get your hands dirty). The best example here is the core itself, where the listing of users is a custom process module, which handles all the additional needs for managing users and it's still just using the basic core lister module beneath. To automate the process of creating any of these as actual pages in the admin tree I'd use something like this: There is no such thing as "permissions for a page" in processwire. Permissions are granted to templates, which is why editing permissions makes most sense in the template edit section.

The default is the theme used if users do not have a admin theme saved in the db (mostly new users afaik).

Maybe you want to clarify a few things here: You're talking about an iframe. What's the page holding the iframe and what the page within the iframe? What's the javascript you're trying to execute and where in the iframe story does it belong?

I'd support @Robin S solution. Generating JS is something I would avoid at all cost if there's a way to have a fixed js just comsume changes from a plain datastructure.

Maybe like this https://pragprog.com/book/btlang/seven-languages-in-seven-weeks. Not the right languages, but I've heard it's quite good.

The problem with such a system is that it'll always be skewed towards "does not work" simply because when a module does work people are very likely to move on without any feedback while the ones where there's a problem with the module are likely to complain somewhere.

What's the number of fields/templates?

The grid-template-areas field might want to sport a monospace font for better alignment of those single letter area names