PW 3.0.170 – Core updates

[Kiwi Chris]

7 hours ago, adrian said:

The other big thing for me is finding ways to make certain data queries more performant, perhaps with something like @bernhard's Rockfinder functionality built into the core so that we can pull large amounts of field data in a more performant way - we don't always need all the info contained in the PW objects that are returned by regular API queries. Honestly I haven't yet used Rockfinder in production - I've actually gone with custom SQL queries of PW field data to build up objects/arrays exactly as I need them, but some inbuilt methods for automating this (like Rockfinder does so well) would be nice.

I'd say this is a biggie. During lockdown here in NZ (thankfully long over), I had the need to move various client databases to the cloud, and started looking at a headless CMS, Directus, because ProcessWire doesn't let you easily hook up an SQL database, leaving the SQL structures alone and just give you an admin UI and API, and yet looking at what Directus does and what ProcessWire does, I can't see why ProcessWire couldn't be made simple to connect to an existing SQL backend. Input Fields work with a wide range of data, and there are already ProFields like Table and Combo that connect to an SQL table behind the scenes, so maybe having a fieldtype (maybe a pro field?) that can connect to any SQL table would be quite handy. That would make connecting to existing apps that have been built outside of ProcessWire straightforward, and also make migrating data simple if it does make sense to pull it into the ProcessWire way of doing fields, as the external data can be accessed via the API.

ProcessWire already has a fields table that contains the definitions for how each field should be managed in the backend, and I guess it should be possible to do something similar linking an existing SQL table, where it is possible to specify any inputfield parameters for each table field, while leaving the actual SQL table alone.

I can see a down side, in that some people who are used to SQL tables, and don't quite understand the ProcessWire way might be inclined to use SQL tables for everything when the ProcessWire way of one table per field actually has advantages depending on the data, but if it makes migration easier, and sticks with ProcessWire's philosophy of trying to keep out of your way and not dictate how you work with your data, then perhaps it could be useful?

[adrian]

1 hour ago, Kiwi Chris said:

maybe having a fieldtype (maybe a pro field?) that can connect to any SQL table would be quite handy.

For this need you should be able to import data from an existing SQL table into a Profields Table pretty easily - either via CSV with the Table CSV Import/Export module, or even with SQL. The other option might be to build a custom fieldtype that utilizes something like http://tabulator.info/ to connect directly to your existing table and manage its content that way. Would that be useful for your needs?

[ryan]

Quote

I'm pretty happy with AdminThemeUikit and don't think it looks dated. 

Good, yeah I’m happy with it too. But I’m just thinking having a regularly updated fresh look would be helpful for attracting new users. It wouldn’t be at the expense of keeping a solid utilitarian theme for when more serious work needs to get done.

Quote

…but these things are very simple to fix with custom CSS overrides.  

Sounds good. If that’s the case, maybe a good place to start would be for some of the skilled designers in the community to propose some tweaks to what we already have. 

Quote

 I wouldn't want to see the admin styling change every year and I can't relate to the desire to be endlessly changing the admin to keep up with the latest fads.

I personally would like to see something fresh on a regular basis, but again, not at the expense of also having something solid and consistent. PW supports multiple admin themes for many reasons. 

Quote

1. Maybe there could be more config fields in AdminThemeUikit to let people adjust things like spacing and font size without having to add their own stylesheet to the admin.

Sounds like a good idea. I wouldn’t know where to start with deciding what specifically is adjustable in this way, but I could certainly make it happen on the configuration side.

Quote

2. It would be pretty good if developers could more easily create modules that extend AdminThemeUikit so if they want a customised admin theme they only have to override certain specific methods rather than completely duplicating the module. Right now if you do...

I was not aware that AdminThemeUikit couldn’t be extended. It was intended to be extendable. Most likely there’s a simple fix. I will correct that. 

Quote

And it would be good if there were more hookable methods in AdminThemeUikit so that it becomes possible to manipulate the main menus for instance.

It’s already quite hookable. But if you can tell me more specifically what additional methods you’d like to be hookable, I should be able to do it. 

Quote

The biggest benefits I see in a built-in API, even one that is disabled by default, would be that a) modules and other shared code can build on it since developers know that it'll be there and know how to operate it

Can you give an example use case? In ProcessWire, all modules already have access to the internal API, which is always going to be more powerful than an external one could ever be.  So I’m not sure I understand yet how shared code like modules would benefit in this case.

Quote

having a built-in API does sound better from a marketing perspective than "you can install it as a plugin/module". And it does give it some legitimacy too

So far as I understand it, this seems like it’s the primary benefit in the PW context. 

Quote

but the gist was that perhaps PW would be a bit more "competitive" if the admin was easier for new users to grasp,

I think there’s likely a distinction between new users that are used to some other platform, and new users that haven’t spent a lot of time in other CMSs. In my experience, users new to CMSs (rather than just new to ProcessWire) figure it out very quickly, with little or no guidance. Whereas users used to something else (WordPress, etc.) encounter something entirely different, and everyone inherently prefers what’s familiar. But users are going to increasingly be "used to" something or another, and more likely WordPress than not. 

Quote

 …the vast majority (at least half, but perhaps as much as two thirds) of potential clients have started with the demand that the project has to be built with a "popular" system (which usually really means WP).

That used to be the case around here too. But today I’m finding more seem to be aware of the downsides of WordPress and the liability it brings. It’s seen as a target and a risk with baggage. At least if there isn't someone keeping an eye on it and taking care of it; so it's a responsibility, which means it's also a cost. But the fact that you can run any version of ProcessWire (even a 10 year old version), without worry, it says a lot. Meanwhile, ProcessWire has been powering websites for as long as WordPress has. But it’s been doing so without the risk and drama. Like I say, PW’s record speaks for itself, as does WP’s. Given a choice of popularity or long term security (which is what it comes down to), I leave that for the client to decide what's in their best interest. 

Quote

What they do care is a) whether they can put their trust (and money) behind a less known platform

ProcessWire may have been a new player or unknown factor at one time, but that was a long time ago. Not only is it open source, but ProcessWire has more than a 10-year track record in open source, and a 17 year development record in total. It is used by tens of thousands of websites by thousands of web developers worldwide. It has been in active development the entire time. There is nothing proprietary about it (open source and PHP). It is well documented. It is coded in a manner that makes it accessible to any competent PHP developer. It is both developer and community supported. And when it comes to things going wrong, it’s far less likely to happen in ProcessWire in the first place. Other projects come and go. I think it's safe to say ProcessWire has been, is now, and will continue to be one of the most stable players in this space. 

Quote

…but the good thing about accepting them is that they do affect our numbers, and again that can be an important factor for getting new developers (and clients!) interested.

Yes, again for appearances. But there's not much downside here. I’ll try to give this some more focus. 

Quote

I actually like the way that @dg from Nette handles this - he uses the "adrianbj authored and dg committed" approach which I highlighted once before - this allows the committer to make changes to the commit, while still having the author recognized as the contributor.

How does that work? Is it anything other than dg just committing code from adrianbj (same as a copy/paste), or does it have something more technical going on with regard to the merge?

[szabesz]

23 hours ago, Robin S said:

I'm pretty happy with AdminThemeUikit and don't think it looks dated. I've said before that there's too much padding between and around elements and the main page heading is way too huge (maybe this is where the "cartoonish" criticism comes from), but these things are very simple to fix with custom CSS overrides. I wouldn't want to see the admin styling change every year and I can't relate to the desire to be endlessly changing the admin to keep up with the latest fads. The admin is a place you go to do work, not to see pretty things. It should be plain and utilitarian, which AdminThemeUikit already is.

A BIG +1 from me ?

[Robin S]

1 hour ago, ryan said:

If that’s the case, maybe a good place to start would be for some of the skilled designers in the community to propose some tweaks to what we already have. 

Below are the style overrides that I apply, mostly just spacing changes and fixes for things that looked off to me. There might be one or two things in there that don't make sense out of context because I'm also loading some custom JS to change the icon of the "user" menu and have the primary link be to the site frontend rather than the user profile.

Spoiler

/* Form elements */
input, textarea, select, button { font-family:-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,"Helvetica Neue",Arial,sans-serif; }
.uk-input, .uk-select:not([multiple]):not([size]) { height:35px; }
.Inputfield input[type=date]:not(.uk-input), .Inputfield input[type=datetime]:not(.uk-input), .Inputfield input[type=email]:not(.uk-input), .Inputfield input[type=number]:not(.uk-input), .Inputfield input[type=text]:not(.uk-input), .Inputfield input[type=url]:not(.uk-input) { height:35px; }
.Inputfield .selectize-input input:not(.uk-input) { height:auto; } /* File/Image tags */
.Inputfields select.uk-select:not(.uk-form-blank) { border-radius:0; }

/* Notices */
.uk-alert { padding-top:10px; padding-bottom:10px; }
.pw-notices .NoticeMessage { border-color:rgba(0,0,0,0.08); }

/* Masthead search */
#pw-masthead .pw-search-form .pw-search-input { border-color:#3a4e6a; background:#3a4e6a; }
#pw-masthead .pw-search-form .pw-search-input:focus { border-color:#557093; background:#3a4e6a; }
#pw-masthead .pw-search-form .uk-form-icon { color:#bfc5d1; }

/* Headings (less huge - same as before Uikit rc17) */
.uk-h1, h1 { font-size:2rem; }
.uk-h2, h2 { font-size:1.5rem; }

/* Inputfield header/content */
.InputfieldHeader { padding:15px 5px 8px 15px; }
.InputfieldStateCollapsed > .InputfieldHeader { padding-bottom:15px; }
.InputfieldContent { padding:1px 15px 18px 15px; }

/* Field/template import/export buttons */
#import_button { margin-right:0; }

/* Buttons */
.ui-button, .ui-button.ui-state-default, .ui-button.ui-state-hover { padding-left:20px; padding-right:20px; text-transform:none; transition:none; }

/* Select */
/* Disabled options */
option:disabled { color:#aaa; }
/* Auto width on desktop, 100% width on mobile  */
.Inputfield.InputfieldColumnWidth>.InputfieldContent .uk-select:not(.InputfieldSetWidth) { width:auto; }
@media screen and (max-width:767px) {
	.uk-select { width:100% !important; }
}

/* AsmSelect (including in Table field) */
span.asmListItemLabel, span.asmListItemStatus, span.asmListItemDesc { padding-top:1px; padding-bottom:1px; font-size:16px; }
.Inputfields .InputfieldAsmSelect .asmListItem .asmListItemHandle, .Inputfields .InputfieldTable .asmListItem .asmListItemHandle { top:5px; }
.Inputfields .InputfieldAsmSelect .asmListItem .asmListItemRemove i { top:1px; }
.Inputfield.InputfieldTable .asmListItem { line-height:1.5; }

/* Page Autocomplete */
.pw-content .InputfieldPageAutocomplete ol li i.fa-sort { top:7px; }

/* Page list */
.PageList .PageListItem .PageListNumChildren { padding-right:6px; }
.PageList .PageListItem .PageListNumChildren:empty { padding-right:0; }
.PageList .PageListActions a, .PageList .PageListMoveNote a, .PageList .PageListerActions a { background-color:#3eb998; }
.PageList .PageListActions a:hover, .PageList .PageListMoveNote a:hover, .PageList .PageListerActions a:hover { background-color:#e83561; }

/* Dropdown menus */
.ui-menu .ui-menu-item .ui-menu.navJSON .ui-menu-item:not(.add):not(.highlight) a { padding-top:2px; padding-bottom:2px; }

/* Tables */
.uk-table-small td, .uk-table-small th { padding-top:8px; padding-bottom:8px; }

/* Fieldsets */
.InputfieldFieldset > .InputfieldHeader { background:linear-gradient(#fbfcfe,#f0f3f7); }
.Inputfield.InputfieldStateCollapsed>.InputfieldHeader:hover { background:#fff; }

/* Breadcrumb */
.uk-breadcrumb .pw-panel { margin-right:-7px; }
.uk-breadcrumb>:nth-child(n+2):not(.uk-first-column)::before { content:"\f105"; font-family:'FontAwesome',sans-serif; }

/* Admin search */
.pw-search-form .pw-search-icon { position:relative; top:-1px; }
.ui-autocomplete { padding-top:0; padding-bottom:12px;}
.ui-autocomplete .ui-menu-item a { padding-top:2px; padding-bottom:2px;  }
.ui-autocomplete .uk-nav-header { border-bottom:1px solid #e5e5e5; margin-bottom:8px; margin-top:10px; }
.ui-autocomplete .uk-nav-divider { display:none; }

/* Tools (user) menu */
#tools-toggle .pw-nav-icon { position:relative; top:-1px; }

/* Login page */
.ProcessLogin .uk-text-center, .ProcessLogin .pw-notices .uk-container { text-align:left !important; }
.ProcessLogin #ProcessLoginForm { margin-left:0; margin-right:0; }
.ProcessLogin #pw-content-body { text-align:left !important; max-width:900px; }
.ProcessLogin #ProcessLoginForm #wrap_Inputfield_login_submit { margin-left:0 !important; margin-right:0 !important; }
.ProcessLogin #ProcessLoginForm #wrap_Inputfield_login_submit input, .ProcessLogin #ProcessLoginForm #wrap_login_name input, .ProcessLogin #ProcessLoginForm #wrap_login_pass input { text-align:left; }
.ProcessLogin #ProcessLoginForm #wrap_login_name .InputfieldContent, .ProcessLogin #ProcessLoginForm #wrap_login_pass .InputfieldContent { padding-left:0; padding-right:0; }
.ProcessLogin #ProcessLoginForm #wrap_Inputfield_login_submit { margin-top:7px !important; }

/* ProcessPageEdit view dropdown */
#_ProcessPageEditViewDropdown { transform:translateX(5px); }

/* Lister */
#ProcessListerTable > .pw-table-responsive { margin-top:0; }
.PageList .ProcessListerTable tr.open { background:#f0f3f7; }
/* Hide Lister button links at bottom when results are empty */
#ProcessListerResults:empty + .InputfieldButtonLink { display:none; }

/* Lister Pro*/
a + #save_edits { margin-left:10px; }

/* InputfieldIsOffset - fix layout in Profields Table config */
.Inputfields .InputfieldIsOffset:not(.InputfieldColumnWidth) { margin-top:18px; margin-bottom:18px; }
.Inputfields .InputfieldIsOffset:not(.InputfieldColumnWidth).InputfieldRowFirst:not(.WireTab) { margin-top:16px; }
.Inputfields .InputfieldIsOffset:not(.InputfieldColumnWidth).InputfieldRowLast:not(.WireTab) { margin-bottom:0; }

/* Profields Table */
.Inputfield.InputfieldTable table.InputfieldTable .InputfieldTableActionSort i { top:5px; }
.Inputfield.InputfieldTable table.InputfieldTable .InputfieldTableActionDelete i { top:5px; }
.Inputfield.InputfieldTable table.InputfieldTable textarea { padding-top:5px; } /* align with text input */

/* Profields Multiplier */
.InputfieldMultiplierSortHandle, .InputfieldMultiplierTrash { width:1%; padding:0.5em 0 !important; }

/* AdminOnSteroids mods */
.PageListItem em:not(:empty):before { padding:0 7px 0 3px; }

/* Admin dropdown menus - remove unnecessary border */
#pw-masthead .uk-navbar-nav > li.uk-active>a:after, #pw-masthead .uk-navbar-nav > li > a.hover:after, #pw-masthead .uk-navbar-nav > li > a:hover:after { border-width:0 5px 6px 5px; bottom:0; }
ul.pw-dropdown-menu, ul.ui-menu, ul.pw-dropdown-menu > li.ui-menu-item > ul.ui-menu, ul.ui-menu > li.ui-menu-item > ul.ui-menu { border:none !important; }

/* Prevent FOUC for WireTabs content */
.WireTabs + .Inputfields > .InputfieldWrapper { display:none; }

/* Improve rendering of PageList icons */
.PageList i.icon { width:18px !important; }

/* Menu icon collision and wonky spinner */
/* https://github.com/processwire/processwire-issues/issues/764 */
/* https://github.com/processwire/processwire-issues/issues/874 */
.ui-menu .ui-menu-item a { padding-right:28px; }
.ui-menu .pw-has-items-icon { position:absolute; right:7px; }
.ui-menu .ui-menu-item a i.fa.fa-spinner { right:3px; }

/* Prevent image thumbnail overflow */
.InputfieldImage:not(.InputfieldStateCollapsed)>.InputfieldContent .gridImage { max-width:100%; overflow:hidden; }

 

 

1 hour ago, ryan said:

I was not aware that AdminThemeUikit couldn’t be extended. It was intended to be extendable. Most likely there’s a simple fix. I will correct that.

The problem is that if you create the minimal module that extends AdminThemeUikit (i.e. just the class declaration and the getModuleInfo method) then what you want to see is everything displaying as per AdminThemeUikit. Then you would add custom CSS/JS and override any AdminThemeUikit/AdminThemeFramework methods as needed. But what you actually see is this:

If that is expected then it would be helpful to have some documentation or a blog post about how to go about extending AdminThemeUikit, or what file structure is needed for a full custom admin theme if anybody is game enough to try that.

1 hour ago, ryan said:

It’s already quite hookable.

The only hookable methods that I can see are AdminThemeUikit:renderBreadcrumbs and AdminThemeFramework::getUserNavArray. So for the thing I mentioned (manipulating menus) you can only customise the "user" menu. It's not possible to dynamically add items to the Pages, Setup, Modules or Access menus without resorting to JS hacks like AdminOnSteroids does. And on the topic of the admin menus, the caching is a bit of a pain and doesn't measurably improve performance according to my tests: https://github.com/processwire/processwire-requests/issues/268#issuecomment-464200684

Another menu related request: https://github.com/processwire/processwire-requests/issues/189

What would be great is if for each major part of the admin theme layout (e.g. header, menus, top of content, bottom of content, footer) there was some hookable method so it was possible to inject custom markup at those points.

[Kiwi Chris]

18 hours ago, adrian said:

For this need you should be able to import data from an existing SQL table into a Profields Table pretty easily - either via CSV with the Table CSV Import/Export module, or even with SQL. The other option might be to build a custom fieldtype that utilizes something like http://tabulator.info/ to connect directly to your existing table and manage its content that way. Would that be useful for your needs?

Tabulator looks interesting, although sometimes I want forms, not tables for data input. The trouble with Profields Table is it seems to be geared around having multiple records in a row format per page. If I understand it correctly, the new combo fieldtype stores things in sql fields in a table in the database, but gives more flexibility around layout, and is a single record per page, so this is much closer to what I want, and may be what tips the balance in terms of me buying the ProFields package. A question though is whether this is actually creating separate fields in the database table, or doing what custom image fields does, and just storing a JSON object in a single field. From an SQL perspective, having separate fields and being able to do sorting and grouping at the SQL level would be more convenient than doing it at the PHP level. 

I would like the option that I raised elsewhere around ordinary field types, of being able to choose whether to index subfields or not, as some will only ever be retrieved based on selecting on other fields.

I guess I should bite the bullet and try building my own custom fieldtypes. I'm at the point I'm comfortable building simple Process admin modules thanks to @bernhard and his excellent tutorial on building custom admin modules, however I think a good tutorial on building custom data driven fieldtypes or custom admin data access modules might be helpful, and it might actually be as useful as adding more features to ProcessWire itself, as with all the various inputfields and Process modules, possibly everything I need is already there for custom SQL data, just I need to join the dots.

[adrian]

@Kiwi Chris - sorry, I didn't initially understand what you were looking to do. It sounds to me like the new Combo field is exactly what you are looking for. It dynamically adds/removes actual DB table fields as you modify the combo field's subfields, so it allows you to sort, group, query like you would with any regular SQL DB table. It is not at all like the custom file/image fields which are stored as JSON. 

[adrian]

8 hours ago, ryan said:

How does that work? Is it anything other than dg just committing code from adrianbj (same as a copy/paste), or does it have something more technical going on with regard to the merge?

I believe it's a technical step in the merge process. It's interesting because 4 years ago I posted a message to you (I'll PM you about it in a minute) about this and back then Github used this phrasing: 
"adrianbj committed with dg" but if I look at the commit I referenced back then, it has now been reworded as "adrianbj authored and dg committed" so it's the same technique, just differently named.

I think this SO answer is helpful in explaining the ways this can happen when editing someone PR: https://stackoverflow.com/a/25327781/1524576 

[Ivan Gretsky]

Regarding the ability to modify the admin theme... Look at Admin Theme Boss (the only custom admin theme I have ever seen used for PW3) thread, and at this particular post to start with. @Noel Bossis probably the man to talk about making extending Admin Theme Uikit a better experience. As well as @bernhardwith his RockSkinUikit and @tpr, who knows the admin inside out making his AdminOnSteroids. And @Robin S is already here, of course)

[Ivan Gretsky]

I see there is a number of topics that are actively discussed in this thread. Maybe we could make a subforum with the selected 2021 roadmap features to be discussed with dedicated working groups? Not to loose the momentum we got here in this thread) And to nurture that community participation in the future of our beloved ProcessWire.

I see these:

1. A strategy/fieldtype for creating rich content.
2. Making admin themes be extendable and/or adding features to them like a sidebar (might be it could be accomplished as an extension?)
3. External API / using PW as a headless system out of the box.
4. Central media/image manager for reusing images across pages 
5. Support for different file storages for image like Flysystem
6. Growing popularity of PW (without sacrificing stability of course). Showing github contributions and such.
7. Implementing admin forms in the frontend / making a limited admin for non superusers (pushing this as I am personally interested))
8. ...seven is a great number to deal with, but certainly there could be more)))

[szabesz]

At least the most popular requests should be reconsidered I think, such as:
https://github.com/processwire/processwire-requests/issues/126

It is hard to build ecommecre solution without adequate precisions of numbers. In countries like Hungary, a price of 1000000.00+ is quite common. The limit of 9999.99 is _always_ an issue.

[cb2004]

Some great discussions going on here, I literally don't know where to start with the likes, quoting and commenting.

For me, I have always understood that ProcessWire has been largely for Ryan and his clients, but the massive feature set has always worked for my needs (and many more peoples needs). Luckily for me when I have been looking to do certain things it has always popped up in the core a month or so later and the pro modules help me achieve what I need to with ease (albeit it in a different way to other systems*).

The simple fact is, other systems* have file managers and other systems* now have their own take on content builders. Most clients have a previous system* which will definitely have a file manager, and clients will soon be asking for content builders. Yes I can use a module for the files and repeater matrix for content builders, but as Ryan said surely we already have a great starting foundation for these 2 features to break out into something awesome. Whilst a ProcessWire version doesn't have to be exactly the same and I have no doubt that less will be more compared to the theme monster that is WordPress, I think without them I am going to find it increasingly difficult to sway bigger clients decisions when their staff are managing the updates and have used other systems*.

* I tried not to spray WordPress all over my post, but being in the UK, this is what a huge percentage of people have heard of, use, and I migrate them over from. And of course they love the end product, but I do think a file manager and content builder are the 2 things I need for my sales process going into 2021.

[teppo]

16 hours ago, ryan said:

Can you give an example use case? In ProcessWire, all modules already have access to the internal API, which is always going to be more powerful than an external one could ever be.  So I’m not sure I understand yet how shared code like modules would benefit in this case.

Two distinct points of view:

• Majority of the sites I work with require some sort of public API. This may be for local JavaScript, or perhaps I need to expose (as raw data or pre-rendered views) content to an external service. With this in mind I've been working on a built-in API for the Wireframe module and I've also got something similar planned for SearchEngine.

In WordPress, plugins can inject their own custom endpoints to the global REST API. That in turn makes it easier to integrate with existing core or third party features (authentication and whatnot), things are more straightforward for plugin authors (no need to reinvent the wheel), and it's also easier for API consumers (familiar interface).

Perhaps worth noting that this is not actually limited to front-end: it can also facilitate behind the scenes plugin-to-plugin integrations quite nicely.

• Let's say that I want to distribute a module that is focused on front-end features. Currently it would need to provide both back and front-end, since there's no public API I can tap into. SearchEngine might be one example of this: if there was a public API, I might be able to use that instead of implementing one of my own.

I could list other examples, but the gist is that any front-end feature that needs to talk to the backend might benefit of this. If there was a public API (and by public I mean something accessible to, say, JavaScript) one could essentially develop front-end features, bundle them in a module or distribute in other ways, and then integrate them with ProcessWire without a need for a purpose built custom backend.

In a way this would create a whole new market / open ProcessWire up for a new type of audience.

16 hours ago, ryan said:

I think there’s likely a distinction between new users that are used to some other platform, and new users that haven’t spent a lot of time in other CMSs. In my experience, users new to CMSs (rather than just new to ProcessWire) figure it out very quickly, with little or no guidance. Whereas users used to something else (WordPress, etc.) encounter something entirely different, and everyone inherently prefers what’s familiar. But users are going to increasingly be "used to" something or another, and more likely WordPress than not. 

Agreed, my experience is similar. New users tend to find ProcessWire very easy to use (certain differences in personal preferences aside), while much of the feedback regarding things like not having a sidebar seems to come from users with experience from other systems.

16 hours ago, ryan said:

That used to be the case around here too. But today I’m finding more seem to be aware of the downsides of WordPress and the liability it brings.

[...]

ProcessWire may have been a new player or unknown factor at one time, but that was a long time ago.

Perhaps you're further down the adoption curve? One can always hope ?

A few years ago it was easier to convince clients to try other platforms, today it's common for WP to be not just a strong recommendation but actually a strict requirement. I guess it boils down to the idea that if you're not an expert and have to make a decision about which offer to accept, the popular system is a safe bet. Also if you're requesting quotes and 4/5 recommend platform X, it does make one wonder if the majority could really be wrong.

16 hours ago, ryan said:

Yes, again for appearances. But there's not much downside here. I’ll try to give this some more focus. 

Thanks ?

[ryan]

@Robin S I've pushed an update to the dev branch that makes it simpler to extend AdminThemeUikit. As far as I can tell, the reason you got the result you got before is because your admin theme was likely missing all of the other files that go along with an admin theme (?). So the reason you can't just extend AdminThemeUikit and be done with it, is because the module file is only one part of the admin theme. I've updated it so that AdminThemeUikit is now built expending that you might extend the class, without all the other files. So now you can create an AdminThemeUikit derived module like this:

File: /site/modules/AdminThemeTest/AdminThemeTest.module

<?php namespace ProcessWire;
class AdminThemeTest extends AdminThemeUikit {
  public static function getModuleInfo() {
    return array(
      'title' => 'Test Admin',
      'version' => 1,
      'summary' => 'Test extending Uikit admin theme',
      'autoload' => 'template=admin', 
      'requires' => 'AdminThemeUikit',
    );
  }
}

You'll also need this file in the same directory:

File: /site/modules/AdminThemeTest/controller.php

<?php namespace ProcessWire;
if(!defined("PROCESSWIRE")) die();
require($config->paths->core . "admin.php");

The above would just be the same thing as AdminThemeUikit. But at that point, you can easily override and extend anything from the AdminTheme, AdminThemeFramework or AdminThemeUikit class. For instance, here the same module as above, but I'm extending the renderExtraMarkup() method to add some more markup to <head> to make the primary headline <h1> smaller (not suggesting this would be the right way to apply CSS though):

<?php namespace ProcessWire;
class AdminThemeTest extends AdminThemeUikit {
  public static function getModuleInfo() {
    return array(
      'title' => 'Test Admin',
      'version' => 1,
      'summary' => 'Test extending Uikit admin theme',
      'autoload' => 'template=admin', 
      'requires' => 'AdminThemeUikit',
    );
  }
  public function renderExtraMarkup($for) {
    $out = parent::renderExtraMarkup($for);
    if($for === 'head') {
      $out .= 
        "<style type='text/css'>" .
          "#pw-content-head h1 { font-size: 24px }" .
        "</style>";
    }
    return $out;
  }
}

 

[ryan]

@szabesz Isn't there already a decimal fieldtype available? I thought there was already a solution for that need, though I've never had the need for a decimal fieldtype so I've not tried it and don't know if it's lacking anything. I guess I figure the ideal situation for something like this is if it's developed by someone that also uses it. But if there's not one available, or what's available is lacking in some way, or not maintained, etc., then I could look into it. Or maybe FieldtypeFloat could be updated to support either decimal or float column type (like FieldtypeCombo). 

[Jonathan Lahijani]

1 hour ago, ryan said:

@szabesz Isn't there already a decimal fieldtype available? I thought there was already a solution for that need, though I've never had the need for a decimal fieldtype so I've not tried it and don't know if it's lacking anything. I guess I figure the ideal situation for something like this is if it's developed by someone that also uses it. But if there's not one available, or what's available is lacking in some way, or not maintained, etc., then I could look into it. Or maybe FieldtypeFloat could be updated to support either decimal or float column type (like FieldtypeCombo). 

The decimal fieldtype is available and works well (I use it for an ecommerce site with large numbers, no problems):

However it would be nice if this was in the core:
https://github.com/processwire/processwire-requests/issues/126

FieldTypeTable supports decimals by the way.

[zoeck]

2 hours ago, ryan said:

 Or maybe FieldtypeFloat could be updated to support either decimal or float column type (like FieldtypeCombo). 

I think that would be really cool ? 

In my opinion, the page overview should be revised.

The edit, move etc. buttons should always be displayed. Buttons should always be displayed. So you can call the function faster.
Possibly a table view would be nicer here...

[adrian]

10 minutes ago, zoeck said:

The edit, move etc. buttons should always be displayed. Buttons should always be displayed. So you can call the function faster.

Not trying to diminish your request for this to be in the core, but just an FYI that AdminOnSteroids supports this. The other thing it supports which is pretty much the main reason I use it is so that the buttons show on full row hover - I can't stand using the admin without that feature - it reduces mouse movement but so much ?

[adrian]

3 hours ago, ryan said:

I've pushed an update to the dev branch that makes it simpler to extend AdminThemeUikit.

Thanks Ryan - this sounds like exactly what we need - it would be great if authors of all alternate theme modules could update to use this approach - currently they are all subject to getting behind the core themes in terms of functionality. I wonder though if perhaps it's time to set up a "base" theme that handles all the basic functionality / layout of the admin and have Uikit extend that. Of course the default theme and Reno could also be modified to extend it, although I expect doing that would be a waste of effort as I think most people are using the Uikit theme. Regardless, I do think it's time it became the default theme way one or another.

[szabesz]

4 hours ago, ryan said:

Or maybe FieldtypeFloat could be updated to support either decimal or float column type (like FieldtypeCombo). 

That would be awesome.

Quote

I guess I figure the ideal situation for something like this is if it's developed by someone that also uses it.

The one who developed that module has been away for more that two years. @arjen stated that he is happy to maintain his fork but it is not an ideal situation that I always have to point people to Arjens's fork instead of the no longer maintained module in the Directory.

Anyway, it is a common need and as far as I know the core concept is that ProcessWire should support features most of us need. I think this is such a thing, based on the popularity of my request: https://github.com/processwire/processwire-requests/issues/126 where there is already a discussion in which others explain why they think it should be part of ProcessWire.

[Jonathan Lahijani]

In this video, I demonstrate YOOtheme Pro's Builder (WordPress) and talk about its approach and benefits.  I then demonstrate 3 different builder concepts in ProcessWire using Repeater/RepeaterMatrix, two of which are modeled after YOOtheme Pro's builder and their limitations along with some suggestions. ( @ryan )

(note: there are many more considerations when it comes to a page builder, but if there were some sort of css-framework agnostic layout tool, that would solve the biggest page builder problem)

Please share your thoughts.

 

[kongondo]

9 hours ago, Jonathan Lahijani said:

In this video, I demonstrate YOOtheme Pro's Builder (WordPress) and talk about its approach and benefits.  I then demonstrate 3 different builder concepts in ProcessWire using Repeater/RepeaterMatrix, two of which are modeled after YOOtheme Pro's builder and their limitations along with some suggestions.

Thanks for the very insightful video @Jonathan Lahijani

Flexible Content / Page Builders

When it comes to this, if you look at what's out there, in many cases, you'll invariably end up in either of two places with respect to the technology behind the builders; Vue JS or React. A few examples: 

1. Statamic - Vue JS
2. Gutenburg - React
3. YOOtheme Pro's Builder - Vue JS
4. Storyblok - Vue JS

9 hours ago, Jonathan Lahijani said:

but if there were some sort of css-framework agnostic layout tool, that would solve the biggest page builder problem

There is ?. It is called Vue JS (I prefer it over React). OK, there is no ready made tool solution but from my experience developing Padloper 2, I can say it is quite doable. If we are to build any sort of page/site builder, I'd highly suggest to look at either Vue or React - especially Vue. It will save you a lot of hassle.

The biggest challenge I found with these frameworks if using the CLI versions (recommended) is that the 'app' has to be developed outside ProcessWire as they run on different ports. This means the app has to be 'built' in order to test it inside ProcessWire. This is a tedious process. I have never been able to develop a Vue app inside ProcessWire and still get the benefit of Hot Reloading. 

If we end up using Vue JS (or even React), then perhaps we need to pay a visit to our old friend jQuery (and its siblings - UI) to plan for their retirement? ?. It wouldn't make sense to have both. Even if we didn't end up with Vue, modern JavaScript has some great APIs that can replace the dependency on jQuery. I know this is a huge undertaking. I know both the modern and the old have their pros and cons. I also know that jQuery is not evil. I know the decision to use it or not can be subjective. I just prefer working with reactive frameworks (and vanilla JS). What do you guys think? @ryan, would modern JavaScript tools fit into this vision? 

Quote

I'm trying to put together a long term, big picture roadmap (2021 and beyond) 

 

[szabesz]

9 hours ago, Jonathan Lahijani said:

Please share your thoughts.

I agree that something like the YOOtheme Pro Builder would be the way to go. Maybe the next admin theme could be implemented form scratch, along with ProcessWire's frontend content builder, based on something like Alpine.js perhaps? See: https://www.youtube.com/watch?v=M3fY0E60cM0

Some sort of reactive JS library is surely needed for such a builder, especially if more that one person start working on its implementation. However, the issue is that locking the admin and the builder to the future of a JS framework is problematic, to say the least.

 

[kongondo]

3 minutes ago, szabesz said:

Some sort of reactive JS library is surely needed for such a builder,

Ha! Great minds! ??. I just beat you to it ?.

[kongondo]

4 minutes ago, szabesz said:

However, the issue is that locking the admin and the builder to the future of a JS framework is problematic, to say the least.

Sure, but to some extent, we have been locking ourselves to the future of some technologies for decades - PHP, MySQL, jQuery. This is not necessarily a bad thing. It depends on the maturity of the technology, I suppose. Sometimes it depends on the needs of the users of the tool you are providing, for instance, Bootstrap 5 removed dependency on jQuery having been 'locked' in for at least a decade, I reckon. GitHub did the same. Sorry, my examples are all jQuery-related - it is just a coincidence ?.