Leaderboard

I've been continuing to work on the PageEditChildren module that I wrote about here last week. This week a "Clone" feature was added. You can click the Clone action and it'll create a copy of the page below the one you cloned, and then make it immediately editable before you even have to save. This Clone action is an example of an Inputfield header action, and it accompanies the Move, Pub/Unpub and Trash actions for each page in PageEditChildren. I thought this ability to add Inputfield actions seemed useful beyond just this module, so the ability has been added directly into ProcessWire's core Inputfields JS API. If you grab the current dev branch of ProcessWire, you can test it out if you'd like. You can paste these examples in your web browser's Javascript console. But in actual web development, you'd likely put these in a separate JS file that is added to your page editor with a hook. Open the page editor to any page, then open your Javascript console in your web browser, and then paste this in: Inputfields.addHeaderAction('title', { icon: 'fa-hand-stop-o', callback: function() { ProcessWire.alert('Hello World!'); } }); That should add a hand icon to your "Title" field header, and if you click it, it'll pop-up a dialog box that says "Hello World". Let's say you wanted it to show a different icon when you hover it, and also to show tooltip text via a title attribute. You can add the 'overIcon' to specify what icon to show on mouseover, and 'tooltip' to specify the tooltip text: Inputfields.addHeaderAction('title', { icon: 'fa-hand-stop-o', overIcon: 'fa-hand-peace-o', tooltip: 'Hello world', callback: function() { ProcessWire.alert('Hello World!'); } }); Above are examples of 'click' actions. We also support toggle or "on/off" actions: Inputfields.addHeaderAction('title', { onIcon: 'fa-toggle-on', onTooltip: 'Click to toggle off', onCallback: function() { ProcessWire.alert('You toggled on'); }, offIcon: 'fa-toggle-off', offTooltip: 'Click to toggle on', offCallback: function() { ProcessWire.alert('You toggled off'); } }); Toggle actions like this are primarily what is used by the PageEditChildren module to handle the Published vs Unpublished state, and Trash on/off state. Whereas "Clone" is an example of a Click action. Our callback functions in the examples above are very simple alerts, but of course you could make it do anything you want in those callbacks. Also added this week to the Inputfield JS API was an update to the Inputfields.label() function that now allows you to set the label for an Inputfield (previously it could only get the label). This is a bit of a contrived example, but since we were talking about header actions above, let's demonstrate the label() function within a header action. This example adds an action that lets you edit the Inputfield label: Inputfields.addHeaderAction('title', { icon: 'smile-o', callback: function($f) { ProcessWire.prompt('Enter new label', 'Label', function(val) { if(val) Inputfields.label($f, val); }); } }); By the way, there's a lot more to the Inputfields JS API, and it's all documented directly in ProcessWire's inputfields.js file. I'll be bumping the core dev version next week to hopefully accompany the first version of the PageEditChildren module. Thanks for reading and have a great weekend!

@TomPich I think the decision re the PW back-end is quite critical in terms of time estimation. Using it will save a lot of coding for an app like this. But a custom CRUD interface, if well-designed, might be easier to use. For my membership app, I went with a highly-constrained PW backend provided through modals (my "AdminInModal" module), in a front-end wrapper, which limits users to just their data for specific pages. The system has about 200 non-techy users who have no problem with the interface. +1

Here's my first attempt at a public repo for Rock Admin Tweaks. Has the AdminOnSteroids tweaks from above, and my QuickWebAuthnLogin already ported over from RockMigrations.

Yeah, that can be a good approach, see https://youtu.be/7CoIj--u4ps?si=q1RnzHLNWwt15TlE&t=1715 (ALFRED) for this. It might not be the 100% solution (in terms of UI/UX), but it might probably be the best in terms of cost/benefit.

Haha, so true. How often have I heard "super easy, super simple..." ? I agree with most of what @wbmnfktr said, but IMHO if you don't use the PW backend you probably lose one of the main advantages of PW over laravel et al. You have to build all the forms, all the logic and all the underlying concepts on your own. Have a look at https://www.youtube.com/watch?v=MYyJ4PuL4pY for example. When you watch this video you'll see so many things that are so much quicker when using PW + backend. Do I say you should use the PW backend? No, but it's probably too early to ditch it. If the design is important it's probably easier to build something on your own, but it sounds like a quite technical project with tech-savvy users I guess, so using the PW backend should work quite well?! You could also just replace the things you want to have different and build your own admin theme. For example you could totally replace the main menu bar / header and leave everything else as it is. 80-100h sounds sporty to me ?

The header action feature is cool, thanks @ryan! Is there a way that a header action can be added through the PHP API rather than through the Inputfield JS API? A couple of reasons this could be useful: 1. I can imagine a module that would add some header action feature to every inputfield (or every inputfield of a particular type) and it would be simpler to do this via a hook before Inputfield::render(). 2. Sometimes the inputfield you want to target doesn't exist in the DOM when the page loads (e.g. Repeater subfields or other Ajax-loaded scenarios) and so the JS code to add the header action would also need to watch for other events like "reloaded" or "ajaxComplete", and again it would be easier to add the action in a before render hook. I was thinking that if the PHP API supported header actions then JS actions could be handled via an "event" property. So something like this... $action->event = 'myAction'; ...which means that clicking the icon would trigger a "myAction" event, and the developer would use JS like... $(document).on('myAction', '.Inputfield', function(event) { const $inputfield = $(event.target); // Do something involving the inputfield... }); And in case the action doesn't need JS but should instead be PHP-based or just link to some URL there could also be an "href" property which would make the icon into a link, perhaps to be used with URL hooks... $action->href = "/my-action/$page->id/$field->name"; ...and... $wire->addHook('/my-action/{page_id}/{field_name}', function($event) { // Do something with $event->page_id and $event->field_name here... }); What do you think?

My biggest issue with this - in terms of coding and stitching everything together - would be registration, user management, page creation through registered users, and keeping everything as easy and clean as possible for the users. They need custom interfaces and can't use the ProcessWire backend. They probably wouldn't get it. Second issue would probably be an additional management tool for all ads, users, and tasks that occur on a day to day base for such websites aka things user need help with. Maybe a bit of GDPR to allow users to totally delete their account and all their ads while keeping everything that might need to be archived by law. You didn't mention any form of payment process so things should be quite straightforward from here. For the frontend I'd go with clean PHP, clever site structure, and logic. Search, sort, filter with any kind of JS is nice, but not necessary. Later on I might add some nice and shiny AJAX-powered search bars, and things like that. BUT... all of the above isn't the problem with such projects. What you really need is a clear and precise description of what the client thinks he wants, written agreements about who delivers which part and who is responsible for what. Was asked to create a job board once. Client said: "Super easy. User creates an account. Adds job postings. List them on the website. Remove them after 30 days. Nothing special!" What he really wanted was a rebuild of monster or stepstone of one of those big job portals. So... yeah. How long would it take? At least 30k EUR.

File Mover Allows the selection of files or images for moving or copying to a different field. The destination field can be on the same page as the source field or on a different page. Screencast For convenience in the screencast this demonstration shows moving and copying images and files between fields on the same page, but you can also move/copy between pages by following the same process. Usage In any Images or Files field, hover on the field label to show the File Mover icon. Clicking on the icon will reveal the File Mover buttons. If no items are yet selected you'll see a button labelled "Select items to later move or copy". Click the button to enter selection mode. While in selection mode, click one or more images/files to select them. When you have finished selecting items click the "Done" button. Note: you can only select from one Images and one Files field at a time before completing the move/copy step. In the Images or Files field that you want to move/copy the items to, hover the label to show the File Mover icon and click it to reveal the File Mover buttons. When you click the Move or Copy button the page will automatically be saved and the selected items will be moved or copied accordingly. There is also a button to clear the current selection if needed. If you hover on any of the buttons a tooltip shows the filenames of the currently selected items, in case you need a reminder. Configuration There is a field in the module config that defines which roles are allowed to use the File Mover module. If the field is left empty then all roles are allowed. https://github.com/Toutouwai/FileMover https://processwire.com/modules/file-mover/

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?

Here's a small module I wrote a few years ago and was asked to share in the module repo. TextformatterImgDataUri This Textformatter checks all images in the field's markup for images under a certain size and converts those from links to data URLs, i.e. it embeds the image data itself. This can be handy when you cache whole pages and want to cut down on the number of requests. Original post with the module code:

I've been using ProcessWire for a long long time and over the years my techniques and go-to approaches have been constantly refined. A lot of this knowledge is codified in my internal heavily opinionated starter module that sets up everything up the way I like. Even with that, there are other tips, techniques, and modules that I may use occasionally on client sites and because of that, I may not remember them months or years later. I do have a document that I've been better at updating recently with this information, but in addition to that, I think to really remember a piece of knowledge it's best to actively use it even if not necessary. The best place I've found to do this is on my personal website. I treat my personal website as a semi-testing ground, a reminder of techniques and the generally the first place I will use something that maybe gets used on my other client websites. Even if I don't really need some specific module, need that odd hook, or require a specific setting, I will deliberately use it on my personal website because I have total control over it, it's live (meaning I have both a development and production version which allows me to test my deploy and sync scripts) and if something breaks temporarily it's not a big deal. For example, I'm doing the following on my personal site: various hooks that modify the admin; adding custom markup fields in the page editor for certain templates using dotenv (maybe eventually use this everywhere, but only here for now to codify the latest approach on this) using rockshell with some custom commands that I don't really need have a random snippet for tracydebugger in /site/templates/TracyDebugger/snippets/ created all the other special status files in /site/ (boot.php, download.php, failed.php, render.php) blocking the vendor folder in .htaccess have a random rewrite rule in .htaccess using ProcessRedirects with a random rewrite rule disabling sessions purposely have a dash in the name of my database (did you know Microsoft purposely put a space in the "Program Files" directory so that developers properly handle paths with spaces in it?) using Page Edit Lock Fields on my home and about page (yea, locking the page from myself!) experimenting with the AdminBar module and hooks, even though I won't use this module (I have my own admin bar that loads via ajax) overriding styles in the ProcessWire's admin bar (making the font small, smaller spacing, full width container) have a humans.txt file separately, using Matomo even though I don't really care about analytics for this site my deploy script deploys some extra random directories even though I don't need them have a separate user account that's been assigned the AdminThemeBootstrap theme I am working on using a honeypot field on my formbuilder-based contact form (I use this everywhere) I have a note (which is basically the above list) that I add to so it's easy to remember what I did, why and references to it (forum post, github, blog post, etc.). --- Separately, I have another completely blank ProcessWire installation with nothing extra done to it (except TracyDebugger). I use this to test and experiment various things (sometimes unrelated issues) when I don't want any hooks or installed modules potentially modifying anything. I'll also install modules here that I'm not so sure about. If I suspect I hit a bug with ProcessWire in a separate installation, I'll experiment here as well. Once I'm done fully experimenting and the issue has been resolved, I'll make a note in a log of what I did then undo my changes bringing it back to a clean slate.

I created regular user accounts via the PW API with a specific role. Then I build a frontend login form using the PW API with the build in login throttle module and added a hidden honey pot field and a simple number captcha. Doing so allows to not expose the true admin login URL, which I keep for the side admin and two maintenance accounts. The admin template checks for the roles and throws a 404 PW error if a user with the role of the frontend-user would try to enter any backend page. So for those frontend users it seems the PW admin backend does not exist at all, while the site admin or the two other accounts can enter the PW backend parts which are accessible based on their roles and permissions granted.

Hi, still sounds doable with plain PW to me. I would go with a frontend login to allow users to login to protected areas of the website frontend from where they could add pets via templates or module logic. Would limit the users to just see the frontend parts they need without beeing able to enter the backend. Did something like this with up to 10.000 users for a kind of booking portal.

That sounds to me like a totally different project now. This way you could offer a solution that's managed. In other words: the frontend lists all offers/ads, categories, filters, and everything you need. When it comes to posting ads they could all be collected by a more or less simple form (FormBuilder would work perfectly well here). In case of shelters that have a whole lot of animals they want to list, they could send a CSV (or Excel that needs to be converted) and you or someone imports it via ImportPagesCSV. Even references to that animal shelter profile could be set and other things of course. The inital cost would way lower, the project could grow and it would only be necessary to build what is really needed, and you could offer to manage that site for a monthly fee. Start with a minmal solution and go from there. We did this with a restaurant directory completely managed, no registration needed. But that's just my thought before my first coffee. ?

I just wrote a first draft of the precise specifications... And gosh, that would be a tremendous work to do with a framework. So, I think, as you all pointed, that it would be better in terms of cost/benefit, to use PW admin. This project has no profit objectives. They want to raise funds by donations and crowdfunding for the website. I thus have to offer them the best cost/benefit ratio (end still pay my bills at the end of the month ? ). The design is not that important. But most users won’t be tech-savvy. So it has to be simple and straightforward. That being said, I didn’t explore how to twitch the admin theme in PW (that was next in my PW ToDo list). It would be a great occasion. I recently thought about using exclusively the Dashboard module for some restricted user accounts in a website I’m doing – and I don’t even know how to do that. Any suggestion about tutos and posts that could help me explore this aspect of PW are very welcome (I took note of your YouTube video, Bernhard, and will watch it ASAP). Thanks guys, as always, for your help and your time. Much appreciated. ❤️

Oh no no no... it would be ProcessWire front, back, and center. But I wouldn't use anything like Svelte or whatever on the frontend or even go headless in this case. In addition to that, when I spoke about custom interfaces and management tools I meant things like we can see in the Invoice Site Profile.

Let's assume you want to change the title of a an edit page. You could hook ProcessPageEdit:execute in a file like site/ready.php like described here. Adapt the template name in the following code to your needs: $wire->addHookAfter('ProcessPageEdit::execute', function (HookEvent $event) { $pageEdit = $event->object; $page = $pageEdit->getPage(); if ($page->template != 'shop') { return; // return early } $this->wire('processHeadline', 'My new headline'); // or modify the existing headline // $headline = $this->wire('processHeadline'); // $this->wire('processHeadline', $headline . " - " . date('d.m.Y', $page->created)); });

I don't think so. When I asked Ryan recently about modifications for our admin style he said he usually does those small modifications with JS. Not very pretty, but on the other hand this might be more robust than str_replace (which is not pretty either).

I agree, users must not use PW backend. I was thinking of a custom backend (my account / my ads / CRUD for each ad) and then use PW API to manage that. I recently dived into the page / template / field management API, and it’s quite simple and straightforward. And I also agree, JS is not necessary – it’s just for things to be smoother and nicer, like an AJAX search result display. You are right about GDPR. I need to investigate a bit more about that. So if I got you right, you would go with a from scratch PHP backend ?

@Robin S I ended up using boot.ini to extend PW's class loader early enough to allow traits to be used in the UserPage class. More on this here.

My eyes. I think String Theory will be easier to comprehend. Seriously though, imagine in 4-5 years as the team behind that creation withers away (as they find new jobs) and the domain knowledge leaves the company, with new team members taking over and having to maintain and build upon THAT. It's going to get worse before it gets... worser? WordPress is bad for your mental health.

Hi all, I am turning out to be a liar at this rate! I really should stop talking about 'tomorrow'. I can only apologise. Projects and Padloper 009 kept me very busy the last many months! I wasn't able to do much on MM next. During that time, I realised that a number of underlying concepts of MM had to change. Hence, I started a re-write of MM but the pace was slow due to afore mentioned reasons. Now that Padloper 009 is out of the way, my main coding focus is on MM! I am quite confident that I'll be able to have a release within a month. This will be a late alpha or early beta, but at least something that can be tested. I don't take your patience for granted. I am trying my best not to let you down this time ?. Thanks!

I was unaware of RockAdminTweaks and have now installed it alongside RockMigrations. Porting the tweaks over is very simple (just a change to the namespace in the tweak file) and I prefer having them in the assets folder as well.

I totally support this. Since the tweaks part of RM can be expected to grow, I also think it would be better to have this in a separate module. RM really should be what it states: the ultimate automation and deployment tool. This is where it shines. I'd be sad to see it become bloated with functionality not related to that. Just my honest opinion.

I really like the idea with a tweaks pluggable collection. But I would prefer its usage was separated from the RockMigration module, so one could use tweaks without the more developer-centric migration tool. I thought that @bernhardstarted a dedicated module for that, but not sure if it is still alive.

Hi guys. Check out my latest project Casa Douro Guesthouses. As the name implies, Casa Douro offers a few guesthouses in historic Porto and on the Douro Region. They came to us looking for a well built website that would fit their marketing efforts and grab direct reservations, instead of relying only on Booking.com and Airbnb. Since their channel manager (CM) software only offers a cookie-cutter website and no API, ours does all the presentation and jumps straight to the booking system when the user decides to make a reservation. As usual on my sites, pages are built using a blocks system (Profields Repeater Matrix), allowing the admin to change things up a little bit between the different units. Plus the usual WireMailSMTP, SEOMestro, and Rockfrontend because I love using Latte templates. The frontend is a mix of Tailwind + SCSS on more complicated components, and JS over Vite which allows me to keep it as vanilla as possible. We already have plans for new sections, and maybe upgrade the booking system in the future.

I will wholeheartedly admit that I may be going a little hard on WP. I know there are good devs everywhere who use the platform that works for them and their clients. I could be taking it a little easier on WP and it's plugins. ALRIGHT, THAT HAVING BEEN SAID *takes swig of beer, chucks bottle* Kidding, but I have been posting very punctuated examples of issues, some of which are more widespread than others. I also haven't been posting any real nuance, so I guess that's also not really a fair play either. I'll admit that I haven't been in a situation personally where a media manager came to mind- so I'm not going to make a blanket "never use them" statement. I can definitely see how what you said could grow into an issue, and combined with the "free for all" no size limit image fields, certainly. I like per-page media but a centralized media manager makes sense logically, especially to developers because we reuse code/resources to stay DRY. It's 100% appealing to me in that sense. However the "management" part of a "media manager" takes active effort and I'm inclined to believe that this isn't something clients/users keep in mind. I say that both theoretically and empirically. Media management can be an efficiency construct that exists outside of "keeping my website updated". Contrast to PW's per-page assets that works the way a client would think it does- when a page doesn't exist anymore, none of it exists anymore. The developer gives up what they know would be a better idea technically for asset reuse (central management) for the simplicity in user experience (distributed management). Recently I was forwarded email from a client from their web host stating that they had reached their website backup space and directed them to upgrade their plan. They asked if they should buy the upgraded package, I told them I'll take a look. I logged into one of their WordPress sites and deleted almost 1gb of images that had not been in use for years. Logged into another and deleted even more. I was almost 100% sure I knew what the culprit was just reading the email. This was a layer deeper than their server disk space. A hybrid approach (I'm sure this has been discussed before elsewhere already) in PW would be interesting where asset fields have a "Select From Another Page" option that allows for reuse, but is still tied to pages. Not to get too in-the-weeds, but extend the current assets/{page id} concept where selecting an asset from another page moves that file to assets/{new id}_shared. Now both reference the same file "manager style" on the filesystem. Asset fields could have a way to view a list of pages that also use the asset, with the ability to "Delete From All". If the file is removed from all pages except one, it's moved back to the assets folder of that page and assets/{new_id}_shared is deleted. The back end handles the centralization, the user's workflow remains enhanced but without additional work. One of the things I discuss with clients is "How can we add utility without increasing workload?". It helps us balance what they want with what they can or are willing to do to make it work. I'm inspired by Colin Chapman, founder of the Lotus car company, where his philosophy when building cars was "Subtract weight, add lightness". In day to day use, I think an optimization for the developer should feel like an optimization/feature for the user if they have to interact with it (as much as reasonably possible of course). I will repeat the caveat that I haven't experienced a situation where the solution was centralized media management- or I've been such a devotee to distributed management that I never think to consider it. Either way that's on me ? The only time I've run into this is for truly site-wide content like logos, or certification/awards logos for the footer which is handled easy by a "Site Settings" page in the page tree, it works because there's still some sort of dedicated purpose for those fields that keeps the images contextually organized. That might be another case-in-point about my limited experience in that situation though. I considered this the most on the my last post re: Contact Form 7. It's a plugin and not core, absolutely. So the developer dropped the ball, happens. Unfortunately issues happen all too often, so I mention it in a manner of a cumulative stack amongst many plugins. I will suggest some responsibility by WP though because of it's built-in reliance on plugins- oh, you want custom fields? (you know what comes next) It's arguable that there's an ecosystem problem, one that WP's architecture, theme reliance, messy admin, and plugin implementation has a healthy hand in. Is the complexity or quality of the core a contributor to plugin problems? 5 minutes with the WP Codex is a little convincing IMHO. If I had the time maybe I'd try my hand at Fluency for WP (did I just say that out loud?). Ironically, the list of issues I (and many of us) could come up with exists as an antithesis to the PW methodology- and I guess that's why we're all here in the first place. So I may need to acknowledge that the dead horse is dead and put my beating stick down ?

Recently I transferred a website from WP to PW. First I had to clone the WP site in order to install it on a different hosting company. It turned out, that this WP installation (about 6 main pages and 20 subpages) with a few images, had the size of about 1 GB! This video helped me: https://www.youtube.com/watch?v=tIurrwfsCOg&list=LL&index=32&t=474s I found in the upload directory a lot of 7000px wide jpgs. Every time an image is uploaded, WP generates about 4 or 5 different size variations and keeps them all in the same directory. There were plugins installed, that all begged for an upgrade. Everywhere in the backend constantly informations from different sources popped up. After I finished the new website in PW, I compared the amount of the generated html code. The PW code was about 80% smaller.

Okay, colleague, I'm writing the report for the boss. Let me know if I've summarized it well: Then I asked ChatGPT to improve it in a more funny way:

@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.

i.am first you can puut this in your head.inc tamplate or some includeded file before.u are doing $page->url $pages->addHookAfter('Page::path', null, 'hookPagePath'); function hookPagePath(HookEvent $e) { $page = $e->object; if($page->template == 'article') $e->return = "/blog/$page->name/"; }