d'Hinnisdaël

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 ?? ''">

@TomPich The sprit of the module would be to keep it simple, and create the more complex pieces as separate admin pages. The canonical solution would be the ListerPro module, but this can be done without commercial modules using just the built-in Lister process module that is the basis for ListerPro.

@TomPich Nothing built in, so far. Philosophically, I've seen the dashboard as a jumping-off point for users to get oriented, then go off somewhere else in the admin to do more serious work. My suggestion would be configuring a separate admin Lister page with filters, or building a custom Process module if you're feeling adventurous. That said, there are ways of doing this manually: Option 1: render a select input using a `template` type panel, with some JS to auto-submit the form on change. In your php file defining the available dashboard panels, you can then use that input parameter to pre-filter the results. This only works smoothly with selects where a full page reload is acceptable UX, so text inputs would require a different solution. Option 2: create multiple panel tabs, one tab for each available filter option. Still, not very useful for text inputs.

@TomPich I see. Glad you got it solved. This might easily break your setup when updating the module, though. If you feel strongly about re-enabling the custom date formats, feel free to open an issue on the GitHub repo!

@TomPich If the "date" field is an actual date field type (as opposed to an integer field storing the raw timestamp), this should work out of the box. The module knows about date fields and how to format them with using a custom format. If you're storing the timestamp as an integer, I'd suggest switching to an actual date field and getting the raw timestamp from that date field in the frontend instead: $page->getUnformatted('date') will usually get you the non-formatted timestamp as integer.

@da² There's an official Twig-2-Latte converter that's really useful if you aim to compare both engines side-by-side. You can try it out online as well.

@da² Latte doesn't have those issues since Latte code is compiled directly to PHP. There's no magic methods and no funky business with dynamic properties. Everything should work as you would expect it to work in a plain PHP file. There's a short but relevant section in their docs on using PHP in Latte files. I've never seen a project where Latte was a performance bottleneck — it's compiled to PHP and cached, so it should be just as fast as a normal PHP file. Usually, it's the amount of database queries and lack of granular caching that slows a site down. If the template engine is the biggest contributor to load times, you probably have a pretty fast site already ?

Setting $view->template is perfectly safe, it's currently undocumented but that's how I'm using it in every project so it's not going anywhere. Uncommenting the $compiler line is fine as well — required, actually. The line was left over from the previous version but only works with Latte 2. In Latte 3, that line will cause an error. I'll take a note to remove that line in the current version to avoid tripping people up.