d'Hinnisdaël

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 ?