Leaderboard

ProcessWire 3.0.196 contains 10 minor issue fixes, but the biggest additions this week are 6 pull requests submitted from @bernhard. This most notable PR is an upgrade to AdminThemeUikit that enables greater customization of the theme's markup. If you recall, Bernhard also provided a PR last year that enables customization of the admin theme's CSS/LESS, so now he's now completed the circle and provided us with a direction for customizing the markup as well. This newest addition lets you provide your own custom render files for different parts of the admin theme by placing them in /site/templates/AdminThemeUikit/. Third party modules can also define custom render files. Furthermore, this addition adds a new hook that enables you (or your modules) to hook into and modify just about any part of the admin theme rendering. Rather than going into all the details and repeating all of the instructions here, see the new AdminThemeUikit README file "Customizing Markup" section which describes all of the different things you can modify and how to do so. You can also find all of the render files in the core AdminThemeUikit directory — any .php files beginning with an underscore are custom render files that can be overridden. While not as broad in scope, there were other useful PRs added this week as well, so be sure to see the dev branch commit log if you are interested in seeing what else was added. Thanks for reading and have a great weekend.

@netcarver Have you tried using boot.php? In site/config.php $config->statusFiles = array( 'boot' => 'boot.php', 'init' => 'init.php', 'ready' => 'ready.php', 'finished' => 'finished.php' ); and in boot.php <?php namespace ProcessWire; wire('classLoader')->addNamespace('Wireframe\Blocks', paths('templates') . 'blocks/'); wire('classLoader')->addNamespace('Wireframe\Traits', paths('templates') . 'traits/'); I don't remember if I used traits in pages classes or in some other parts of the code, but you can try.

This looks awesome - thanks @bernhard and @ryan

@Zeka Thank you, I will give that a try as well. Updated to add: Yes! Using boot.php works nicely, I can now stick with PWs own autoload mechanism, thank you for the suggestion.

https://github.com/baumrock/RockSSE-demo Would be great if many of you could test this on your setups and let me know if it works as expected! In production I have a long running task like trashing lots of pages. The script will finish when all pages have been trashed.

Hello, I'm starting to play catch-up with some of the recently (and not-so-recently) added features to PW. In particular, I'd like to ask about more complex uses of Page Classes. I have a site where the end users are actual PW Users with first and last name fields. I also have several other templates in the system that have the first and last name fields but they are not actually Users of the system, rather they are entities like Contacts or other personages that can be also be named. I thought I'd enable page classes and add a simple getName() method to the UserPage class to allow their name fields to be nicely concatenated. In itself, no problem, as long as I remember to extend from User. So here's exhibit A: UserPage.php... <?php namespace ProcessWire; class UserPage extends User { function getName() { return trim($this->first_name . ' ' . $this->last_name); } } This works fine, I can call getName() on my users, nice. Now, my other nameable entities need this function too. I can extend from UserPage to inherit the getName() function, which works well and is straightforward... <?php namespace ProcessWire; class ContactPage extends UserPage { } So I can now use $contact->getName() as well as $user->getName(). But, my contacts aren't really system users, so I'd prefer not to inherit from UserPage at all, but either inherit from some intermediate class representing some form of NameableEntity or else use traits to compose the functionality into the individual page classes which need it. However, I'm hitting snags with both approaches and would appreciate some feedback. Attempt at Traits So I add the following as site/classes/NameHandlingTrait.php... <?php namespace ProcessWire; trait NameHandlingTrait { public function getName() { return trim($this->first_name . ' ' . $this->last_name); } } And switch my ContactPage.php over to using it... <?php namespace ProcessWire; class ContactPage extends Page { use NameHandlingTrait; } And that works. I can access $contact->getName(); (I actually did it by setting up the wire autoloader in ready.php to look for a specific namespace in a traits/ subdirectory - but I'll skip showing that here, it did work for my page classes that extend from Page.) However, when I try switching UserPage.php over to the same trait code to keep it DRY... <?php namespace ProcessWire; class UserPage extends User { use NameHandlingTrait; } I immediately hit the following error: "Fatal Error: Trait 'NameHandlingTrait' not found (line 5 of /site/classes/UserPage.php)" either when visiting the site (front end or admin) or by bootstrapping from the CLI. I can overcome this by manually requiring/including the trait file at the start of UserPage.php - but I'd much rather autoload it if at all possible. No matter how early I try to declare the extension of the class loader to attempt to autoload the trait, it isn't soon enough and I always hit the fatal error shown above. Can anyone shed any light on this? How do you go about using the PageClasses, especially UserPage, when the structure might need to take more of a composition-rather-than-inheritance form? Also, if you have any suggestions as to other places to get autoloading set up in PW prior to init.php or ready.php I'm all ears. I tried setting up the autoloader mappings in both places and they work for classes derived from Page but not for UserPage - so I suspect PW is creating a User instance pretty early on in its bootstrap, well before it is loading in extensions to the autoloader. I'll try adding a PSR-4 clause to composer.json and dumping the composer autoloader next - but I'd rather stick with native PW autoloading if possible. Intermediate Base Class The other approach I've tried is to use an intermediate base class to house the getName() function and inherit from that. This is doable for the classes derived from Pages but again, I hit the snag that the UserPage seems to have to extend User, and not my base class. @ryan What would you recommend here? Could UserPage extend something other than User?

Whoa! That is something I was wishing to have for years! Thank you! Recently I posted about donations and @bernhard's paypal link was on the list. But to my regret I have not donated to him myself. I wish I could fix my mistake, but things happened since then that do not allow me to pay online abroad anymore ? Please be so kind to help me out here and start donating to Bernhard. I know he will appreciate it. And I will join you as soon as I find a way to.

Hi @bernhard, yes, I have it already in my backlog ? Hope I will find a time for it soon.

Subscribe Podcast RSS feed and save as something you want. The additional example module ProcessPodcastSubscriptionsEpisodes create new pages per episode. Download/Install Github: https://github.com/neuerituale/ProcessPodcastSubscriptions Module directory: https://processwire.com/modules/process-podcast-subscriptions/ Composer: composer require nr/processpodcastsubscriptions

Hi I created new module for adding links to quickly edit a field directly from page edit. https://processwire.com/modules/admin-helper-links/ You probably already know existing module HelperFieldLinks created by @Soma which was my inspiration. I was using that module for a long time so thank you @Soma! The reasons for this new module are that HelperFieldLinks seems inactive and contains few bugs. I decided to try to fix them, but after a short time I realized a better (i think) and simpler solution and also got some new ideas how to improve. I used javascript instead of PHP and modified a code which is already in PW source code to show field names when you hover the inputfield's expand arrow (in debug mode). I also moved the cog icon next to the expand icons which doen't break the layout so much. What is missing is the field info panel with it's props, never used it, but it can be done too. The template edit links needs to be added too. If you got some ideas how to improve, tell me.

Well, yes and no. Two migration modules already exist in ProcessWire, but neither suited my needs: “Migrations” by @LostKobrakai seems effective but quite onerous to use and has been deprecated in favour of “RockMigrations” RockMigrations by @bernhard is simpler and has a nice declarative method: migrate(). However, it is ideally suited to “headless” development, where the API is used in preference to the Admin UI. This is great for professional PW developers, but for occasional developers like me, it is much easier to use the UI rather than just the API. In addition there @adrian's ProcessMigrator which is designed for migrating page trees. Concept I wanted something to achieve the following: To allow development to take place (in a separate environment on a copy of the live database, or on a test database with the same structure) using the Admin UI. When finished, to permit a declarative approach to defining the migration and implementing it (again in the UI). To allow testing of the migration in a test environment on a copy of the live database. To allow roll-back of a migration if installation causes problems (ideally while testing rather than after implementation!). To provide a record of changes applied. Although not originally intended, the module I developed also allows the selective reversion of parts of the database by exporting migration data from a backup copy. Also, if changes are made directly on the live system (presumably simple, low-risk mods – although not best practice), it allows reverse migration to the development system in a similar fashion. I should emphasise that what I have built is more of a 'proof of concept' than a fully-fledged module. The code is pretty hacky and uses some stuff outside of the module itself. Lots of validation is missing. However, I have used it successfully in a number of small tests and a medium-sized live migration. If there is sufficient interest, I will tidy the code and make it available, but it would still need input from better coders and PW-savants than me to make it into something more widely usable. EDIT: Please note that the module has moved on a bit from this original post - the design has changed somewhat to make it more robust and flexible and additional features have been added. Please see the help file for full details. I still consider it to be at alpha stage, however, so use with care - test before making migrations and always take backups first. Design The module has the following principal components: A PW module “ProcessMigrateData”, bundled with a bootstrap migration in the same ProcessMigrateData folder, to be placed in the site/modules folder; A Page Class “MigrationPage” to be placed in the site/classes folder; Php files migrationActions.php and migrationControl.php to be placed in the site/templates/RuntimeMarkup folder (and migrationActions.js to be placed in site/templates/RuntimeMarkup/scripts). There are also a methods which need to be put in class DefaultPage and a functions in the init.php file. The module requires the FieldtypeRuntimeMarkup module. Migration definitions are held in .json files in the ProcessMigrateData/migrations/{migration name} folder (I might move this). This folder contains up to 2 sub-folders - “new” and “old” which each contain a file called a migration.json file, which defines the scope of the migration in terms of fields, templates and pages, and also one or more of fields.json, templates.json, pages.json and remove.json. The first 3 of these files contain the field, template and file definitions within the migration scope and the remove.json file simply lists fields, templates and pages to be removed. These migration files are mirrored by pages of template “Migration” under a parent /migrations/ of template “Migrations”. The mirroring happens in two ways: If a new migration is created in the module (from the Setup -> DB Migration menu), then initially no json files exist. The json files are created, after the scope of the migration is defined on the page, by running “Export Data” from the eponymous button. If json files exist, but there is no matching migration page, then the latter is created by the module on accessing the DB Migration admin page. In this case, we are in the “target” database so there is no “Export Data” button, but instead “Install” and/or “Uninstall” buttons. Migrations therefore either view the current environment as a “source” (type 1) or a “target” (type 2). Installation The module creates templates called Migration and Migrations and a page below the root named ‘migrations’. Open the admin page “Setup -> DB Migration” to create a migration. One (“bootstrap” is already installed) and cannot be modified. The pic below illustrates the DB Migrations page in the source environment. The status of a migration (as a source page) can be ‘pending’ or ‘exported’. ‘Pending’ means either that the migration data have not yet been exported or that the current export files differ from the source database. On opening this page in the target environment, the individual Migration pages (type 2) are created from the definitions in their respective /new/migration.json file. The pic below illustrates the DB Migrations page in the target environment. In a target environment, a migration status can usually be ‘indeterminate’, ‘installed’ or ‘uninstalled’. ‘Indeterminate’ means either that the migration has not yet been installed (so no ‘old’ files containing the uninstall definition exist yet) or that the current state matches neither the ‘new’ or the ‘old’ state. ‘Installed’ means that the current state matches the ‘new’ definition and ‘uninstalled’ means that it matches the ‘old’ definition (i.e. it has been actively uninstalled rather than not yet installed). When carrying out development work, you keep a note of what fields, templates and pages you have added, changed or removed. The module does not track this – it is a declarative approach, not a macro recorder. Also, it does not handle other components such as Hanna codes and Formbuilder forms. These come equipped with their own export/import functions. You can update a migration page as you go along, rather than keep a separate note of changed components. The migration page also allows you to document the migration and add any number of “snippets”. These snippets do not do anything, but can be a convenient place to store (for example) Hanna code exports for pasting into the target environment and help to make the page a comprehensive record of the migration. See example below: Note that migration pages just define the scope of the migration. It is entirely feasible for other parts of the dev database to be changed which are outside this scope and which will therefore not be migrated. After sync'ing code files to the target environment, the new migration will be listed on the setup page. On the migration page, in the target environment, there are “preview” buttons to see what changes will be implemented. The migration can then be 'installed'. See example of the migration page in ‘installation’ mode below: That's the gist of it, but inevitably there are complications. Happy to discuss and share further if there is interest in this.

I don't remember the last time I laughed so hard ?.

Great. I forgot (or maybe never knew?) that boot.php existed!

https://github.com/kreativan/FieldtypeFolderOptions Maybe this custom field type can help or give u an idea, no multiselect support. Define the folder, and field will let u select files from it... then $files->include("my_folder/{$page->my_field_name}.php");

Hey @Richard Jedlička thx for the really helpful module ? Would it be possible to add icons to fields that have no label? Eg a checkbox. Ideally the icon would appear in the top right corner:

Thanks @kongondo - in hindsight I should have resurrected the previous post.

v0.1.4 is now on GitHub. As well as bug fixes, this includes a 'hook suppression' option (not yet documented in the help) to enable superuser use without the module operating fully (for performance reasons) - i.e. if you need superuser but are not using the module.

Have you tried adding the namespace to the autoloader inside site/init.php instead of site/ready.php? wire('classLoader')->addNamespace('ProcessWire', wire('config')->paths->templates . "traits/"); If you have usePageClasses set to true in the config.php and are using the /site/classes/ folder then I would think this wouldn't even be necessary since that should already be included in the places for the autoloader to look. I haven't come across the need for traits yet, although I keep forgetting that they exist in php now. When I think of composition I usually think of moving certain functionality out into a separate class that would then be instantiated somewhere inside the other class. You can create classes that don't extend Page (perhaps that that extend Wire or WireData if you want easy API access) and then use those in your Page derived class. Your example is probably intentionally oversimplified, but sometimes I find that sometimes a bit of duplicated functionality is really just incidental and doesn't actually justify creating a new layer of inheritance or a separate class at all, especially as you might later discover that the two functions actually serve slightly different purposes and at that point are tied together and difficult to pull apart. You could also use a PW hook to add this function to both classes, although it wouldn't be as elegant.

It's not only JavaScript, sometimes it's the design of our backend...

I was about to create a similar topic, but why do it if this one already exists))) Not so long ago I started donating to some ProcessWire modules' authors. And each 1st of the month I am looking at my Patreon receipt in my email with a kind of a pride. I think that this thing is my little contribution to the community I love so much and which gave so much to me for free. I do know that Ryan likes to receive his support with pro modules payment. But many modules really shouldn't be paid/pro as they are so essential to many (and so fun to build). But their authors still would be glad to receive some money to sustain their enthusiasm supporting them and creating new features. I am sure the appreciation itself is equally important, but what is an easier way to show it than ???))) The other thing is that I sometimes notice some great improvements that seem to happen to modules as soon as some support comes in. I am writing this to encourage everyone to support the PW ecosystem by donating to module authors. I will list the modules I know that clearly asked for donations. I am sure that is not an extensive list. But at least something to start with. Tracy Debugger Mystique and other modules by ukyo (please don't miss this one @Jonathan Lahijani))) Rock Migrations and a bunch of rock stuff by bernhard All the great stuff from teppo I really like the Patreon/OpenCollective/Github donations, but only 1 of 3 listed used them. Sooooo..... Start throwing money at these fine gentlemen)) Support yourself by making you favorite modules not go away. I wish we could bring back @tpr to support his AOS and wire shell by @marcus and @justb3a. Would they keep supporting their thing is they had some donations coming in? Who knows. And please feel free to list you other module authors that you know asked for support below. Edit 2022-10-27: added teppo's link

Hello Seba, yes, this is possible. I have connected the login to our domain controller via LDAP and the control of the authorisations runs via corresponding groups. (Customized Version of this Module: https://github.com/conclurer/LdapSignIn ) in general, its just a normal website with access protection ?

Some of you might of used my previous U2F module for their two factor needs. Well I was recently informed that Chrome is dropping plain U2F support in favour of WebAuthn. So after a full day of debugging some cryptic errors I am proud to announce a WebAuthn module. This has some major improvements. For example you can now use on-device credentials like Windows Hello/Apple Touch ID. This means that even people without a Yubikey can benefit from modern two factor authentication. It also has much better cross platform support. For example NFC will now work on an iPhone. I do not recall the original U2F stuff working well on iPhones so yay? The is still the original issue that ProcessWire imposes with its Tfa class, That being it is a setup once and never edit again system so you can only add your on-device credentials for a single device because once saved you cant then edit your credentials on a second device. You also lack the options to revoke a single credential or add a new one. You have to wipe out the config and re-add your keys again. It sucks but realisticly if you need more than 3x credentials your almost defeating the point of Tfa I feel the need to also point out that this does not replace passwords. That is something WebAuthn can do a fully passwordless setup. But I think implementing that inside ProcessWire would be a huge challenge. It is frankly a form of magic that I was able to make WebAuthn work within the confides of ProcessWire's Tfa class. Github: https://github.com/adamxp12/TfaWebAuthn ProcessWire Modules: https://processwire.com/modules/tfa-web-authn/ I hope this module helps you guys out securing your ProcessWire websites If you have any issues just reply and I will do my best to help you out

Update: Here's a little snippet how to use dynamic navigation items using the NavJSON feature: // in getModuleInfo() 'useNavJSON' => true, // enable JSON nav feature 'nav' => [ [ 'url' => 'contacts', 'label' => 'Contacts', 'icon' => 'users', ],[ 'url' => 'mailings', 'label' => 'Mailings', 'icon' => 'folder-open-o', 'navJSON' => 'mailings-nav', // this will call executeMailingsNav() to get items ],[ 'url' => 'groups', 'label' => 'Groups', 'icon' => 'users', ], ] // and in the module /** * JSON nav for mailings */ public function executeMailingsNav() { $options['add'] = null; // no link to add pages $options['edit'] = $this->mailer()->url."new/?channel={name}"; $options['itemLabel'] = 'label'; // use the label property as item label (default is name) $options['items'] = []; foreach($this->mailer()->channels as $channel) { $data = $this->wire(new WireData()); /** @var WireData $data */ $data->name = $channel->short; $data->label = "New ".$channel->name; $data->icon = "plus-circle"; $options['items'][] = $data; } return parent::___executeNavJSON($options); }

I hate hate hate hate (repeat however many times you would like) to say this, but WooCommerce is my weapon of choice for eCommerce. For the level of my client base, they are on the understanding that if I say I am not doing that with this software and you would need something more highend and secure, then they are ok with the functionality. That will be the only time you will ever hear me talk WordPress on here (until the new Padloper comes along). But, I did check out the module by @Gadgetto that @bernhard was talking about, and it is impressive. Yes you can plug everything into the frontend yourself with Snipcart, but the backend integration is lovely. If you are worried about the fees, then in my experience, you have a product that has too many competitors and there will always be somebody out there undercutting you. Just roll something out with a slightly higher price otherwise, test the water and adapt from there.