Leaderboard

A good feeling to have! Thank you for your tireless improvements to PW!

This week I kept working on what's been in progress the last couple of weeks. That wasn't really the plan, as I was hoping to move on to other parts of the core. But I found it a took a lot of time to adjust everything to the new code and classes, and to refactor and remove other chunks of code that could either be simplified or removed. So these last few weeks of updates took a lot more time than I expected, and it's one of those things where once I got into it I felt I had to keep working until it was done as well as it could be. That meant getting pretty deep into some core logic. So in hindsight I'm slightly regretting refactoring so much code without major short-term benefits that can make more interesting reading here. And there are perhaps some short-term drawbacks in potentially introducing new bugs, as goes with any new code. But that's how it is sometimes. The good news is that it's a definite improvement in quality and I have no doubt there will be long term benefits especially in terms of improved performance and maintainability. But in any case, I'm glad to be wrapping up these particular updates so that I can move on to other parts of the core and Pro modules, and hopefully I'll have more interesting stuff to write about next time. One small addition you might find useful in these updates is that you can now identify the closest matching page when a 404 occurs. Maybe you want to provide a hint to users that land on a 404 as to what page they might have been looking for. Now you can do this in your 404 page template file: $p = $pages->request()->getClosestPage(); if($p->id > 1) { echo "<p>Were you looking for <a href='$p->url'>$p->title</a>?</p>"; } Like last week I'm not bumping the dev branch core version just yet because I don't want to trigger any upgrade alerts that might prompt people to upgrade immediately. I'd rather focus more on testing and leave these updates to those that are interested in that testing, helping to track down any issues. Thanks in advance for your help with testing these updates. Likewise, thanks for reading, I hope you have a great weekend!

@millipedia So with you on that! Took time to actually learn CSS, and while it's constantly changing, decided to to lose the "Sara Lee" approach - layer upon layer upon layer. Spent far too much time overriding framework defaults instead of actually doing stuff. Now I use SCSS to combine global resets, default classes, colours etc then add small per template or component stylesheets. Same for any per template JS. In the supply-chain world this is referred to as "just in time" vs "just in case"

I'm with you in that I like the look of Tailwind but I've never quite found the right project to justify using it. These days I rarely use a framework at all. Support for flexbox and grid has meant that a lot of the advantages of using a framework don't apply any more. Browsers are a lot more consistent these days as well, so there's not as much need for polyfills and resets and vendor specific tweaks that might have been baked in to a framework. My starting point for a project is a single CSS file that has some minimal styles and utilities in that I'm pretty sure I'll always need. Originally that was based on Wing css but I've tweaked and added to it over the years. I then have other css files for components that I've used over the years - so if I need an off screen menu for example I have one that I can reuse and adapt. The same applies to javascript; In the old days (a couple of years ago anyway) I would have just included jQuery by default in a project but now I just have a few native javascript functions I can include when I need to. Most of the work we do is pretty bespoke stuff so this works better for us. I imagine that if you were doing lots of sites that were fairly similar then a framework might be useful. One situation we would use a framework for is when we need to do an admin interface (we a did a great project that had a SMS bot the client could manage for example). For that we've used ModularAdmin which is based on Bootstrap 4 (and which hasn't been updated for a few years so probably not that useful a link). Now I'm essentially a solo dev, so bespoke code is easy to manage. If you're part of a larger team (or looking for a job) then I bet having decent documentation and consistency is much more important so learning a framework is probably a smart move.

Was looking into this actually, but then you'd want to isolate the sites from each other which means php-fpm etc. I got it running recently, so its not impossible, but it feels way less robust than some docker based setup. If something is up with apache/nginx ALL sites go down, etc.

Not sure this is strictly a shared server issue. I find that I want to update data structures and settings pages, but don’t want to overwrite user-updated pages so database backup and restore (or phpmyadmin) doesn’t work. That’s why I wrote ProcessDbMigrate - still in alpha but usable provided everything is tested first. Or, if you prefer to do it all in code with the api, rather than in UI, there is RockMigrations.

I think something like ploi.io or runcloud could work for you. I personally use Runcloud but they appear to be moving slower than ploi "feature wise" although it has worked perfectly for all the sites I manage and their support is fair for the paid price. Both this services clear your goals from 0 to 4 in one way or another. I also think both has some sort of deployment tool integrated with any git repo (which I don't personally use but i think it's there). One "downside" is that ploi doesn't have Apache server configuration they went full nginx though I know there's some crew around here running PW with no issues on nginx. Aside from that, they do seem superior feature-wise. For example, there you can have db only servers, load balancers. The worse part of Runcloud in my opinion is it's per-site backup service which is a service provided by them, Ploi lets you use your own storage (s3 for example). One thing both services have is cloning one "app" into another one, or another server, at least I can confirm this on Runcloud, but seems to exist in ploi too and it's super handful. Another way I do this is through CI services (like Github Actions) and basically doing some shell scripting which is not too bad for all the time saved. In the Github Actions I basically rsync template files/modules and run the migrations module through it's CLI but I rarely push actual content since it's managed by a third party. While on development, I do still use plain old cli mysql import, scp the things or run ngrok to save the hassle of doing previous steps if I just want to quickly demo sth, but tbh it's just lazy on my part I bet it can be easily automated. EDIT: Another trick I do some other times is ssh tunnel a db connection to the actual server. Which is something that moving away from shared hosting makes really simple ? I am also trying to find the time to explore deployment using docker but well, just a plan for when I have some spare time. Check this thread too for other opininons/services:

We have the identical situation, same error an all edit pages since 3.0.184 because of the following error: Strangely enough, we don't use the new field InputfieldTextTags at all yet! As hotfix, we have surrounded the JSON.parse() call with try ... catch statement: try { var o = JSON.parse($select.attr('data-opts')); } catch (e) { return } But this cannot remain a permanent solution. Are there any other findings on this problem yet? Best Regards, Thomas.

I found this module, maybe it is of your interest. The module says: // It's called for each page that's being saved, no matter if it's in the backend or in your templates via the api. https://processwire-recipes.com/recipes/extending-page-save-process/