LostKobrakai

There's also the following, but be aware the stock module on github has some bugs (see my PRs). I'm also not sure how well it works with pw 3.x. I've used it in the past for assigning multiple types of roles to customer sections in a page.

In PHP functions do not inherit variables from the parent scope. Even closures (unlike many other languages) don't do so unless explicitly stated by `function() use ($var, …) {}`

Since sessions are maintained by cookies and cookies are bound to domains the answer is no – you cannot share a session between domains. What you can do is have only a single domain handle authentication, and all other domains fetch information from that service. See for example oauth or openid connect systems. That‘s rather complex though and not something available in processwire as is.

The spec for http 1.1 (rfc 7231) only specifies the behaviour of the location header for http 201 and 3xx. I'm not sure it's a good idea to depend on undocumented behaviour of not setting a proper 3xx status code. Especially as this seems to happen even when explicitly calling: $session->redirect($url, 302); This not setting a http status code is waiting to cause people trouble. One isn't always dealing with browsers, which are usually quite forgiving.

Using / as dividers signifies an American date format of MM/DD/YYYY, which makes only the latter invalid.

It's neither. Pages are objects and field values are stored within that object. If the field was not yet accessed it will be loaded and stored. After that it'll directly use the value in memory. Most often people wouldn't even refer to that as caching as it's still just stored in memory and for the current request only – but tech. it is a form of caching.

That's because the file input field uses ajax requests for the files. So each request only holds a single file.

Imo the most important part missing in conversations about one language vs. the other is context. Just using features for comparison is useful mostly to fanboys. One needs to look at existing knowledge, time to learn, amount of benefit from the learned language (short term and long term), team dynamics (hiring, on-boarding, finding devs already fluent), existing code, …. There's a reason there's so much PHP written for things objectively much simpler done in other languages – because all the above things often outweigh changing away from PHP. Like everything async/stateful (even just websockets) is a pain in the ass in php, because the common way to deploy php is stateless. Does that stop people from doing that with PHP? Nope, people take on a bunch of complexity to do it even with languages/runtimes out there much more suited to the task. Take the leap from webdev to ML and the context is completely different. Suddenly things like existing code don't exist anymore, ML is "new". ML needs to be learned anyway, so existing PHP knowledge is vain. Other people mostly use python for ML, so it makes sense to use them. Short term there's a clear benefit in moving to python for ML. The same should apply to green field projects, but what today is actually properly green field (including team knowledge and such).

Wouldn't it make sense to use PRs on GitHub for such suggestions?

$this is a special variable within classes to refer to the current instance. It's simply not available in hooks. But $event->object should refer to the current object instance, but I'd expect you'll only have access to public methods and properties that way. So because of the context switch (within the class vs. outside) you might still need to change things.

In MySQL `NULL` is always less then any non-null value. Therefore you either need to sort at runtime, somehow make the sql query issued sort by `ISNULL(col), col` with different directions or use my paginator module for paginating though multiple different selectors: https://github.com/LostKobrakai/Paginator

If you have highly variable load I'd suggest going with something like heroku for manual scaling (if planable) or even solutions, which can automatically scale. No need to run a super beefy server for a whole month if only a single day has actual load. 25k/hour is around 7req/s (likely higher for varying load over the duration of the hour), so either requests must be served in <1/7s or you need more server instances.

Or a time column instead of a datetime one, removing the complexity all together.

Is this documented somewhere? Feels like a gross implementation detail bound to change at any given point in time. Using this would imo be the proper solution:

There are three parts from my perspective: Filesystem => Have wordpress and processwire in separate folders URLs => You need to find a (likely .htaccess) way to move certain paths away from wordpress to processwire Migration => How do you deal with migration needs to be clarified. Can you have downtime between taking wordpress content down and pushing the pw replacement up? How much downtime is ok? All of those are solvable problems. The complexity of the last part mostly depends on how much downtime you're allowed. The less time the more automated things need to be.

Yes and no. It might pre-compile some pages like e.g. all the category listings of blog posts. But those are not dynamic by something the user requests, but those are added by a developer to be created at buildtime. Say your SSG has access to all your blogposts. It can easily aggregate them by tags and create pages for "/blog/tag/static-site-generator". But it can't precompile a site where a user searched for "Static Site" in a search box and showing results.

11ty is great. It's super flexible and doesn't lock you into a certain way of using it or fixed templating. Static site generators make a lot of sense for anything in the realms of corporate or product marketing page. You can keep all the stuff, which rarely changes in plain html. Form submissions and such can just be sent to a different headless endpoint. There's also things like Netlify CMS or similar tools, which allow you to trigger rebuilds whenever something in the underlying data changes. This is nice if you don't want to involve a dev every time some copy changes. For more dynamic content like e.g. comments I'd still not use a static site generator. They make sense if the cost of rebuilding for each change is outweight by the simplicity of deployment / putting the site up somewhere, but not really if you're constantly rebuilding. I don't really subscribe to the idea of having highly dynamic content just rendered client side, but people do use ssg's as an alternative to the dreaded SPA. Dynamic content is still all loaded/rendered in js, but at least it's multi page with some static bits.

With 5 million pages do people actually click through who knows how many pages you get? Generally offset/limit pagination scales quite badly because it always needs to count the offset part as well. So the higher the page number (offset) the slower the query will get. For big datasets cursor based pagination is usually adviced, but on processwire you‘d need custom sql for that. Also it will no longer give you pagination in terms of „you‘re on page 6043 of 20383“. You can only do next/prev. But from an UX pov page numbers that big aren‘t useful in the first place. Having means of filtering down to a more manageable result set is what I would rather strive for.

It's a topic on the lister pro support forum, which is only accessible to people with lister pro licenses.

Your client is wrong in stating this is not relational. Tables and relationships between them is what processwire does. Just differently than your client seems to be expecting it. On the other hand I feel you did miss out on proper up front communication about the requirements of your client. It's great if you want them to move on from joomla, but moving to a different system, which doesn't work for your client is worse than an old problematic one. I'd try to get back to the drawing board and evaluate more closely what the needs of your client actually are, do some demos with processwire and see if it actually can fit or not. Maybe for as long as it's "stock" wordpress, but even then things like the guttenberg editor are unstructured data in wp. I'd not say it's a good example of an relational database structure. Even more so considering how you interact with those records within php.

Generally I think event handling can quite easily happen outside of processwire with something like https://event.thephpleague.com/2.0/.

This is not the whole picture. Simple fields might only have a single `data` column, but complex ones might have many more. Also multi-language support does work by adding `data_{lang}` columns to those field tables. Though I can see the argument for having template (or more correctly fieldgroup) based tables, where columns of fields would be merged into an single table.

Nicely done. I like the color schema a lot. You might want to make the "Los geht's" CTA a bit more clear though. I wasn't really sure what I need to do/click on the introductory page. Also I feel more whitespace after it wouldn't hurt as well.

There's now a free and open source version similar to sizzy available: https://responsively.app/

I would've never expected it to work like that. Good to know.