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.

There's no search/filter functionality built into the module. The way I've previously done this is by rendering a custom select dropdown in a template panel, and hard-reloading the page with a query param. Not very elegant, but right in line with the requirements. This seems to be where others have landed as well. Anything more complicated, it's best to manage that in a module built for wrangling large amounts of data. A custom ProcessPageLister page or the commercial PageListerPro module have worked well in the past.

The cleanest way to do this currently is handling the request and preparing data inside /site/templates/home.php (controller) and then including a view from /site/templates/views/home.php. Using modules such as TemplateEngineFactory, this becomes the default. Prepare data in a PHP file, then render a Twig/Smarty/Latte view. It's certainly not as clean as having a proper controller class pattern available, that's for sure, but it's a pattern that works across projects of all sizes (at least in my experience).

@poljpocket Very true. From that perspective, it definitely makes sense to keep page classes lean und encourage proper separation of concerns. All frameworks have their conventions around distributing functionality. In Laravel, display logic might go into a ProductPresenter, admin form business logic into a ProductAdminController. In ProcessWire, we have ProductClass for display logic and ProductModule for business logic. That might not be for everybody, but it's more of a guiding principle than a hard requirement.

Please no ? I'll agree with this — a modular download is not required and would create more confusion than it helps clear. Newcomers don't know which modules they need ("what's a repeater?") and probably don't want to wade through a list of modules before trying out ProcessWire. Experienced devs tend to use most core features anyway, or work from their custom boilerplate repo. So I'm failing to see the benefit here, as file size shouldn't be of concern on a web server.

Thanks @ryan for taking the time and getting back to everybody's suggestions. It's great to see all the ideas and inputs in this thread. There's not much to like or dislike about how composer installs packages, it just happens to be how PHP projects pull in third-party packages these days. This is as much about making newcomers feel at home as it is about making the life of long-time devs easier. Right, WEBP output has been supported for a while. Upload is still limited to JPG/PNG/GIF/SVG, somewhat arbitrarily. JPEG is a lossy format, so why not allow WEBP source images as well — most images on the web today are WEBP, and browsers and operating systems have broad support. Extending the availabe output formats could be as simple as $image->format('webp')->width(200)->url. Semantic versioning is about unintended breaking changes as well — introducing new features brings with it the possibility of introducing new bugs, so even the difference between minor version (features) and patch version (fixes) is meaningful when deciding whether to upgrade a live site or not. That part (fixes vs. features) is probably known when bumping the version. Interesting, I'll need to check that one out, then. Sounds promising!

That's a perfectly reasonable position to take as a CMS. The editing experiencing itself doesn't need to resemble the viewing experience — most of our clients are perfectly happy with a well-implemented split-screen, where they edit the page blocks on the left, and get a live preview on the right. As long as changes mirror instantly without a hard reload, they get what they want. This would be already be amazing to have in the core. I remember this being part of ProDrafts, but it wasn't worth the investment just for that feature alone if you're not using the drafts feature as well.

I tend to agree with some of the previous posts: ProcessWire is doing a lot of things right, but it feels like there's some catching up to do in terms of open issues and general level of polish. Some of these are making ProcessWire look a bit long in the tooth compared to other CMSs — catching up with the ecosystem here would be a great signal that it's a mature and stable project keeping up with the times. Full composer installation: all core files living inside /vendor, any user files and modules outside of it Automated test suite: at least for the critical parts like the selector engine and php version compatibility Extend image format support: WEBP, AVIF, JPEG2000, etc as input and output formats, as well extensibility for future formats without major architectural changes Semantic versioning: there's currently no way of knowing if an upgrade brings bug fixes or new features (and possibly new bugs), they're all patch releases lately Environment variables: read config from .env files to avoid editing/overwriting config files for each environment nginx support: Apache is showing its age somewhat, and a lot of deployment solutions target nginx by default

@kater Unfortunately this isn't currently doable — there are some quirks around how ProcessWire determines if a user page is editable or not. Inside the Dashboard, there's no way of knowing whether a user page is editable by the current user. See this open issue and this one for more details on why this is the case.

There's a list of valid urls on Vimeo's oEmbed docs page that seems to match the ones mentioned in the issue. It doesn't mention video ids now being hexadecimal, however. vimeo.com/{video_id} vimeo.com/album/{album_id}/video/{video_id} vimeo.com/channels/{channel_id}/{video_id} vimeo.com/groups/{group_id}/videos/{video_id} vimeo.com/ondemand/{ondemand_id}/{video_id}

If you're on PHP 8 and a new-ish version of Latte, you should be able to use the nullsafe operator to safely get the value: <body n:class="$page?->category?->value"> On PHP 7, you can still use the similar nullish coalesce operator, which in this case behaves identically: <body n:class="$page->category->value ?? ''">