Leaderboard

With the style panel, you can customise the look of your website without writing CSS code. If you prefer to work with code, that's fine too. Just deactivate the panel and load your CSS as you are used to. PAGEGRID will stay out of your way. You can also combine the approaches or bring your favorite CSS framework. The style panel is a tool for developers, designers or "advanced users", not necessarily for your client (you can give them access, but I wouldn't recommend it ?). The great thing about using the style panel (and PAGEGRID) is that you don't need a build tool or deticated development environment. If you use the block modules, a simple database backup can be enough to restore all changes. Since the templates and fields are all created by the modules, migrations are no longer an issue. This can be a quick and easy way to create a custom website. Which CSS frameworks are supported by PAGEGRID? The style panel generates modern vanilla CSS. The block modules use vanilla CSS and vanilla JS. With your own custom blocks you can easily add a framework if you want. If there are enough requests in the PW community for a certain framework, I might build some blocks for it. ?

Hey @gebeer it's really the same as with hooks. In the beginning placing all hooks in ready.php is the easiest. Later or on more complex projects it's better to move those hooks into their dedicated page classes. The concept is simple: Everything that belongs logically to FooPage goes into FooPage::migrate() Everything that belongs logically to BarPage goes into BarPage::migrate() Everything that belongs to the project and nowhere else or that needs to take care of circular reference issues goes into Site.module.php Site.module.php is a concept that I'm using for several years now and it is great. It's an autoload module that holds all the project specific stuff that belongs nowhere else. Similar to _functions.php but with all the benefits of OOP. Years ago I've created modules named after the project, like for the Foo project it was Foo.module.php and for the Bar project it was Bar.module.php; But I much more prefer Site.module.php which is why RockMigrations offers you to create this module for you (if you want). Nowadays whenever I'm working on any of my projects I instantly now where to look for: Site.module.php - that saves brain power for more important tasks ? I've done a video about hooks and custom page classes and the same concept applies to migrations (the video starts at the interesting part): All you have to do is make your custom pageclass a MagicPage and add a migrate() method: <?php namespace ProcessWire; use RockMigrations\MagicPage; class BasicPagePage extends Page { use MagicPage; public function migrate() { $rm = $this->rockmigrations(); $rm->migrate(...); } } Then as soon as you save that file those migrations will be fired. And only those. ? There's a reason why these features are built into the module...

ProcessWire Dashboard Download You can find the latest release on Github. Documentation Check out the documentation to get started. This is where you'll find information about included panel types and configuration options. Custom Panels The goal was to make it simple to create custom panels. The easiest way to do that is to use the panel type template and have it render a file in your templates folder. This might be enough for 80% of all use cases. For anything more complex (FormBuilder submissions? Comments? Live chat?), you can add new panel types by creating modules that extend the DashboardPanel base class. Check out the documentation on custom panels or take a look at the HelloWorld panel to get started. I'm happy to merge any user-created modules into the main repo if they might be useful to more than a few people. Roadmap Panel types Google Analytics Draft At a glance / Page counter 404s Layout options Render multiple tabs per panel Chart panel load chart data from JS file (currently passed as PHP array)

Something I've wanted in ProcessWire for a long time is full version support for pages. It's one of those things I've been trying to build since ProcessWire 1.0, but never totally got there. Versioning text and number fields (and similar types) is straightforward. But field types in ProcessWire are plugin modules, making any type of data storage possible. That just doesn't mix well with being version friendly, particularly when getting into repeaters and other complex types. ProDrafts got close, but full version support was dropped from it before the first version was released. It had just become too much to manage, and I wanted it to focus just on doing drafts, and doing them as well as we could. ProDrafts supports repeaters too, though nested repeaters became too complex to officially support, so there are still some inherent limitations. I tried again to get full version support with a module called PageSnapshots developed a couple years ago, and spent weeks developing it. But by the time I got it fully working with all the core Fieldtypes (including repeaters), I wasn't happy with it. It was functional but had become too complex for comfort. So it was never released. This happens with about 1/2 of the code I write – it gets thrown out or rewritten. It's part of the process. What I learned from all this is that it's not practical for any single module to effectively support versions across all Fieldtypes in ProcessWire. Instead, the Fieldtypes themselves have to manage versions of their own data, at least in the more complicated cases (repeaters, ProFields and such). The storage systems behind Fieldtypes are sometimes unique to the type, and version management needs to stay internal [to the Fieldtype] in those cases. Repeaters are a good example, as they literally use other pages as storage, in addition to the field_* tables. For the above reasons, I've been working on a core interface for Fieldtypes to provide their own version support. Alongside that, I've been working on something that vaguely resembles the Snapshots module's API. But rather than trying to manage versions for page field data itself, it delegates to the Fieldtypes when appropriate. If a Fieldtype implements the version interface, it calls upon that Fieldtype to save, get, restore and delete versions of its own data. It breaks the complexity down into smaller chunks, to the point where it's no longer "complexity", and thus reasonable and manageable. It's a work in progress and I've not committed any of it to the core yet, but some of this is functional already. So far it's going more smoothly than past attempts due to the different approach. My hope is to have core version support so that modules like ProDrafts and others can eventually use that API to handle their versioning needs rather than trying to do it all themselves. I also hope this will enable us to effectively version the repeater types (including nested). I'm not there yet, but it's in sight. If it all works out as intended, the plan is to have a page versions API, as part of the $pages API. I'll follow up more as work continues. Thanks for reading and have a great weekend!

Oh thank you for this explanation. Much appreciated!

Note that the module only stores the current count and not all the timestamps of each visit. That means you can get "trending topics" in terms of most views from the very beginning but not trending topics in terms of most viewed in the last 2 days for example. But you could certainly achieve something like this by hooking into the pageViewTracked event like I did with RockHitCounter: https://github.com/baumrock/RockHitCounter/blob/1bfe2531810d2e9e18177d9975fd4d868fda96a4/RockHitCounter.module.php#L34

Thx. Fixed ?

@bernhard, That works, yes, but only if you update the $file = Paths::normalizeSeparators($step['file']); in the getTplPath() method as well, as you suggested earlier..

One approach might be to keep a log of a certain number of timestamps for the most recent hits on each page (dropping the oldest when adding a new one). Calculating the average difference between the timestamps would give a rate at which the page is being hit. It might also work to look at the age of the oldest timestamp, and if it's less than a certain age assume the page is receiving a lot of hits. You might find some useful techniques in the Page Hit Counter module.

Appreciate the detailed explanation @bernhard and @gebeer, I was unaware of some of the finer points. Looking forward to trying the module again in the future. A brief philosophical note among the technical discussion (the thread seems to have gone off track a bit ?) — RockMigrations is a great tool and people seem to be enjoying it. And not everybody has to agree with its way of doing things. We were merely expressing our views on what a good solution looks like. Choosing to use a particular tool is about preference and previous experience. It's about finding what works best for each of us, and that might change over time, or it might not. Neither is directed against you or a critique of your work. I have no doubt that the features I referred to as "a few things too many" are valuable in your workflow. That's the beauty about creating your own modules – you're free to tailor them to your needs and include whatever saves you time. My personal opinion is that these features shouldn't be part a migrations feature. You seem to disagree, and that's fine.

They way I've sort of done this is with New Relic, you install agents for php/apache/mysql in the server and does it's magic to monitor the relevant processes. And I say "sort of done this" is because I didn't really plan for anything, just wanted to test it out and got easily overwhelmed by all the features it has and concepts I don't really understand. I did manage to get alerts on spikes in memory and load, but that's about it and I'd say thats like 0.01% of what newrelic does, but kinda solved what I needed at that moment.

@ShadowByte You can add a sort order to your selector: template=news, limit=10, sort=-date

Ok. I finally followed my initial tutorial step by step based on a clean ProcessWire 3.0.229 with basic blank profile (output strategy Markup Regions) and PHP 8.2.4. Following the steps and copying the code one by one showed no warnings or errors at all. Of course i needed to adapt the events.php template for markup regions to see the output. However I found two possible traps one can step into. First trap is related to the installation process of the Latte composer package. If a default ProcessWire composer.json exists in the root of your installation, composer asks to use this composer.json file. If you answer Yes (default), this would install the Latte files in /root/vendor instead of /root/site/classes/vendor as I assume in my tutorial. This could explain the file not found error you mentioned. In order to install the Latte composer files inside /root/site/classes, one needs to answer NO to the composer question "Should I use the composer.json in the root?". Added a note in my initial post to avoid this trap. Second trap could be your template output strategy. My tutorial assumed you are using delayed output strategy, not markup regions or others. If you use markup regions, you won't see any Latte output in the events.php at all. So I decided to add an example for markup regions for the events.php template too. In your specific case, the error may be related to the fact that you already installed other Latte template implementations like RockFrontend, LatteTemplateEngine module or others, which may affect each other (e.g. namespaces, autoloaders). So I guess if you would start with a blank ProcessWire installation, my initial solution should work out of the box for you as well ?.

Thanks - that has taken care of things. I actually think there are lots of modules that get loaded via CLI scripts even though they aren't needed. I kinda think PW should have a module autoload option for this to make it easier / more obvious to the developer to disable via CLI unless needed.

I've been encountering frequent Error in hnsmtp::send : cannot connect to smtp-server! errors indicating a failure to connect to the SMTP server. I'm using Brevo, formerly known as SendinBlue, and this issue only started a few months ago. The errors seem to occur randomly, with varying frequency, ranging from ten times a day to once a week. I've reached out to Brevo for assistance, but they haven't identified any issues so far. Additionally, I recently conducted an external SMTP test on dnschecker.org, and it consistently succeeded each time (though this might be coincidental). The problem persists regardless of whether I test the connection locally or in a live environment. I'm wondering if there's a way to debug the SMTP connection to gather more information about the problem.

Has this been deprecated? Just tried this module on a site, trying to get watermarks on its opengraph images, and I'm getting this error: Compile Error: Array and string offset access syntax with curly braces is no longer supported (line 2385 of site/modules/PageImageManipulator/ImageManipulator.class.php) (My server is running PHP 8.0)

@julianmark - good luck with getting the FTP login details. I do think that's a little unfair of a statement to make given that you also state: :)

Hi Marc, I quit my job as developer. I really wanted to work in the outside air and with my hands again. I'm building garden sheds these days and I love it. Maybe someone wil take over some modules I made in the past.