Leaderboard

This week there are a few minor updates on the dev branch, though not enough yet to bump the version. The most notable are a few improvements to the database selectors you can use with $pages->find() and similar API calls. While working through issue reports a few weeks ago, there were a couple issue reports that indicated one selector or another not working. What I found was that it was working as designed/built, but they were just selector features that had never been supported. But they also seemed like good/useful shorthand syntax to support, so I was enthusiastic to add support for them. I just wanted to wait till we were back on the dev branch, as we are now. Here's what's been added: Support for OR values on "status=" selectors. Now you can match one status or another with PageFinder selectors by specifying a selector like "status=hidden|unpublished", and this will find all pages that either have hidden or unpublished status. The hidden and unpublished are just likely the most common examples, but you can use any other status name, or as many statuses as necessary in your OR condition. Previously it was possible to match pages having one status or another by other means, but it was far from straightforward. Now it's nice and simple. Support for OR values on "sort=" selectors. This one isn't technically an OR condition since we are giving a command to the selector engine about how it should sort, rather than trying to match something. You can tell it how to sort with the syntax "sort=date|title" as an example. That would be shorthand for "sort=date, sort=title", which is saying "first sort by date, then by title". Support for combined start and limit selectors. Previously you have had to specify "start=x, limit=y" separately, if you needed it. Now you can optionally specify both as part of the "limit", for example "limit=5|10" which is shorthand for "start=5, limit=10", and actually kind of similar to what it translates to in MySQL, which is "LIMIT 5,10". I suspect that not many people ever use "start=" in their selectors unless using "start=0" to prevent a set from paginating. So if you wanted a set of 10 pages that don't follow the current pagination, you could specify "limit=0|10" in your selector, or the more verbose "start=0, limit=10" will work in any PW version. Support for matching children paths. This is a small one, but previously you couldn't do "children=/path/to/page" to match a page having the given child path. Though you could do "children=123" where 123 is the ID of the child page. It has been updated so that it can now support paths in addition to IDs, just as "parent" does. I'm not sure why we didn't have support for this one before, it likely just hadn't come up yet. You can use OR values here too if you'd like. As before, you can also use subfields on "children" as well. Worth mentioning is that these are additions for our PageFinder engine which queries the database. We also have the lesser used in-memory selectors which don't yet support all of these, but I've put it on my to-do list. In-memory page finding selectors come into play if you are post-filtering pages that you have already loaded from the database into a PageArray. We like these to maintain some consistency with the database selectors when possible, so I'll likely have that working here soon. From this end, I'm also putting ~2 hours of work into the new Pages Snapshots module every day, with a lot of progress but also still a lot of ground to cover. Separately, I'm working on pulling more than 4 million articles out of an older proprietary legacy CMS for a newspaper organization and converting them to a standard XML format for import elsewhere. A lot of data conversion has to take place in terms of cleaning up markup for each article. ProcessWire is the tool that all of this is being done in, and I'm using a lot of $sanitizer methods as well as keeping HTML Purifier busy! Thanks for reading and have a great weekend!

Ok - this write up got quite long so I reckon it counts as a case study. Crest Research is a hub for academic articles and information about security research collated by the University of Lancaster and other universities in the UK. Their old site had been running for several years on Word Press. There was a lot of content that wasn't brilliantly organised and there was lots of plugins that had been added to WP (honestly one of the things I like least about WP is that it's too easy for users to add plugins without really understanding the implications). We persuaded the University that it would be much better to make the move to Processwire. No small part of that was being able to demonstrate that PW was a much better option from a security point of view. We also wanted to be able to develop an API that provides content to a native app we built for Crest a while back; that probably would have been doable in WP but much easier in PW. This was our first reasonably large move from WP to PW so we learnt a lot on the way. So - first step was to import all of the posts from WP. For this we headed to Adrian's ProcessMigrator module which worked well at getting the data over. Once we had the data over we used Wanze's ProcessBatcher module to do bulk updates and moves to try and organise things (including deleting a load of WP tags we didn't want to keep). We found that we needed import certain things manually as well, in particular some thumbnail images. For these we just created an import script that read through a CSV of data that we'd dumped from the WP database. Honestly PW is just great at this - we had a column of page aliases and a column of image URLs and with about 10 lines of code we manged to download the images and add them to our imported pages. We've used this method of a CSV and an import script on a couple of other projects where we've needed to load content from other platforms and it's been very straightforward and effective. Once we had the content over there were a couple of other bits of functionality from the WP site that needed to replicate. One of these was a download manager. The old site kept statistics of the number of file downloads which we needed to replicate (and retain the old data) so we built a modue to handle that. This was pretty much our first foray into PW module development and Bernhard's blog on building admin modules was very useful. We tried to remove as many WP short codes as possible but those we need to keep we replicated in the Hanna Code module. The search on the new site was very important to the client - a lot of their targe audience is researchers and academics. We ended up with a system of filters (author, tag etc) together with the text matching operators that appeared in 3.0.160. The client also asked if we could add some kind of fuzzy searching for misspelled words and US / UK spelling differences which we did by adding to the lemmas in Ryan's WireWordTools module. Our additions our available on GitHub. I think there's still plenty of refining to do on the search but it works well. Another thing the client asked for was an indication of 'Reading Time' for an article as Medium have on their articles. We added a hook to calculate the reading time for an article when the page is saved. Can't seem to find the blogpost on Medium where they explained their formula but I've stuck the code we ended up with up on GitHub as a gist here. Other modules we used include: AIOM+ - this was before we got a license for ProCache. We used AIOM and then some hooks to generate cached versions of some chunks of html using MarkupCache. Probably wouldn't bother now and just use ProCache. Redirects - we tried to keep the site structure the same as the old site for SEO, but there was quite a lot of organising. We grabbed the top few hundred pages from Google Analytics and then ran those through a PHP script to check their status on the dev site (gist of that script on GitHub as well ). We dumped those results into a spreadsheet and decided where they needed to be directed to. Then we imported that list back in the Redirects module. Other honourable mentions go to Connect Page Fields, Page Field Edit Links, Dashboard, Schedule Pages and of course Tracy Debugger (which was particularly useful on this project). So... I'm sure you're asking (assuming anyone has made it this far) what the end site was like and whether the client was happy? Well comparing the old and new sites in Lighthouse gave us this: And Mozilla Observatory gave these rather nice results (especially since it's a security focused site) This resulted in a big upswing in traffic. We're seeing about a 500% increase in vistors compared to this time last year (and from pretty good numbers in the first place). IMO the biggest factor in this increase was the improved page speeds. Now - of course we probably could have got similar results in WordPress if we'd spent enough time and energy on the site but by using PW we've ended up with a much cleaner site which the client is happy to use. Logging into the old site with it's upselling of plugins and so on is just painful. We've also educated the client as to why adding random plugins is not a good thing; the old site loaded 18 javascript files from various sites most of which we didn't know anything about - we have 3 now (and one of those is analytics which we tried to persuade them to lose.). Anyway - they're happy and we've got plans to keep developing the site over the next couple of years so hopefully it's just going to keep getting better. s.

I know I'm super late to this party, but since I've been away for quite some time - but absolutely love ProcessWire - and Ryan mentioned that this roadmap could extend beyond 2021, I thought this was the most appropriate place to comment. Thanks to @teppo's PW Weekly I've been able to, mostly, recount (in summarized form) multiple years of development (with plenty of tangential links, often reading the full blog posts by Ryan) both of PW and in 3rd party development efforts, so I don't feel too terribly left behind. Something a little different not yet discussed: Zooming out and looking at the bigger picture, within regards to the CMS/CMF landscape, I think an area that PW lacks is in marketing of itself, and I don't mean this as a knock on ProcessWire - the product speaks for itself and word of mouth is awesome, and marketing efforts can oftentimes detract from active development time. Marketing isn't exactly a "core feature" of the codebase, but it is something that I think can be code-adjacent. ProcessWire is capable of so, so much, but from just looking at it, or installing it from source, it's hard to see that from the eyes of a first-time user. ProcessWire doesn't use templates like WordPress, but templates are a big business with WordPress. Although some WordPress templates come bundled with custom plugins which starts skirting the line of what ProcessWire does (site profiles), there's a plethora of ready-to-go, custom designed websites with a only the simple task, after installing, of adding content. ProcessWire is more developer focused (which I personally love), but that doesn't mean we can't, or shouldn't, also cater to an audience that may want to see what designs or functionality can be made (almost) immediately available after install. As a simplistic first step here: currently Site Profiles are listed under Modules as its own category, but that's not too intuitive for findability - if this were to have its own landing page and higher level navigation, with feel good images based on the profile (for those that provide them), I think it might help to attract more potential users. On the topic of Site Profiles, since ProcessWire is capable of so much (that many of us aren't even entirely aware of), having some custom built, premium Site Profiles built as premium starter kits (kind of like what my buddy Jack McDade is doing with Statamic) it might be another boon, and additional income source. He's also considering selling branded merchandise, which I think we'd tried before and it didn't take off, but it's easy to do (via something like CafePress) and every little bit helps I suppose? On these notes, should there be - or has there been thought to - an official marketplace via the ProcessWire website for things like these (with a percentage going back to PW)? Pro Module Thoughts: 1. Search: I remember a mention of the front-end search functionality of the current version of the PW website potentially being packaged up into a Pro Module. What's the status on that? I think that - if it could be packaged into a pro module - it would be a fairly popular one. I realize that language issues would be a hurdle and there were strides made towards that endeavor such as with WireWordTools but don't know if the feasibility was broken down once multi-language was considered or if it's still able to be worked on and released. 2. Recurring Dates / RRule I too would have a use for this. Realistically, most businesses could if they want to attempt to accurately list their open hours when they celebrate holidays, as holidays have recurrence, and can have annoying recurrence (like the American Thanksgiving) which is the 4th Thursday of November. API-based things might have a need/want to integrate LazyCron into a non-standard recurrence. My personal usage would be for events - honestly I'm surprised the school websites Ryan's worked on haven't had a need for this. Reporting to Google for JSON-LD on its recurrence may also be helpful to have an API-level access to it as well (I'm not familiar enough to know for sure though). The largest difficulties in handling recurring events is exception management. There are usually two ways to generate recurrence - tie them to a single entry and assign a recurrence rule and extrapolate from that dynamically on call, or use the recurrence rule to generate the actual entries, individually (and usually have them tied to an original). How would exceptions be handled if a single date, or time, needed an adjustment? If one or more were cancelled? If one or more were to be added? If editing the primary edits them all, does it overwrite all others even if individual changes were made? Whether convention or configuration, these are just some potential issues with recurrence. ? Image Reference Field and/or Central Image Manager: It's certainly not necessary to a website being used, created, or maintained - but it would certainly be helpful if it was part of the core, whether optionally (in page settings) or statically (as a field/input setting). Teppo did a great job illustrating why: I'm essentially a technician (title is Web Administrator, but 85% of my job's time is help desk / support), professionally I'm a programmer/web developer, but the business I've worked for has 100+ people who are extremely varied in their technical expertise. 40 or so of them will be expected to have access to the administrative back-end for the primary website I'm (finally) redoing in one way or another, as they will be the content authors/maintainers (I work for a public library, so these are city-level librarians). They would not take the time to find a reference to an image already in the system when they could more easily just upload another completely brand new copy of the same image (let's say it's a 200MB file) multiple times, and resize it to a 240px width. I know that I could create a page that contained a "shared" image repository, or use one of the various modules, but the fact is that it can be very useful for various reasons. Layout Tool / Editor: From my own personal experience, I would agree with bernhard here. I think, based on the 5th time I've read through this topic, that it's been decided that Editor.js, specifically, is not a good fit, but continuing on... I'd done some testing of my own, like bernhard, and found limitations and issues with it. I'd also tried showing it to some basic-skilled coworkers with minimal (but enough) instruction and they struggled, hard. Showing them a CKeditor field (without instruction), however, they were able to do what they wanted and although were confused with certain things, weren't struggling. That said, from what I've seen of Bard and Editor.js, a similar approach can be managed using styling and JS adjustments with the RepeaterMatrix fieldtype, even if it's apparently overkill where storage needs come in. I do like that individual fields are still independently searchable within RepeaterMatrix though, which I think wouldn't be the case with an Editor.js fieldtype solution. How is RepeaterMatrix similar to Editor.js with style and JS changes? Robin S. and monollonom essentially had similar ideas - that the layout is different for Editorjs/Bard type fields, they're more compact and seemingly integrated. From the observation of the front-end GUI interface of Editor.js and Bard, it's doing something fairly similar to what RepeaterMatrix currently does - you create a new item (or start of a block of items) from a predetermined set of options. It's just that the interface of the other two has a different "wow" factor. Click a hoverable + button, choose from the available options, and then go about adding the related content. So if a fieldtype was created that's similar to RepeaterMatrix but stored data in a more efficient way, and was intended to be a more concise and (for lack of a better word) all-enclosed field, I would think using similar markup to RepeaterMatrix with a much more visually minified styling could help here. I'd love to understand more about how the $page-meta() can be used to integrate non-field stored data like bernhard was asking about, because that could be a way for developers to setup layout-like interfaces within custom-made template builders. Actual Page Builder - an Alternative: Fieldtype There are a few open source visual page builders for email templates (ex: GrapeJS). These are well-tested and I'm thinking that for the purposes of single page instances or landing pages, something like that could be used and created into a fieldtype of its own. Remove all of the markup from it afterSave to get only the text content, and place that content in a separate data field in the DB to make it searchable and it's now capable of being a standard page/template in PW. It would be up to the developer to place appropriate limits on it, but beyond that... Just a thought. I ♥ ProcessWire. (I also love all of the work that's been done since this topic was created, too!)

Nothing of your posted content looks like a PW installation. Are you sure you are in the right place here?

The answer's almost in your question! $s = $location->getUnformatted('location_message_start');

Hello @ all I want to share a new module with you, which makes the creation and validation of forms easy. Take a look at the following example of a simple contact form: // A very simple example of a contactform for demonstration purposes $form = new Form('contactform'); $gender = new Select('gender'); $gender->setLabel('Gender'); $gender->addOption('Mister', '0'); $gender->addOption('Miss', '1'); $form->add($gender); $surname = new InputText('surname'); $surname->setLabel('Surname'); $surname->setRule('required'); $form->add($surname); $name = new InputText('name'); $name->setLabel('Name'); $name->setRule('required'); $form->add($name); $email = new InputText('email'); $email->setLabel('E-Mail'); $email->setRule('required'); $form->add($email); $subject = new InputText('subject'); $subject->setLabel('Subject'); $subject->setRule('required'); $form->add($subject); $message = new Textarea('message'); $message->setLabel('Message'); $message->setRule('required'); $form->add($message); $privacy = new InputCheckbox('privacy'); $privacy->setLabel('I accept the privacy policy'); $privacy->setRule('required')->setCustomMessage('You have to accept our privacy policy'); $form->add($privacy); $button = new Button('submit'); $button->setAttribute('value', 'Send'); $form->add($button); if($form->isValid()){ print_r($form->getValues()); // do what you want } // render the form echo $form->render(); This piece of code creates a simple contact form and validates it according to the validation rules set. Inside the isValid() method you can run your code (fe sending an email) Highlights: 30+ validation types Support for UiKit 3 and Bootstrap 5 CSS framework SPAM protection Highly customizable Hookable methods for further customization Multi-language You can download and find really extensive information on how to use at https://github.com/juergenweb/FrontendForms. Please report errors or suggestions directly in GitHub. Best regards and happy testing ? If you have downloaded the module in the past I recommend you to uninstall the module completely and install the newest version 2.1.14. There are a lot of changes in the new version, so please test carefully.

Yes I noticed this as well, especially with respect to Python. I almost glossed over it thinking it was a Python-only tech ?.

@horst Like with matching a "parent=" or "has_parent=", it just sends the path to another $pages->get('...'); call to lookup the ID, so it should work with any path that $pages->get() would accept.

Hi @ryan, many thanks for the additions, especially the status one will be used by me! ? I want to ask if the support for matching children paths also works with multi language names, e.g. (/path/to/page/) resolves the same as the de path of the same page (/de/pfad/zur/seite/) ?

alright, i thought i would just zip everything at once. index.php <?PHP if(file_exists('config/config.php')) header('Location: login.php'); else header(''); ?> login.php start.php functions.php config.php <?PHP define ('DB_HOST', 'localhost'); define ('DB_USER', 'latentli_test'); define ('DB_PASS', '12345'); define ('DB_NAME', 'latentli_test'); ?> pepper.php <?PHP /** * Password pepper */ $pepper = 'pc?yACRCM='; ?> i really cant figure out why i cant fetch data from the online server while the same pieces of code are working well on localhost.

Hi Juergen, Thank you again for your very detailed and informative reply. It really made everything crystal clear. These days I am finishing a translation of language csv file in greek. Would you like to send it to you, so you can add it to the module language file? Do you believe it would be better if I send you a separate csv file only with the greek translation so you may just add the new column to your csv file? Have a nice day!

many ways... 1. use childpages instead of repeaters would be possible 2. repeater matrix (pro module) 3. pagetable module 4. editing the https://processwire.com/modules/fieldtype-events/ to your needs this is a example for repetable items in a small amount in a own fieldtype module ....this comes in the first minute of thinking about your question. processwire API code goes the same as for repeaters with different sources of the content (get childpages instead of repeateritems and so on)... kind regards mr-fan

Just want to point out that you can also do this with the new URL hooks https://processwire.com/blog/posts/pw-3.0.173/#introducing-url-path-hooks I can't test it now, but something like this should work (not tested!): $wire->addHook('/{building}', function($event) { $name = $event->sanitizer->pageName($event->arguments("building")); $building = $event->pages->findOne("parent=/buildings/, name=$name"); if($building->viewable()) return $building; });

There some usefull examples if you are in ML setup

The topic comes up regularly, so there's already a ton of information in the forum. If url segments for the building template aren't needed, this solution should cover the requirements:

Apologies for the delay folks. Here you go: Demo code for Using htmx to Refresh ProcessWire Frontend Content.

Sure... If you haven't read deeply into htmx, the main premise is that the server is the single source of truth regarding both data and markup, i.e. whole application state. If we need to update either data or markup, the server handles that. We just need to tell it what action to take. Validation has to pass, of course, before the server will oblige ?. Below is a quick example that demonstrates updating the markup using htmx based on user actions. Only 'remove' locations is demonstrated in this example. I wasn't sure whether your app shows the user both their removed and added locations and whether they can reset the session to have all locations reloaded afresh. It doesn't matter much as it wouldn't change much of the logic in the example. Secondly, note that this example makes use of alpine.js and tailwind css just for the pizzaz. These are not required by htmx. To let ProcessWire recognise htmx requests, please refer to this thread. Depending on the approach you take from there, you might not even need a JavaScript file! In the example below, we do have a JavaScript file just because we want to use alpine.js (for notifications) and we need htmx to talk to alpine.js. We also need the JavaScript file to tell htmx to add XMLHttpRequest to its request headers so that ProcessWire's $config->ajax will understand the request. First, let's see a demo then we'll see how easy our work is using htmx. Just for this demo, I have included htmx (and alpine.js and tailwind css via their respective CDNs [in production, you want to purge your tailwind css ?]) in my _main.php. Inside the template I am using for this demo, I have the following code. Here, I have removed the tailwind classes used in the demo so we can focus on htmx. Note that you don't need a dedicated template file for this to work. It will work with any template. As long as htmx is loaded in the page view and your template (in this case, the current page's template) is listening to ajax requests. In the template file, the main htmx magic happens here: <?php namespace ProcessWire; $out = "<a hx-post='./' hx-target='#locations' hx-vals='{\"location_add_id\": \"{$page->id}\"}' hx-include='._post_token' hx-indicator='#locations_spinner_indicator'>Add</a>" . "<a hx-post='./' hx-target='#locations' hx-vals='{\"location_remove_id\": \"{$page->id}\"}' hx-include='._post_token' hx-indicator='#locations_spinner_indicator'>Remove</a>"; echo $out; Let's go through the htmx attributes: hx-post This tells htmx where to send its ajax request. In this case, we are sending it to the same page we are viewing (./) and are using POST. We could have used hx-get if we wanted to (GET). hx-target This tells htmx which markup to replace/swap. The default is to replace the markup of the element from which htmx was called. However, hx-target can be used to specify the element to replace. In this example, we are replacing the whole listing so we target its wrapper element which has the id locations. hx-vals This is optional but we need it in our example. We want to tell the server which location (ID) has been added/removed. If we had a form element, we could have used it for this instead. Since we don't have one, we are telling htmx to process the (JSON) value of hx-vals and send that together with its request. Note: the escape slashes are so we can have raw, valid JSON in the attribute as required by htmx. hx-include This is also optional but important in our case. It tells htmx to include input elements found via the selector in this attribute in its ajax request. In our example, we are telling htmx to include the CSRF token we set on the server together with its request. hx-indicator Also optional. Tells htmx to show/hide this element to show the user that something happened. In this case we use a spinner. We could have used a progress indicator as well, .e.g., if we were uploading a file. That's it really! No event listeners, no handlers! We can add (and I did add one), event listeners on htmx events in order to do something after the event. In this example, htmx fires a custom event which alpine.js is listening to in order to show notifications after the DOM has settled. The notification type (success, error, etc) and the message are all coming back from the server but not as JSON. The markup to update the page is also coming back from the server. htmx receives it and plugs it into the DOM per the hx-target (also see hx-swap) attribute value. In this example, we are updating the whole listing. If we wanted, we could update just the location that was removed, e.g. add it back but with some removed 'indicator', e.g. greyed-out. In this example we use anchor tags as htmx triggers. For htmx, it doesn't matter; button, div, p, li, whatever valid HTML element would work. You already have a backend logic that's working for you but I show an excerpt of mine here, for completeness. Inside my-template-file.php (the template file for the template for the current page, in this example), I have the following code: <?php namespace ProcessWire; if ($config->ajax) { // check CSRF if (!$session->CSRF->hasValidToken()) { // form submission is NOT valid throw new WireException('CSRF check failed!'); } // ................ more code // e.g. check removed locations in the session, etc // get previously removed locations (keeping things in sync) $removedLocations = $session->get('removedLocations'); // REMOVING LOCATION if ((int) $input->post->location_remove_id) { $mode = 'remove'; $notice = "Removed"; $id = (int) $input->post->location_remove_id; } else if ((int) $input->post->location_add_id) { // ADDING LOCATION $mode = 'add'; $notice = 'Added'; $id = (int) $input->post->location_add_id; } // ................ more code // e.g. check if we really have a page by that id, SET $noticeType, $options and update session 'removedLocations' etc // build final content //----------- // @note: buildLocationsCards() is a function that does what it says on the tin. We use it in both the ajax response here and also below, in non-ajax content, when the page loads // the $options array contains a key 'skip_pages_ids' with an array of IDs of locations (pages) that have been removed in this session. We skip these in buildLocationCards(). $out = buildLocationCards($page, $options); // @note - here we always return one input only // we use the values in this input in JS to pass event details to alpine.js to show the correct notification and the notification message. $out .= "<input type='hidden' id='location_notice' name='location_notice' data-notice-type='{$noticeType}' value='{$notice}'>"; echo $out; $this->halt(); } // NON-AJAX CONTENT BELOW.... That's all there is to it ?. I am happy to share the full code if anyone wants to play with this further.

Just throwing in htmx as an alternative here. If you are interested, I could put together a rough example.

The other great thing about it is that it's a very realistic thing we can do. Though Jonathan's video pointed out a lot of drawbacks. Maybe we can solve some of them with upgrades to RepeaterMatrix like Jonathan proposed, and maybe others are acceptable drawbacks given our context is very different from tools like WordPress. Plus, it seems like Jonathan is already using this approach successfully with clients. I took a closer look at https://editorjs.io/ and I like it for a lot of the same reasons I liked what The Bard example was showing. The plugin-based approach for blocks it uses looks great and this seems like something we could probably integrate pretty easily/quickly since it's based off an existing tool that handles the difficult-to-code parts. Being able to solve this need with an existing tool like this is the ideal route IMO. While cool no doubt, this is where I get into more of a grey area as to whether ProcessWire should be involved in this sort of thing at all. It just seems it steps maybe too much outside the scope of content management. Yes, this makes sense. This is what I liked about that editor.js option, as it seems like (combined with its plugins) it's already a clean system for doing this. Interested to hear of others think this approach would be a good path to take. I'm already a fan of Unpoly after spending a lot of time looking at it, particularly with how lightweight it is relative to what it does. There isn't anything hard coded in it. The top area is a CKE and images field, and images use tags to place in groups. The next part is list of features/highlights, each with headline, icon, description, and link; these are a FieldtypeTable field. Another FieldtypeTable field manages quotes (quote, cite, source, active), which are pulled randomly in different parts of the page, as well as on other pages in the site (which pull from the same field). Everything else on the page is pulled in dynamically from other parts of the site. For instance, the blog part always shows the newest blog posts, the showcase part always shows the newest site additions, the Pro modules part pulls from the /store/, etc. So there isn't really much code on the actual homepage template, since it's actually the other parts of the site rendering each of those. I agree, I will add this. Yes, that has been my experience as well and so this was one of the things ProcessWire has always tried to solve from the beginning. Keep the client focused on semantic content and not on style, layout or presentation. It's also why I've never been a fan of front-end editing. As soon as the person editing content takes their focus off of meaning and shifts to presentation, that's where things go south and content is no longer portable. I see a fundamental job of a CMS being to manage portable content. With all that said, it does seem like there is an exception to the above (per what Jonathan mentioned earlier). That is, the perhaps temporary 1-page marketing things, where questions of portability don't really matter and the short term marketing needs do. This is already built into FieldtypeFloat, so another good reason for it to add DECIMAL column support. Well in this case, we would add the support to the core, so one wouldn't need to use Combo for that purpose. A number spinner is built into the HTML5 number type, which is already an option for the float field. What's lacking is the ability to modify the step value from the default. I can add that, no problem. @Robin S I've been experimenting with your Uikit admin CSS additions and a few of them (some of the "fix" ones) seem like they should be added to the core. Some of the other more subjective ones, you've got me thinking we should have a "customization presets" dropdown in the Uikit admin that lets you select predefined customization sets like yours. I think having separate configuration settings for all the different things you've changed is probably too much configuration, but presets seems like a good way to answer common preferences people might have?