Leaderboard

We had a smooth rollout of the new main/master version 3.0.200 last week (read all about it here). If you haven't upgraded yet, consider doing so, this new version is a great upgrade. I'm going to add the 3.0.200 tag shortly after I finish this post, which should trigger other services (like packagist) to upgrade. I've had a new client project in the pipeline that I've been waiting to start till the new main/master version was out, so this week I started that project. Pete and I are working together on it, like we've worked on others before. It involves taking a popular WordPress site and rebuilding it completely in ProcessWire. I've done this a couple times before, but this time it's bigger and broader in scope. I always find the large site conversions to be great learning experiences, as well as great opportunities to show how ProcessWire can achieve many things relative to WordPress, in this case. At this stage, I'm having to spend a lot of time in WordPress just to get familiar with the content, fields, etc., as well as in the theme files (php and twig). The more time I spend in these, the more excited I get about moving it into ProcessWire. For this particular site, moving from WordPress into ProcessWire is going to result in a big boost in efficiency, maintainability, and performance. Part of that is just the nature of PW relative to the nature of WP. But part of it is also that the WP version of the site is kind of a disorganized patchwork of plugins, code files, and 3rd party services, all kind of duct taped together in an undeniably confused, undisciplined and fragile manner. (Though you'd never know it by looking at the front-end of the site, which is quite nice). This has been a common theme among WordPress sites I've dug into. Though to be fair I don't think that's necessarily the fault of WordPress itself. I always enjoy taking a hodgepodge and turning it into an efficient, performant and secure ProcessWire site. I love seeing the difference it makes to clients and their future by taking something perceived as a "necessary liability to run the business", and then turning it into the most trusted asset. I think the same is true for a lot of us here. We love to develop sites because it's an opportunity to make a big difference to our clients… and it's fun. Ironically, if past history is any indicator, I seem to get the most done on the core (and modules) when I'm actively developing a site. Needs just pop up a lot more. I don't know if that'll be the case this time or not, but I do expect to have weeks with lots of core updates and some weeks with no core updates, just depending on where we are in the project. This particular project has to launch phase 1 by sometime in July, which is kind of a tight schedule, and that may slow core updates temporarily, but who knows. I'll share more on this project and what we learn in this WP-to-PW conversion in the coming weeks. Thanks for reading and have a great weekend!

@bernhard yes sir it is the same software but I did a bit more work on it before my computer was lost/stolen. I recently recovered the hard drive and got it up and running again, and hated to scrap the project. As stated earlier by @dynweb, unfortunately I agree and I don't really see much use for a forum anymore. I appreciate everyones time that posted ?

@bernhard I had nothing groundbreaking going like a module or anything, but I had users being created using the API by following: https://gist.github.com/woganmay/4c15a0f7c16e41ab3a3ea1a73c595bf9 So when a user was logging in to the members area I had created in ProcessWire, it was creating a user on the forum with the same email address and password as what they had just logged in with. I never got round to getting them logged in to Flarum unfortunately so gave up, but I was obviously looking to remove some options from Flarum like logging out, and registration and stuff. It seems this could be a good thing to look at: https://discuss.flarum.org/d/21666-php-and-wordpress-single-sign-on-sso-with-optional-jwt-addon

Hi @wishbone Maybe you can take a look at this module. Gideon

Updated for PW 3.0.200 master. Download here: https://github.com/apeisa/Finnish-ProcessWire/archive/refs/tags/v.3.0.200.zip

A week ago the new website of the wuppermann group went online. The Wupperman group is a EU-wide operating company with several locations in different countries. Their portfolio is all about steel fabrication. This includes flat producs, tubes & profiles. The technical production is developed by me, Olaf Gleba. The grafic design is supplied by C&G: Strategische Kommunikation GmbH. Homepage: https://www.wuppermann.com Some Impressions: (Secured) Shareholder portal, only available in german language Former screens deleted on behalf of the client. Technical notes: 1. All contents are populated by provided (i name them) content modules (e.g. Repeater Matrix Types) which gets the client what he needs and either prevent him from doing weird stuff. In nearly all textareas formatting is limited to a absolute minimum. For example, image insertion in CKEditor is generally prohibited. Instead there are dedicated fields for modules which holds media contents. 2. This and that.. - vCards are build on the fly with a admin hook on page save. - PrivacyWire as CCM (just a few cookies to handle Matomo and external movie content) - Uses the SearchEngine Module to handle (multilanguage) site search - Email Obfuscation Module for frontend e-mail addresses - Wire Mail Smtp to deliver automated e-mails - Multilingual (german, english, hungerian, polish, dutch) - Ajax driven content (for example on the contact page) - Heavy use of Fieldtype AssistedURL (Fork by @adrian) to provide language dependend, local file linking (fieldname_[de|en] approach) - Login area (closed shareholder portal) with secured file downloads ($config->pagefileSecure = true) - Email New User, Admin Action (create users batcher), Force Password Change for functionality like adding new users with specific roles, Password reset, Change Passwort a.s.o. - Distribution of concatenate/minified css and javascript is cachebusted (happens within my developement environment,- no modules (like AIOM etc.) involved). - Thanks to @ryan* all images are delivered in WEBP format (with fallback). *) s. https://github.com/processwire/processwire-issues/issues/1497 - The site uses a bunch of modules provided by the ProFields Package (for example Repeater Matrix and Table Fieldtypes).

I think a better way is to skip the Add Page step and then make sure the title is always automatically derived from your two fields when they are populated. There are a few steps involved, illustrated here with case that is different to yours but you can see the similarity. In this example the template of the parent page that new pages are added under is named "creatures", and the child template (where the title is being set automatically) is named "creature". 1. For the "creatures" template, make sure that it allows a single template for children: the "creature" template. 2. For the "creatures" template, in the "Name format for children" setting enter "Y/m/d H:i:s". This will allow the "Add Page" step to be skipped and will automatically set the page name to the current date and time. We will later change the name in a hook. 3. Optional but recommended: for the "creature" template, choose the "creatures" template as "Allowed template(s) for parent". This lets you quickly add child pages via Pages > Add New and also ensures that new pages can't be added in the wrong place. 4. For the "creature" template, edit the Title field in the template context and set the visibility to "Open when populated + Closed when blank + Locked (not editable)". The title is going to be set automatically so editors should not be able to change it manually. 5. Add hooks like the ones below to /site/ready.php. // Pages::added $pages->addHookAfter('added', function(HookEvent $event) { /** @var Page $page */ $page = $event->arguments(0); // Creature if($page->template == 'creature') { // This is a newly added page so the fields that make up the title won't be populated yet $page->setAndSave('title', 'New creature'); } }); // Pages::saveReady $pages->addHookAfter('saveReady', function(HookEvent $event) { /** @var Page $page */ $page = $event->arguments(0); /** @var Pages $pages */ $pages = $event->object; // Creature if($page->template == 'creature') { // Return early if the page is in the trash (thanks @taotoo) if($page->isTrash) return; // If the fields that make up the title are populated if($page->colour->id && $page->animal->id) { // Set the title $page->title = "{$page->colour->title} {$page->animal->title}"; // Sanitize the title as a page name $name = $event->wire()->sanitizer->pageName($page->title, true); // Set the page name while making sure it auto-increments if there is a sibling page with the same title $page->name = $pages->names()->uniquePageName($name, $page); } } }); Result:

This week we have some improvements to the $pages->findRaw() method. Most of these are based on requested improvements in either GitHub (like #427) or the forums: Support for selecting parent properties/fields in the return value, i.e. $pages->findRaw("selector", "parent.title"); // Example 1 $pages->findRaw("selector", [ 'title', 'parent.title', 'parent.parent.title' ]); // Example 2 Support for selecting page 'meta' data in the return value, i.e. $pages->findRaw("selector", "meta"); // example 1 $pages->findRaw("selector", [ "meta.foo", "meta.bar" ]); // example 2 Support for selecting "references" in the return value. References are other pages that reference the found page(s) via Page reference fields, just like the $page->references() method. $pages->findRaw("selector", "references"); // example 1 $pages->findRaw("selector", [ 'references.title', 'references.url' ]); // example 2 If you want the references to be indexed by field name, just include "references.field" in the requested fields: $pages->findRaw("selector", [ 'references.field', 'references.title', 'references.url' ]); Support for selecting title and/or value from options (FieldtypeOptions) fields, i.e. $pages->findRaw("selector", [ 'my_options_field.*' ]); // example 1 $pages->findRaw("selector", [ 'my_options_field.title', 'my_options_field.value' ]); // example 2 Support for a new "flat" option that flattens multidimensional arrays in return value. This is best explained by an example. Let's say we did this: $pages->findRaw("categories.count>0, limit=1", "title, categories.title" ); And it returns an array similar to this for every matching page: [ 'title' => '2-factor authentication coming to ProcessWire', 'categories' => [ 1035 => [ 'title' => 'Security' ], 1288 => [ 'title' => 'Users' ] ] ] Now let's try the flat option: $pages->findRaw("categories.count>0, limit=1", "title, categories.title", [ 'flat' => true ]); (side note: you might already know this, but fields and options can also be bundled in the selector like this below, which is identical to the above): $pages->findRaw("categories.count>0, fields=title|categories.title, flat=1"); It flattens any multi-dimensional arrays in the return value to be indexed in the same way that you requested them in the $fields argument: [ 'title' => '2-factor authentication coming to ProcessWire', 'categories.title' => [ 1035 => 'Security', 1288 => 'Users' ] ] In addition to these updates for the $pages->findRaw() method, this week there have also been updates to the $sanitizer->float() method and InputfieldFloat module. Now both support numbers with E notation such as 1E-2, 10E-14, -1.253E-5, etc. There are also some new values for the getString option on the float sanitizer. I don't work with this kind of stuff very often, so thanks to @MetaTunes on GitHub for helping to figure it out. Lastly, the ProcessTemplate module also went through a refactoring with some minor improvements this week. Thanks for reading, have a great weekend!

Welcome to the forums @OxfordSUOliver If you have access to your files, paste the following temporarily into one of your template files and then visit a page that uses that template: $u = $users->get('sup'); // or whatever your supersuser name is $u->of(false); $u->pass = 'your-new-strong-secret-password'; $u->save(); Remember to delete the above from your template file once done. If you don't know the name of the supersuser, you can check this in your DB tables. See the pages table. Scroll down to user with ID 41 and check the string under the column name. Alternatively, temporarily again, in a template file, do the following: $u = $users->get(41); echo $u->name;// this is the name you want for logging in Note the original ProcessWire Superuser ID is normally 41, unless for some reason your colleague changed it, which would be highly unlikely, although they could have deleted that user having set up an alternative Superuser ?.