Kiwi Chris

I just read this after I got home from Saturday morning netball with my 11 year old daughter. Sounds like ProcessWire kids are a thing. ?

Have you seen this: https://github.com/momentum81/php-remove-unused-css It's incomplete, hasn't been updated in a while, and won't remove all unused CSS but might still achieve some reduction in CSS size.

There's a Bootstrap NPM starter project that includes PurgeCSS to strip out unused css here: https://github.com/twbs/bootstrap-npm-starter Also, there's a good tutorial on how to strip CSS with any CSS framework using UnCSS here: https://www.keycdn.com/blog/remove-unused-css There's another tutorial that should work with any CSS framework here: https://medium.com/dwarves-foundation/remove-unused-css-styles-from-bootstrap-using-purgecss-88395a2c5772

I recently inherited a site built in Wix because the person who built it disappeared, and the site owners weren't provided with a login. Reverse engineering it proved a nightmare, including having to use Chrome Developer tools to individually download images since the way Wix served up the pages, you couldn't just save them and capture all the content. I probably could have built them a site from scratch for less, but they really wanted to keep the design, and they didn't have backup copies of their images. I've rebuilt it as a static site at this stage just using SSI for headers and footers, with Bootstrap 5.x to provide layout, and I've been able to discard 97% of the code on most pages and have something that looks pretty much the same. Pages that were up around 1MB of HTML from Wix came down to about 15KB with Bootstrap, with almost identical appearance. I'm not a great designer myself, but Bootstrap makes doing pretty much any kind of layout fairly easy, and it's easy enough to strip out unused CSS to slim it down once you're finished. Customising Boostrap via scss files is pretty easy, particularly if you use something like Visual Studio Code which has extensions that will automatically compile scss on save. There are other CSS frameworks like Bootstrap such as UIKit that ProcessWire itself uses as well, and using any of these is a great help if you want to ease into the intricacies of CSS with a framework with components that just work, but that you can customise as you need and as your skill develops. These front-end frameworks are much like ProcessWire itself, in that they don't set out to tell you how to build sites, but give you a useful set of components that you can put together like Lego bricks or perhaps Meccano is a better analogy, as you actually have to bolt things together by writing some code, whereas website builders hide all of that away from you (and create horrible code), but you do get parts that are already made to work together.

I'm not sure if it will help with your requirements, but there's a module I've used in the past that may help. Although Mike Rockett is no longer maintaining the module, I think it still works, and may help: I used it to map URLs of the kind you're talking about from a site I built before I discovered ProcessWire so that they'd still work in ProcessWire https://processwire.com/modules/process-jumplinks/

My approach to this is non-web based. I write my copy in LibreOffice, and then copy and paste. Unlike Word which has a habit of generating horrible HTML code, LibreOffice generates clean HTML when copied and pasted, as long as you stick to using formatting that exists in HTML, ie headings 1-6, lists, and paragraphs. Since LibreOffice is free, and uses .odt file format by default whereas Word uses .docx it's possible to have both, and use LibreOffice Writer for web content. An .odt file is just a zip file containing XML and any visual assets (as is a .docx file) (You can test by changing the extension to .zip and then open the file. I've used this technique to get jpg files for a website when someone's emailed me a Word document.), so in theory, it should be possible to write an import module to upload an .odt file, read its contents, and save to a rich text field in ProcessWire. I'm happy copying and pasting from LibreOffice Writer, but an automated import module for people who write a lot of rich text and need to get it into ProcessWire might have merit for others.

Thanks. I'll look into this and have a go at replacing it. In my usage scenario this isn't really an issue. I have some very small non-profits who don't want to pay much but have images and documents they want to host, and storing them locally on my VPS isn't really cost effective if they have a lot. If they're paying a low price and don't have to worry about storage, I don't think they're going to object if there's a temporary outage. I really appreciate you making this available. It's something I'd been thinking about for a while, and having a working module to modify will be so much easier than starting from scratch. I'd imagine my usage scenario may be useful to others too, so I'll be sure to update any modifications I make.

This is super cool. I'd been thinking about ways to use Cloudflare images for a while. This might be a bit of an issue for how I'd considered using it. One of the things that had attracted me to Cloudflare Images is the low price of storage and traffic, but if ProcessWire still needs a local copy, that's maybe not quite as useful for the scenario I'd had in mind, although it would certainly help with traffic. Not sure whether a way around it would be to just store a thumbnail locally once full res file has been stored in Cloudflare.

https://www.bmt.net.nz/ This project began as a project to convert a 20 year old Microsoft Access membership and musical production database to a cloud based system. I completed that over a year ago, but then the organisation realised they wanted a new website, and much of the data was already in the system I'd built for them to manage their membership and shows. Building the public frontend required adding a few more fields on the backend, and reorganising some of the data, but most of it was there already. I've used Lister Pro extensively in this project and it's also my first project using RockMigrations. RockMigrations has proved really helpful in adding new fields, testing, then applying to the live site, and although there's a bit of work to go, the aim is to use RockMigrations to enable the whole setup to be installed as a module on top of a clean ProcessWire installation, as I suspect the setup should be useful for other groups, either with or without customisation of the frontend. Other modules I used were Formbuilder Pro for a membership form, Import Pages from CSV (to import exported data from Access database), Wiremail Gmail, to enable emailing to gmail addresses. I also wrote a custom dashboard module and updater. I wrote a modified version of the ListerPro action Send Email to enable sending HTML formatted emails.

Has anyone else managed to get ProcessWire working on Azure App service with PHP 8.x? App Service runs a Docker container, but the container image has been changed from Apache to Nginx between PHP 7.x and 8.x so of course .htaccess files don't work. I've followed instructions here: https://www.schakko.de/2021/09/08/deploying-php-8-0-applications-with-azure-app-service/ and tried to convert the ProcessWire .htaccess file here: https://winginx.com/en/htaccess but the best I've been able to get was the home page loading, but all other pages just give a 404 error. My client is a non-profit and want to use Azure because they get free hosting under Microsoft's non-profit programme, so before I give up, has anyone else managed to get this working?

I didn't have anything in the migrate file to install the module, but I did have code to create a lot of fields and templates and create some pages which all got created. I wanted these to be under the control of migrations, but assumed (incorrectly) migrations would only run on installed modules, ie once the module is installed I do want the migrations file watched and run if there are any changes, but if the module isn't yet installed it doesn't make sense to run its migrations. An easy way to get it to work the way I want is to do a conditional check at the start of the migrations file to see if the module is installed or not, and only run the actual migration code to create fields and templates if the module is installed. That way I won't get a bunch of fields and templates installed for an inactive module.

I'm not sure whether it's intentional or not, but I started experimenting with deploying a site setup to a clean, blank copy of ProcessWire with RockMigrations I dumped a copy of RockMigrations and a custom module with a migration file in the format MyModule/MyModule.migrate.php I installed RockMigrations via the admin UI, and was wondering why it was taking so long. Afterwards I checked, and found it had gone ahead and installed all the modules, fields, files, and created pages in the custom module's migrate file, even though the module itself was not yet installed. I'm not sure whether that's intended behaviour? If it is, I need to make sure I don't upload a module with a migrate file unless I want the migration to run as soon as I upload it. My assumption was that RockMigrations would start watching and running migrations in a module's directory once the module is installed, but possibly I assumed wrong. Apart from being surprised that the module's migration file ran before the module was installed, it was very nice to see a whole app with multiple fields, templates, modules, and pages constructed before my eyes, and it's way more modular than exporting site profiles, since I can build a base functionality in one migration file and then add components in others.

Something like this could work. There are two possible scenarios I can think of. A site profile migration or a module migration. In either case, it's still necessary to be able to manually specify the order of the fields and templates because of possible dependency issues, but it should be possible to generate the field and template definitions (for those who want to, rather than coding them).

That's a significant issue, and I tend to think it's better to have migrations generated manually rather than fully automated, but I think possibly more automation is possible. Here's my first ever migrations file, that works nicely for me. //Modules $rm->installModule( "FieldtypeLeafletMapMarker", "https://github.com/madebymats/FieldtypeLeafletMapMarker/archive/PW3.zip" ); //Fields include __DIR__ . '/fields/fields.php'; //Templates include __DIR__ . '/templates/Discipline.php'; include __DIR__ . '/templates/Member.php'; include __DIR__ . '/templates/Show.php'; include __DIR__ . '/templates/ProductionRole.php'; //Web Templates //include __DIR__ . '/templates/contact.php'; include __DIR__ . '/templates/ProductionRole.php'; include __DIR__ . '/templates/location.php'; include __DIR__ . '/templates/pastShows.php'; $rm->createPage('Website', 'website', 'basic-page', 'home'); $website = $this->wire->pages->get('name=website'); $rm->createPage('Past Shows', 'past-shows', 'pastShows', $website); $rm->createPage('About Us', 'about-us', 'basic-page', $website); $rm->createPage('Contact', 'contact', 'location', $website); In each of those template definitions, I have: $rm->createTemplate('...'); $rm->setTemplateData( ... ); I did combine the field definitions into one file, but I could have done them individually. I still have full manual control over the order of migrations, but my migrations file itself is pretty small, and each template definition file is self-contained, and I think it makes the code cleaner. It's not as efficient maybe as running $rm->migrate with all the templates in one big array but it works, and I can control the order. It made me think, if I'm using this sort of structure, then the getCode method of RockMigrations, instead of being used just to display the code on screen, could build the definition files for me. A way to have some manual control if definitions are combined in a file would be to have some sort of Migrations build file for a module, which specifies the fields and templates in the order that they need to be processed. In my module migrations file, I've specified the order manually, but I've kept the definitions separate. The way I'm using this is in association with modules, so I wonder whether the way to do it is to hook into the module UI, check whether the module has a migrations build file, and if it does, offer a button to generate the module migration based on the specification in the build file?

This is perfect. I've thought of an enhancement to RockMigrations that would be useful because I'm lazy. In the showCopyCode method, instead of copying and pasting, an additional option would be an 'export' button, and a path field. I'd still need to write a migration file, as the order of field and template migrations is important, but if I simply list the fields and templates as includes in order, then it would make the migration file more concise, and I could still trigger a migration by updating version details of file, but without having to keep copying and pasting into a file. eg, if I want the definition for myTextField to be associated with ProcessHelloWorldModule, then I could set a path site/modules/ProcessHelloWorldModule/fields/ and dump the definition there by button click. I've been having a play and here's a mockup although it doesn't do anything yet. I'm not sure whether it actually needs its own save button, or whether to hook into saving the field and save the RockMigrations code to the path specified. I've never worked with modifying field/template editing before, so I'm not sure how to persist the save path. Of course I can do this manually, by copying and pasting each field and template definition into its own file but I think this might be a time saver for people who like to use the UI, but also want to use migrations.

A quick question before I go ahead and set up migrations files: I like using the ProcessWire UI to edit my field and template properties, and RockMigrations gives me all the code to copy and paste into a migrations file, so this is nice and easy, but I want to make sure on my development instance that I don't accidentally overwrite field or template definitions by triggering a migration when I've yet to copy and paste updates from those fields into the migrations file. I do want the migrations to run automatically on the deployed site I think though, as the migrations file(s) will only get updated on the deployed site when they're ready to run. I think I'd prefer to include the migrations in page classes, as that keeps all the definitions of an object in one place and nice and modular, just I don't want to accidentally trigger these on my local development environment before I have all the fields and templates modified with any changes I've done via the UI. What's the best way to handle this scenario?

ProcessWire does and doesn't do this. You initially have to edit your HTML templates to define the structure of pages on your website, but after this, all the editing of the content can be done either on the front-end or back-end without having to edit HTML directly. Most other CMSs do the same, just some come with a lot of predefined themes to get you up and going where someone else has created the HTML templates. Both the strength and weakness of ProcessWire is that it doesn't come with a lot of predefined themes. That's because ProcessWire doesn't try to decide for you how your site should be structured, and third-party themes for other CMSs typically depend on the CMS having a specific structure to data. That might seem like a good idea, until the moment you try to do something that doesn't fit the assumptions the CMS has made about how data should be structured, then it turns into a nightmare to try to make it do something different. ProcessWire makes virtually no assumptions about your data, which is why it requires some knowledge of HTML to make templates to start with, but it's much easier to change than other CMSs, and once you've got your HTML templates, it's very easy to edit content without needing to know anything about HTML, and is arguably more intuitive for editing content than some other CMSs that involve some clunky and inconsistent plugins and add-ons to do anything beyond the basics. I guess you could use the analogy, ProcessWire is a box of Lego bricks. You've got to do some construction, limited only by your imagination. Other CMSs are like a ready made toy. If it's the toy you want, then they're quicker and easier, but if you got a toy car, and really wanted a helicopter, then trying to change it is going to be hard. With ProcessWire it can be a car or a helicopter, but you've got to build it.

I think this could work both ways. One of the things I really like is that it's possible to use the admin UI to design your fields and pages, but RockMigrations then gives you the code generated to copy and paste into your migrations file. If you start prototyping using the UI, and intended to add it to a migration but forgot to, having an indication that a field or template isn't included in a migration is just as useful as indicating that it is. This would be particularly useful when adding RockMigrations to an existing site, as it makes it easier to see quickly what has been see up to be managed by migrations and what hasn't been.

Something like? $database->exec('ALTER TABLE pages AUTO_INCREMENT = 1');

This looks great. I'd been considering building something similar myself as I have a need for it. I do have a need for it to integrate with an existing site, but from the looks of the latest Rock Migrations, there's an easy way to get the configuration of fields and templates to paste them into a migrations file, and that's something else I've been meaning to have a play with, so I might set up a local version of this profile, install Rock Migrations, and see if I can build a migration that allows me to apply this to an existing site.

@kixe Your fork of the module doesn't allow issue reports on Github, so I'll mention it here. There is a hook into AdminRestrictBranch module if present to automatically restrict the page tree to the root of the domain in multisite mode. if ($this->wire('modules')->isInstalled('AdminRestrictBranch')) { if (method_exists('AdminRestrictBranch', '___getBranchRootParentId')) { $this->addHookAfter('AdminRestrictBranch::getBranchRootParentId', function ($e) { $e->return = $this->rootPageID; }); } else $this->warning('AdminRestrictBranch::getBranchRootParentId() is not hookable'); } Where this has an issue is that if a user is only supposed to have access to page tree belonging to domain A as defined in AdminRestrictBranch, and then logs in to domain B, the branch restriction defined in their user profile or role is overridden by the hook in multisite. This means if any user knows other domains under the same installation of ProcessWire using Multisite, they can log in and access the page tree of those domains, even if AdminRestrictBranch is configured to otherwise prevent them from accessing them. A quick fix is to comment out the hook code. A better fix would be to check whether a user or role already has branch restrictions in place defined by AdminRestrictBranch, and if so, defer to those restrictions, but if not, provide default behaviour as exists of restricting to the root of the domain.

Oops! Sorry @adrian I just realised I got my module mentions back to front. I'm using your 'official' version of AdminRestrictBranch, and the Multisite version by @kixe There does seem to be some interaction going on between them that's causing unexpected results. It's not necessarily a fault with AdminRestrictBranch, it looks like an issue with Multisite module as it hooks AdminRestrictBranch::getBranchRootParentId , but it's still worth mentioning here in case someone else runs into the same problem, so that they're aware of potential issues using the two modules together. I found an easy fix was just to comment out the hook code in the Multisite Module.

I'm not sure whether it's an issue with the current version of the core (3.0.203), or some other interaction, but currently I'm getting a weird issue. All users, regardless of what branch they're restricted to, are being restricted to the same branch. ie branch restriction is happening, but regardless of what branch is specified, they all get the same branch. [edit] I seem to have found the source of the problem. It is an interaction between Multisite module and @kixe version ofAdminRestrictBranch. What seems to be happening, is that when a user logs in, they will get the full page tree of whatever domain they have logged in under, regardless of how AdminRestrictBranch is configured. In some ways that's desirable: log in under a domain, and only get that domain's page tree, but it's also a security issue, as if a user knows another domain in the same multisite setup, and logs in with the login that's supposedly restricted to the page tree for another domain, they can see the page tree of the other domain.

Thanks for sharing an interesting use of comments. I think I would find the hook code useful as I have FormBuilder and I can think of scenarios where I could use this. As a matter of interest, if you want to aggregate meta data from all comments and get an average rating for a given piece of meta data, what's the most efficient way to achieve this?

The ProFields Combo field and Table fields create SQL tables behind the scenes, but they're still fieldtypes, so are expected to be added to a ProcessWire template and are linked to the page tree. Sometimes that's not necessary or desirable. With regards to creating custom tables, I'm quite happy writing SQL statements for this, or using the generated CREATE TABLE statements with a database export from mySQL, or for that matter even other dialects of SQL, with a bit of editing if necessary. It's not hard to write a CREATE TABLE statement initially, then an ALTER TABLE statement if subsequent changes are needed. I think this would play nice with your RockMigrations module to generate SQL schema changes in code, and I don't want to turn ProcessWire into mySQLAdmin or Adminer which is installed with Tracy Debugger, but it would be nice to have an end user friendly UI to view and edit custom SQL tables in the ProcessWire admin. You have made me thing of something I hadn't considered, about how to migrate SQL listers and editing forms, if the InputField settings or fields to display in a lister change, but if they're accessible via the API, it should be possible to manage migrations in a similar way to ProcessWire native fields and templates.