d'Hinnisdaël

I think your reasoning is sound. Especially for blocks that are re-used across pages (which I didn't have in mind).

I see. In that case creating a custom field would probably be best and have little overhead if it's autoloaded. What's the reasoning behind storing the data on the parent and not on the children? Performance? Storing it on the children, you could use the `$page->meta()` api and avoid the need for hooks since that should be cloned alongside the page. It currently only allows associative arrays and might have a performance penalty as well.

Shouldn't it be enough to associate the styles with the block page's id and make sure cloning a page also clones its associated styles? If you assign a unique id (pgrid_id) to each block but keep that around after cloning, you won't be able to edit the cloned page's styles without it affecting the original page's styles. Or maybe I'm missing a part of the picture here.

It's working great, we're not missing much in terms of features. I think ploi did at some point offer Apache + Nginx but scrapped the option. We're running ProcessWire on Nginx now. It requires some extra work here and there but is running smoothly overall.

Having a sanctioned way for creating "dynamic" routes would definitely be a worthwhile addition to the core. I've settled on creating JSON endpoints as separate templates and implementing the routing inside the template file. Sometimes a switch statement is enough, sometimes FastRoute makes more sense. It tends to be a lot of boilerplate even for simple tasks. I agree with Ryan that piggybacking on 404s is technically correct even though somewhat of a misnomer. It ensures that regular pages always have priority when routing a request. In the case of conflicts with a module, the site has a way of overwriting and customising the routes.

@MarkE There's currently no direct way to do this — the chart data is passed as a JSON blob, so no functions. I've been looking at setting up charts via JS files or JSON endpoints, but nothing concrete yet. I'll probably end up moving the chart panel to a chartkick.js implementation which would allow all of that.

@MarkE Callback function in what context? What's the goal?

There's currently no way of grouping panels in tabs. What'd be your use case?

@schwarzdesign Thanks for reporting. I'm afraid there's no easy solution without changing how the core handles user edit permissions. Currently, the editable() check fails for all processes other than the default page-edit or page-lister ones. That's why it doesn't work in the context of the Dashboard process. See the corresponding source code of PagePermissions.module. I'm not sure why it's done this way and if there's a chance to get this opened up. I'd suggest you open an issue in the official ProcessWire repo to get a discussion started. Checking for user-admin permissions as a special case sounds good but won't solve the problem: the user permissions are a lot more complex when you're handling superusers vs. non-superusers and multi-layer permission systems. There's user-admin-all and any combination of user-admin-[role] permissions we'd have to check manually. It's definitely better than the current state, though. I might implement this in the near future.

+1 for a solid database migration mechanism. Deploying field/template updates to production involves a lot of manual copy/pasting. Having a built-in way of describing changes in database structure would make automated deployments and rollbacks possible.

The module seems stable enough to bump to version 1.0. Notable changes Declare a private namespace, solving install issues Require the latest ProcessWire master version 3.0.165 Add a new panel type Add New Page which recreates the core add-page shortcut menu

We've switched most of our servers to a setup of Hetzner VPS managed via Ploi. I haven't found many differences between Cloudways, ServerPilot, Moss, Ploi, etc. if all you're doing is hosting simple Laravel or ProcessWire sites. The main advantage seems to be speed here — compared to shared hosting, the sites are between 4 to 10 times faster even when hosted on the cheapest Hetzner instance at 3$/month and with security and updates taken care by Ploi. We liked Ploi because it's great at regular backups, has lots of notification channels for automatic deploys and the admin panel is very polished.

Looks great! Thanks for releasing this as a public module. Does this theme do away with all colors? How does it handle warnings and error states?

Does anybody else feel like the login screen could use a revamp? While it might not be the most important thing in the world, first impressions count. On large(r) screens the login form seems to get lost in the upper third. The rest of the admin looks a lot cleaner and more deliberate. A few tweaks would go a long way in making the login screen work on all device sizes. Those are two custom styles I've been adding to my sites lately, one PW-branded and one not. No markup changes needed, just CSS. This second one borrows heavily from Twill's login screen. The floating environment label has turned out to be really useful to see at a glance if one is editing on staging or live. Not sure if there's a way to make this 100% core compatible.

I've gone ahead and created a separate repo for third-party and Pro modules. Looking forward to having forum users test these and contribute with their own translations. daun/pw-lang-de-modules While the list of modules to include is obviously subjective, I've started with the ones my non-technical clients tend to use on their own (in alphabetical order): Dashboard Jumplinks PageListerPro PageLister Actions Delete Email Set field Set status ProcessWire Upgrade ProFields Table

Hi @Mike Rockett, first of all thanks for this wonderful module! Been using this for a while but never stopped by to say thanks. I just sent two pull requests your way I'd love to get your take on. The first one makes the module work well with multi-language sites by adding a hook for modifying the Typographer Settings instance. The second one just updates the underlying php-typography package, while we're at it.

Just a quick note that the above example will need an adjustment if the site uses a non-default asset folder or url. To make this work when serving assets from, say, /data/* or assets.domain.com/v1/*, we can use the path and url settings for the files folder instead of root. if ('url' === $event->method) { $file = $config->paths->files . substr($file, strlen($config->urls->files)); }

How does everybody feel about creating a separate language pack for official and/or popular modules which would usually be in the site folder? I just noticed the Norwegian language pack making that switch. Especially for the Pro modules (Lister, FormBuilder) it would be nice to have a drop-in solution. And if you don't need them, just install the core language pack and everything stays the same. As far as I can tell, the current de-DE language pack doesn't include module translations, right? I'd be willing to create a repo and get things rolling.

Just reading through the thread now, that looks very promising! Working with event dates from the API/selector side is quite messy but it seems like it doesn't have to be ?

Format Datetime fields as Carbon instances. You can find the latest release and the complete readme on Github. Installation composer require daun/datetime-carbon-format Usage All Datetime fields will now be formatted as Carbon instances instead of strings. Some examples: // $page->date is a Datetime field // Output format: j/n/Y echo $page->date; // 20/10/2020 echo $page->date->add('7 days'); // 27/10/2020 echo $page->date->format('l, F j'); // Monday, October 20 echo $page->date->year; // 2020 echo $page->date->diffForHumans(); // 28 minutes ago Frontend only The ProcessWire admin seems to expect datetime fields to be strings. This module will only return Carbon instances on frontend page views. Date output format When casting a Carbon instance to a string (usually when outputting the field in a template), the field's date output format will be respected. Links GitHub • Readme • Carbon docs PS. I remember reading about a Carbon module in a recent newsletter, but couldn't find it anywhere. Was that you, @bernhard?

I think what I meant to say was that the hash (#prodDescription) is never sent to the server. ProcessWore doesn't know about it. Any redirects that are dependent on the presence or absence of a hash need to be done in JavaScript on the client.

I'm pretty sure those anchor hashes never reach the server and are evaluated by the browser only.

What are you using ProcessWire for in this scenario? Will you have other internal content managed in ProcessWire or will you just be using it to render the external content on the frontend? I've done the latter before (using PW only to import and display data) und wouldn't recommend doing it. Importing the data is just a lot of added complexity. A static site generator might be a better solution here.

There's two ways I've tried in the past that worked: 1. Use a regex for your allowed url segments so it won't match "sitemap.xml" 2. Trigger a 404 manually from your homepage template file if the first input segment is "sitemap.xml"

The code looks right to me. The fact that you're seeing a chart at all means there's probably something off in the way your options are structured. The panel itself only sets the defaults so overriding them like you're doing it should work. I'm afraid I won't be of much help here since debugging Chart.js config is a bit out of scope of this module ?