Leaderboard

ProcessWire 3.0.181 has fixes and improvements as usual, but the biggest addition is a nice pull request from @LostKobrakai, plus major updates to our Helloworld and ProcessHello demonstration modules. This post covers it all— https://processwire.com/blog/posts/pw-3.0.181-hello/

u can use unpoly. Layers - Unpoly <a href="/post-page" up-layer="new" up-target='.content'>Open Content</a>

Hey @Pete... do you have an idea when we will have the reputation count back? The more I use the forum now, the more I somehow want it back as fast as possible. It's probably weird but... it was such a great indicator for a lot of things here. And no... it's not about my silly amount of reputation points.

A few days ago I stumbled upon this old module, which had been laying in the modules directory of one of my sites since 2017 in a half-finished state. I have no recollection why I left it like that, but figured it might be useful for someone, so here we go: https://github.com/teppokoivula/Snippets https://processwire.com/modules/snippets/ Snippets is a tool for injecting front-end code snippets (HTML/JS/CSS) into page content. The way it works is that you create a snippet — say, a Google Analytics tag — and then choose... which element it should be tied to (there are some pre-populated choices and custom regex option), whether it should be placed before/after said element or replace it entirely, and which pages the snippet should apply to. The "apply to" option also has some ready to use options (such as "all pages" and "all non-admin pages") or you can select specific pages... or use a selector. Snippets are regular markup, with the exception that you can use values from current page (behind the scenes the module makes use of wirePopulateStringTags()). Available hooks: Snippets::isApplicable, which receives the snippet object and current Page object as arguments and returns a boolean (true/false). Snippets::applySnippet, which receives the snippet object, page content (string), variables (an object derived from WireData), and an array of options for wirePopulateStringTags() as arguments and returns the modified page content string. That's just about it. It's a pretty simple module, but perhaps someone will find this useful ?

CodyFrame is their CSS framework (free). It uses the BEM convention. It handles things like colors, spacing, fonts, form styles. No JS. Then there's CodyHouse UI Framework / components which use CodyFrame as the base layer. There are many free components, but CodyHouse Pro membership (now a one time fee for life), gets you access to all the components. The difference I see with CodyFrame + CodyHouse components vs Bootstrap/UIkit is that CodyFrame is just and base layer and doesn't try to do every possible thing. CodyHouse components are where they make their 1-off, tightly coupled section templates. By tightly coupled, I mean that the component relies on the utility classes from CodyFrame + specific CSS classes for the component that aren't in CodyFrame + any dependencies on other components + custom, vanilla JS for that particular component (this part is huge). I feel like this 1-off approach gives them a lot of flexibility, although it means you as a developer have to take the necessary files and insert them correctly into your project (which is not hard). Here's their offcanvas component which is a good example of what I described... it relies on (a) CodyFrame + (b) custom CSS for that particular component + (c) custom JS for that particular component + (d) other component dependencies (like animated menu button): https://codyhouse.co/ds/components/info/off-canvas-navigation https://codyhouse.co/ds/components/app/off-canvas-navigation They've done all the hard work for you. I think this will be my go-to front-end framework moving forward.

Not sure why they removed it from the design flow, but you can easily hover any member's avatar to see it:

Here are some quick items to consider, based on how I would upgrade a site: - start over, back to the original version (2.5) - Login as superadmin - enable debug mode from the config - Make sure the site is fully functional on localhost in the original version; if there are PHP errors/warnings on the front end, e.g. related to php version, fix those first before upgrading the site - Upgrade any modules that are compatible with 2.5 - once the site is running with no errors on 2.5, upgrade the core to latest stable version if you replace the htaccess, make note of any settings that need to be copied over (www, https, pro cache etc) - upgrade all modules to the latest using the upgrades module Note that the new core compiles the non-namespaced files. You can clear the filecompiler cache (bottom of modules) if you see any errors related to that, if you still see no content on the homepage, check for js/browser errors; Check how assets are being referenced; paths could not be resolving.

Or htmx) Or by hand with js.

Yeah. The simplest solution I can think of would be to set visibility of the title field to "hidden (not shown in the editor)" --> setup > templates > yourtemplate > click on title field > visibility Then just do whatever you want with that field via a simple hook. To test it place it in /site/ready.php - to get a good setup create an autoload module that handles your business logic and place the hook there. <?php // create a unique name on page creation (when id=0) $wire->addHookAfter("Pages::saveReady(template=yourtemplate,id=0)", function(HookEvent $event) { // set unique name, see options array $page->name = $this->wire->pages->names()->uniqueRandomPageName(); }); // set title to full name (forename+surname) on every save (id>0) $wire->addHookAfter("Pages::saveReady(template=yourtemplate,id>0)", function(HookEvent $event) { $page = $event->arguments(0); $page->title = $page->forename." ".$page->surname; });

So true! Repeaters are nice but... only in limited cases. Keep the title field - reuse or overwrite it with a unique identifier of some kind or anything else... had so many cases I thought I wouldn't need it but at the end it was somehow my lifesaver or at least the one and only unique identifier I had. Free your mind from the label "title"... you can write anything in it, either way. You could also ignore that field, remove it in your template to be seen and work with the module PageUseIdAsName to get your unique identifiers.

Hey @LuisM... just a short feedback on this. I'm really happy you would take your time to guide me and probably anyone else trough this setup and what's possible with it. I already talked to @bernhard in the past several times in regards to his module as I was super interested how all that works. I'm still impressed what he does with that setup. I really really love those kinds of setups, workflows and automations... yet... the initial setup of RockMigration is already way larger and more complex than any of my projects. My projects (look at muskaat.de) are most of the time super simple and straight forward. They do what they need to do... sometimes more complex, sometimes only a few more files, and most of the time only a DEV and LIVE stage. Nothing I'd need such a setup for. Even though I really am a Spielkind (someone that loves to play around with all possible options). Still... I know and understand the benefits of those setups with RockMigrations - and your addition to it - and what they could and can do. As I'm most of the time the one and only developer for now... Git is perfectly fine for any workflow I can imagine. I'm missing two or three developers on my side and maybe a few more stages, like dev / qa / testing / preprod / live, within my projects to really benefit from your and @bernhard's modules. Yet... I really appreciate all the things you both and several others here build to make ProcessWire even more awesome for whoever.

Hi @teppo PR merged on the trust. ? As posted on GitHub , your eyes will surely solve my newbie errors. ASAP I will check deeply all. Thanks again.

v0.0.67 has a fix to setModuleConfig method that might change how existing implementations work: $rm->setModuleConfig("AdminThemeUikit", [ 'maxWidth' => 0, // use full width of screen ]); Before the fix from today this code would have reset any other module settings (like a custom logoURL). No it does only update the maxWidth setting (as it merges existing config data). If you want the old behaviour you can set the third parameter to TRUE: $rm->setModuleConfig("AdminThemeUikit", [ 'maxWidth' => 0, // use full width of screen ], TRUE);

Wouldn't that be $wire->files->copy(src, dst); ?

https://processwire.com/docs/selectors/operators/ https://processwire.com/docs/selectors/ https://cheatsheet.processwire.com/selectors/ id!=1234, id!=2345

Both the list on the Modules page and the fieldtype select on field edit screen expect fieldtype module names to start with "Fieldtype". BaseFieldtypeRuntime starts with "Base", so it's grouped under "Base" on the Modules page, and also not included in the fieldtypes (wire)array managed by the core (see /wire/core/Fieldtypes.php).

Thx @Robin S, I had a look to those fieldtypes and you where partially right. I removed sleepValue and deletePageField since they should never get called on a non-db fieldtype. But your runtimeonly field does actually have too few methods if you want to keep it completely out of the db. Your fieldtype creates an empty db table. Not sure if that is intended? I've invested some more time and really like this approach of building new Fieldtypes! Is really simple, see this example of a new Fieldtype called "FieldtypeNow": I renamed the base fieldtype to "BaseFieldtypeRuntime" and it really does not do anything other than providing the boilerplate. It does not even show up in the list when you create a new field in your pw installation (screenshot later). This is the current code: Actually it does only define the inputfield and add some hooks to replace the render and renderReady methods by our own implementations and define all the functions necessary to keep the db out of the game: Simple, right? ? This is how the installation screen looks like: The BaseFieldtype is set as dependency, so FieldtypeNow can only be installed when the Base Fieldtype is available. Once installed, you can easily create a new field of that type: Notice that there is no Fieldtype "BaseFieldtypeRuntime" in this list as I mentioned above. You can then add your field to a template and edit any page of that template: <?php namespace ProcessWire; /** * Demo Fieldtype Extending the Boilerplate Runtime Fieldtype * * @author Bernhard Baumrock, 03.10.2018 * @license Licensed under MIT * @link https://www.baumrock.com */ class FieldtypeNow extends BaseFieldtypeRuntime { public static function getModuleInfo() { return [ 'title' => 'FieldtypeNow', 'version' => '0.0.1', 'summary' => 'Fieldtype showing the current time', 'icon' => 'code', 'requires' => ['BaseFieldtypeRuntime'], ]; } public function render() { return time(); } } Another Fieldtype rendering the content of a php file named like the field (very similar to the existing modules by @kongondo RuntimeMarkup, @Robin S RuntimeOnly and @kixe FieldtypeMarkup). You actually only have to implement the render() method, and if you need you can load scripts in the renderReady() method... This fieldtype loads files that are named like this: site/templates/FieldtypeRenderFile/{fieldname}.{templatename}.[php/css/js] site/templates/FieldtypeRenderFile/{fieldname}.[php/css/js]