d'Hinnisdaël

Rather late to the party, but congratulations to everybody involved on the website redesign! It's turned out really well. Such a clear and fun design for a CMS, I like it better with every minute. One thing that doesn't quite work yet (I think) are the admin screenshots on the homepage. These could be much more lively and colorful. As in: examples of working with images and other multimedia content in the backend. Sure, the tables and custom fields are important, the search, filter, etc. But it's all rather dry. And I kind of miss the skyscrapers, they lent themselves to integrating images easily. Or maybe it's time for trees or birds. As someone said before, keeping the skyscrapers comes with some free brand recognition. I agree that not of all the animations make actual sense or match the text beside them, but that's... okay? They're fun to look at, and the text is large and easy to read.

SQLite support would be especially great to signal that ProcessWire prioritizes ease of installation. It's a sane, pragmatic default that avoids the hassle of networked databases. I would assume 80% of new sites to just use that over MySQL if it was available. That said, the selector engine and quite a few third-party modules probably do rely a lot on the strongly typed columns of MariaDB, so I'm not sure how feasible this really is. Types in SQLite are very unintuitive, coming from the MySQL world.

@FireWire Sure! Wouldn't say no to a PR implementing this. I think there's a long-standing feature request in the core for disabling modules (as opposed to completely uninstalling them). That would be the ideal solution of course 🙂 But yeah, having it in the module is a close second, I'd say.

I would like to echo the request to get back proper checkboxes. ProcessWire provides distinct inputfields for checkboxes vs. toggles, so I'm confused to find that all of them now look like toggles. It's rather unintuitive and, as Bernhard mentioned, not amazing for module developers. Not sure what problem the global switch to toggles was solving, but I don't think there was a problem to begin with. Checkboxes are great, toggles are great, let's keep them separate 🙂

Separate color pickers for main color (light) and main color (dark) sound like a good solution to allow proper branding while still being accessible. Also, I would like to second the request for adding CSS variables for the border radius. There are some great additions in the new theme to make things more customizable, but to call it truly "customizable", it should offer the possibility of changing the border radius on buttons and inputs. The current look (very round buttons + completely square inputs) is a bit peculiar, but that's okay as long as we get a way of tuning things ourselves 🙂

@Jules Vau The hashes (or in your case, color codes) are stored as filedata. If you have access to the Pageimage object, this should do: $type = $image->filedata("image-placeholder-type"); $hash = $image->filedata("image-placeholder-data");

I've created a fork of the previous version a while ago that adds support for aspect ratios. Been working great for years, and haven't seen a need to update to the newer version. Here's the fork and the git diff in case you're still on v1. The newer v2 seems to be a complete rewrite, so...

Thanks @Noboru for the pointer! I've released version 0.3.1 with your suggested fix.

@FireWire The placeholders are cached and there's no logic for regenerating anything on module refresh, especially not globally, so that'd be a surprise for me at least. Are you sure it's related to this module? Feel free to share the exception stacktrace in case.

@FireWire Thanks for the heads-up! So you're saying it's currently working but will break in a future version of ProcessWire? Is there a specific release that triggers the issue on your end? The module should probably also reset the output formatting state to the value it was before setting it to false, just in case.

@wbmnfktr The ecosystem of available packages and services is definitely one of the major draws of Laravel. It almost parallels the Wordpress ecosystem, but ten times more professional. A lot of Laravel packages are very high quality, actively maintained, well tested, etc. That's probably a result of their somewhat "enterprisey" approach to structuring a project. Dependency injection, containers, service providers, those are all great approaches for professional projects, but they do require some commitment to learning these specific concepts. ProcessWire's approach to extension via hooking is almost the complete opposite of Laravel's container resolution approach. They're both flexible and ergonomic, but ProcessWire's a lot more approachable and easier to grok for newcomers I think. Being able to replace an internal handler in three lines without copy-pasting the whole class is really magical.

Asking an AI about the downsides of any versioning scheme will produce a list like that, not sure if that's helpful ? The word "easily" is doing a lot of work here — I don't think it's easy to read through every commit in a three-month span when doing quarterly updates of a ProcessWire instance. And while an experienced ProcessWire dev might be able to spot an issue, we can't expect newcomers to read the source code to determine if an upgrade is safe or not. If we want to grow the community, a public changelog shouldn't be controversial in 2024. The marketing aspect of an LTS versioning scheme is a good point. The danger is of course the "L" in LTS — not sure if there's much appetite to keep supporting releases other than the current one, unless it's sponsored or tied to a paid support tier. Not calling it LTS but e.g. "focus release" would of course get rid of that problem. The idea is nice in any case — communicating the current development focus.

At the risk of repeating myself: semantic versioning would be a small but extremely helpful step toward a more seamless upgrade experience. Having an unusual versioning scheme would be perfectly fine if there was a public changelog available. Currently, upgrading is a crapshoot — you can't tell from the version number if it's a fix release or a feature release, and there's no changelog to help figure it out. Going source-diving is an option, but not feasible for every single update. One could stick with the master version, but the latest master was released 11 months ago and it's common to aim for quarterly security updates, so we're back to the dev branch.

The animation on the homepage is a bit hard too read at its current size. Getting rid of the iMac and the IDE background and showing just the Safari windows should allow things to get a bit larger. Apart from that, the design of the site is fine in my opinion. Not sure if a complete overhaul is a great investment of time here. I agree that the content of the demo site should be unrelated to the ProcessWire ecosystem to make it relatable and understandable by newcomers. Skycrapers were and are pretty great here. Birds would also be fun ? If we create and link to demo sites, I'd be wary of using (too many) commercial modules. Otherwise we're creating the impression that people need to buy a bunch of paid modules to create nice websites with ProcessWire. We should definitely strive for a commercial module showcase, but mixing that with demos sends the wrong signal in my opinion.

I was suggesting you link to a separate page that is handled by ListerPro. I don't think it's possible to render a ListerPro page into a dashboard panel. If you absolutely require filtering in a dashboard panel, I'm afraid you'll have to develop that yourself as there's really no ready-to-go solution available yet.