PW 3.0.170 – Core updates

[flydev]

I will edit the post, but it's just to show you that is possible to move easily blocks.

For the pros/cons you exposed, I have the same point of view and I still think that CKEditor should stay the default editor in ProcessWire.

 

5 hours ago, ryan said:

Moving blocks is not as simple as drag/drop or cut/paste. Instead you have to click up/down arrows to move a block.

Look at this screencast :

 

CTRL/CMD + C, S, X ok ?

 

5 hours ago, ryan said:

We couldn't use our existing Inputfield modules for new blocks (like an Image block)

Interesting, what you mean exactly ? 

 

 

Quote

@szabesz
At first sight, my clients think they can deal with it as it does look familiar indeed. However, it has rather quirky behaviors when adding/removing list items, adding/removing line-breaks, and last but not least the horrid feature of injecting styles when pasting (which can be partially dealt with but never properly). So in the end my clients are always confused by the quirky way of using CKEditor.

That's clear this is something to deal on client basis. Example on personnal experience :

- Me, as I am not a content editor, I still prefer to use CKEditor.

- A colleague, writing big wall of text, is scratching his head on CKEditor and edit content on Wordpress then paste it in PW ?‍♂️

 

 

 

[Ivan Gretsky]

I like @bernhard's approach where every content block has it's own template (if I am getting it right). I also wrote that "Repeater Matrix should be PageTable Matrix" back in 2018 (though I never did try to fix that as @bernhard ?) This way you can easily move content-type-templates between projects.

Though I am not that sure that on-code-only solution he proposes for quickly creating/duplicating/moving those templates would suit most of the users. A decent UI for that should be in admin too with the ability to be extended with hooks, but that is built-in anyway; RepeaterMatrix got it right with the ability to create types on the fly, but that at a cost of putting all the fields in the same template).

There are other points not covered, like

1. nesting, defining parent/child relations (for creating blocks with nested elements, like wrapping a header, a text and a calculator with some custom background like here),
2. crafting a grid for column design (we can get around by creating a lot of custom sections, but would be great to do it more easy),
3. copy-pasting content from one page to the other.

I am not sure this can be done easily, @ryan but can we at least have another look at "The data storage" part of my previous post. If implemented, it could solve a lot of problems, making our builder a lot like editor.js while reusing a lot of goodness ProcessWire already has. If it is not possible at all I think that @bernhard's way is great (with UI improvements, some of which can be borrowed from RepeaterMatrix).

Any way, editor.js or alike do not seem to me a solution to problems we are talking about. Let's just watch at @Jonathan Lahijani's video, the Bard field video again) Editor.js could be a one field inside of some blocks of our builder though.

 

[szabesz]

2 hours ago, flydev ?? said:

Look at this screencast :

How did you fix the "paragraph turning into a header" issue? I cannot seem to spot it in the screencast. BTW, such an issue is a prime example when a non-tech-savvy editor gets stuck.

[monollonom]

Hey,

My 2 cents on the page layout / builder : about editor.js, I see it more as a nice-looking alternative to CKEditor than something genuinely different in what it offers (apart from for the structured data) and it seems a bit limited to be a page builder more than what is already available to us. And I agree with your pros & cons @ryan.

But I do think that adding some improvements to the RepeaterMatrix module, which we all seem to use as a "page builder", is a good way to go.

As much as I don't want my clients to have too much freedom when it comes to the layout, I think there could be a way to introduce a "layout abstraction" into RM, something simple and limited, but that could give more flexibility. In a (distant?) way, it would be like giving the user the ability we have, as admins, to define fields' width or group them in a fieldset.

I drafted some screenshots to show what I had in mind, that could be "user-friendly" (close to what @Jonathan Lahijani showed in his video).

The idea would be to have "layouts" which would be described just like RM items but instead contain abstract "containers". Just like you would with fields, you could change the width of said containers, and make sure they add up to 100%.

Then in the page editor where your RM is, you would have the possibility to either add a "layout" or an item. A layout and its containers would reflect the way we described them in the settings, re: width. To show that the layout is something different, we could use the secondary color.

And this could be how we translate that into (hopefully not with repeating parts like mine) code:

<?php

foreach($page->test_matrix as $item) {
	if($item->type == 'matrix_layout') { // reserved type name
		if($item->layoutType == 'two-columns') {
			echo '<div class="grid">';
			foreach($item->subItems as $subItem) {
				echo '<div class="column-1-2">';
				if($subItem->type == 'type_text') {
					echo $subItem->text;
				} else if($item->type == 'type_image') {
					echo $subItem->image->render();
				}
				echo '</div>';
			}
			echo '</div>';
		}
	} else if($item->type == 'type_text') {
		echo $item->text;
	} else if($item->type == 'type_image') {
		echo $item->image->render();
	}
}

A few notes :

• Don't be fooled by my screenshots, I just messed around with Firefox's dev tools.
• To keep things simpler a layout should not contain another layout.
• The page editor may become too dense, even unpractical, if there is too much containers. Maybe a toggle on a container to expand it along the horizontal axis could be a solution ?

End of my 2 cents.

(also : I like how @bernhard is removing the field's label to gain space and I think it could be nice to have such option in the core, like "☑️ Do not display the field's label". Of course it would then remove the ability to collapse the field, but it would be a conscious choice. Edit : this is especially useful in context where you use RM and have 1-field types, like I used in my example above)

[flydev]

10 hours ago, szabesz said:

How did you fix the "paragraph turning into a header" issue? I cannot seem to spot it in the screencast. BTW, such an issue is a prime example when a non-tech-savvy editor gets stuck.

I just hit [enter] at the end of the line, like in CKEditor, a new paragraph is open.

[bernhard]

12 hours ago, Ivan Gretsky said:

Though I am not that sure that on-code-only solution he proposes for quickly creating/duplicating/moving those templates would suit most of the users. A decent UI for that should be in admin too with the ability to be extended with hooks, but that is built-in anyway; RepeaterMatrix got it right with the ability to create types on the fly, but that at a cost of putting all the fields in the same template).

Absolutely true and I've had a chat with @ryan about the same topic yesterday. What I forgot to say (thanks for bringing that up here @Ivan Gretsky) : I totally agree, that there should be a UI for beginners or non-coders to achieve the same things. I just didn't implement it in RockMatrix because it's a LOT more work and - of course - I don't care about that option. But what I want to say is: Please develop such modules with an API-first approach in mind. Just like ProcessWire was built in general: First comes the great API, second comes the UI (eg the PW admin that is built on top of that). I've had several requests from all over the world for better supporting RepeaterMatrix in RockMigrations. And it often felt hacky to get that working. For example matrix item names are somewhat concatenated strings like matrix{type}_whatsoever (https://github.com/BernhardBaumrock/RockMigrations/blob/16b9029c5aa46099f9a57391bfbf167229776f98/RockMigrations.module.php#L374).

I think if all modules were built api-first that would have lots of benefits: Migrations would be easier, quality of code would improve and so would maintainability. I don't see any downsides.

12 hours ago, Ivan Gretsky said:

I am not sure this can be done easily, @ryan but can we at least have another look at "The data storage" part of my previous post. If implemented, it could solve a lot of problems, making our builder a lot like editor.js while reusing a lot of goodness ProcessWire already has. If it is not possible at all I think that @bernhard's way is great (with UI improvements, some of which can be borrowed from RepeaterMatrix).

I'm not sure about this. I've built RockMeta which is basically what you are saying but a lot less complex. It stores single field values in page meta-data. For a complex field like a page builder with different types and different fields this would get a lot more complex (just a feeling). And not to forget: Data queries would be totally different from how processwire works at the moment. That could be a problem for page finding operations (either internal pw selectors or using RockFinder). Whereas if everything is just pages and fields, things are so simple, clean and beautiful. ProcessWire that is ? 

Just throwing in some thoughts - I'm sure ryan will help us find the best solution ? 

[bernhard]

PS: I'm in gereral very interested in a solution for "non-db-fields". Meaning fields that are code-only and do not live in the database as their own tables. That's what rockmeta does and it is great for many situations where I definitely do not need to query those fields via selectors or rockfinder. For example I can add a checkbox to a "headline" field that says "capitalize headline" and if checked, well, the headline shows capitalized on the frontend. Or another checkbox that says "add more space above this headline", or another one that says "center this headline". The great thing is that those inputfields can live anywhere on the page editor - in my case they are even part of another inputfield (and not as a separate checkbox as they were if we built regular checkbox fields in PW):

So I agree such a feature would be great to have. Maybe not for the whole page-builder field but maybe as an option for fields in general? So we could have a page builder field and as one content block we could have such a JSON-field where one can input an address for example (forename, surname, street, zip, city).

RockMeta does not work with multi-lang fields at the moment. Just saying ? 

[ryan]

Quote

I will edit the post, but it's just to show you that is possible to move easily blocks.

@flydev ?? Thanks for posting that, I've learned something new about editor.js. My experience with it is mostly limited to their own demo, so I'm really just looking at it from an outsider perspective. The tool is more powerful than it looks at first. I was particularly impressed with your integration of ProcessPageEditImageSelect. Nice work. It looks like you are pretty far along with this module and it also looks like it will be a great tool for PW users. When do you think you'll be releasing it?

Quote

Quote

We couldn't use our existing Inputfield modules for new blocks (like an Image block)

Interesting, what you mean exactly ? 

From what I can tell, editor.js is one big input element, kind of like a rich text editor, even if it also isn't. I think this is also compelling, and what makes one draw comparisons to CKEditor. So editor.js could be represented by a PW Inputfield, but it couldn't itself contain other PW Inputfields (as far as I understand it). Whereas something like a Repeater is an Inputfield that contains other Inputfields. If a block in a builder can be represented by a group of Inputfields, then that means that the types of blocks you can build can be very flexible and modular. The benefit being that it expands the means by which you can extend it. On the flip side, it also means that it's not something you'd ever compare to an RTE because it's just completely different. Editor.js seems to find a nice middle ground between RTE and block builder. 

Quote

I like @bernhard's approach where every content block has it's own template (if I am getting it right).

It does appear that every block type is defined by a PHP class, but I'm not sure if that also corresponds to a template (?). Templates are a resource best limited to not use any more than necessary (since they all have to be loaded on every request), which is why RepeaterMatrix limits itself to 1. Though maybe something like block types aren't huge quantities, I don't really know. 

Quote

 Though I am not that sure that on-code-only solution he proposes for quickly creating/duplicating/moving those templates would suit most of the users. 

Such a solution would need to come with several predefined block types, just as editor.js does. I think this builder focus is important, otherwise it's becomes too abstract, at which point something like editor.js with plugins becomes a clearer answer. So I'm hoping that people could get up and running by selecting existing block types rather than having to always create them. Then they can create them when-and-if they need too. When it comes to code definition, it comes with its own benefits, and I think it's fine so long as the built-in defaults/types are strong enough to answer the most common needs.

Quote

nesting, defining parent/child relations (for creating blocks with nested elements, like wrapping a header, a text and a calculator with some custom background like here), crafting a grid for column design (we can get around by creating a lot of custom sections, but would be great to do it more easy), copy-pasting content from one page to the other.

Getting into this level of stuff is where the RepeaterMatrix upgrades should help. But this level of complexity I think would hinder a simple builder for the larger audience. For this particular project, I think it's best if it focuses exclusively on content tools and doesn't get into layout and style aspects. 

Quote

I am not sure this can be done easily, @ryan but can we at least have another look at "The data storage" part of my previous post. If implemented, it could solve a lot of problems, making our builder a lot like editor.js while reusing a lot of goodness ProcessWire already has. 

This is one of the things Jonathan and I talked about. I'm investigating options for alternate storage methods of repeater items, such as the ability to save all the content JSON encoded in the 'data' column of the repeater table (rather than saving in separate pages). It would be an option you can choose in the field settings. I'm going to try and make it happen though it's possible I may hit a roadblock, so will have to get further along before I know for sure. 

Quote

Any way, editor.js or alike do not seem to me a solution to problems we are talking about. Let's just watch at @Jonathan Lahijani's video, the Bard field video again) Editor.js could be a one field inside of some blocks of our builder though.

I think editor.js is also an answer to what many people are looking for, so we have to be careful not to lose sight of what it does well. While there are things to learn from it, I agree it probably doesn't answer quite enough of what we are looking for.

Quote

But I do think that adding some improvements to the RepeaterMatrix module, which we all seem to use as a "page builder", is a good way to go.

Good ideas. Improvements to RepeaterMatrix are part of the plan. But that's going to be a separate project.

Quote

PS: I'm in gereral very interested in a solution for "non-db-fields". Meaning fields that are code-only and do not live in the database as their own tables.

The $page->meta() method exists for this purpose, at least from the API side. Though the values are still stored in the DB, but not as field data, just as flexible unstructured data stored for each page. 

The Combo field might offer potential here too, as you can bundle as many inputs as you want within a single Combo field. Though it's still technically stored in field data, and still as searchable as any other field data. But without the being a separate dedicated field and having a separate DB table for each component, etc.

[bernhard]

1 hour ago, ryan said:

It does appear that every block type is defined by a PHP class, but I'm not sure if that also corresponds to a template (?). Templates are a resource best limited to not use any more than necessary (since they all have to be loaded on every request), which is why RepeaterMatrix limits itself to 1. Though maybe something like block types aren't huge quantities, I don't really know. 

Yeah - every block is a separate template (all having a prefix here):

No idea how I could measure or tell about the performance impact of such a setup compared to other strategies, but it's nothing noticeable and I thought if that really became a problem I'd simply do some caching...

[ryan]

Quote

No idea how I could measure or tell about the performance impact of such a setup compared to other strategies, but it's nothing noticeable and I thought if that really became a problem I'd simply do some caching...

I'll have to think about it a bit more to be certain, but most likely it isn't a problem. And what's in your screenshot above definitely isn't a problem. If we get into 100s of these kinds of templates then I think that's where I might start to worry and think we have to benchmark and find alternatives... but that's also the point where someone has gone well beyond a simple builder.

[Robin S]

@ryan, what follows is only about the idea of taking Repeater Matrix in a Bard-like direction for long-form content, as referred to in my earlier post. I don't have an opinion on the "builder" idea because it's not something I or my clients need.

Looking at the Bard video you can imagine it as rich text field (i.e. CKEditor or maybe Editor.js) with Repeater Matrix elements distributed through it. You can add new Matrix items and edit them within the rich text interface. Here's a mockup of what a hypothetical "Repeater Matrix Bard" field might look like:

But as far as I can see such an interface would be very difficult to implement. You'd have to somehow replicate the Matrix item interface inside CKEditor or Editor.js, maybe as plugins. [Actually, as soon as I made this mockup I suddenly had another idea for how it could be done, but I'll come back to that at the end of this post].

So when I first started thinking about this idea (back when Bard was introduced to Statamic) I wrote that option off as too difficult and turned to working with the existing CKEditor and Repeater Matrix fieldtypes. Of course this was going to involve compromises and the result was never going to be as slick as the Bard interface. My idea was to use placeholders for the Matrix items within the CKEditor field, in the form of CKEditor widgets. Each widget would correspond to a Matrix item, and a Textformatter module would replace the placeholders with rendered Matrix item output when the page is rendered for the front-end. This is easy to do via $matrix_page->render().

First I experimented with keeping the Matrix field visible in Page Edit, with the Matrix field in accordion mode. Hovering a widget placeholder in CKEditor highlighted the Matrix item (to help the user work out which placeholder is linked to which Matrix item) and clicking the widget scrolled to and opened the Matrix item for editing. But this takes the user away from CKEditor and disrupts the writing experience a bit too much.

So then I changed to hiding the Matrix field in Page Edit so the user only sees the CKEditor field. When they add or edit a Matrix item a Magnific modal opens where they can work with the fields within the Matrix item. I added a dropdown to the CKEditor toolbar to let users add new Matrix items/widgets within the CKEditor field. This works okay but it's not fantastic - the main dissatisfaction I have is that my widgets are rather basic. This is because I'm no expert when it comes to CKEditor and its widget system. But looking at example widgets in a tutorial it seems that it's possible for them to have richer layouts and items like images (icons?) within them. I'm using the title attribute tooltip to show the text from the Matrix item header, but it would be great if the widget contained an icon corresponding to each Matrix type (sidenote: we really need a larger selection of icons available in the core) and perhaps some of the item content. Maybe the developer could specify code for each Matrix type that would render the HTML of the widget? I fear this is all beyond me but if you're interested maybe you could explore the possibilities of this? Or see if a similar approach would be more easily accomplished in Editor.js.

A screencast of the system in action:

Because the user doesn't see the Matrix field it would be possible for items to become orphaned there after their corresponding widgets are deleted from the CKEditor field. But it would be good to keep orphaned items for a short while to serve as disaster recovery. So perhaps orphaned Matrix items would be automatically removed after some period of time.

Coming back now to the mockup screenshot and an idea of how to achieve it...

What if there was a special rich text Matrix type available to be added to any Matrix field? This would consist of a CKEditor field in inline mode (to reduce the distraction of the toolbar) together with (optional) Files and Images fields to allow for linked files and embedded images (edit: it would be good if somehow a single Files field and a single Images field was shared between all rich text items).

This matrix type would render differently within the Repeater Matrix inputfield - it wouldn't have a permanently visible header and the Files and Images fields wouldn't be permanently visible either. Instead a special toolbar would appear when the rich text item was hovered (probably at the bottom to avoid clashing with the CKEditor toolbar). This toolbar would include the standard Matrix icons (sort, copy, toggle, delete) and icons that make the Files and Images fields visible for when those need to be accessed. But when nothing is hovered it would render just as the rich text portions appear in my mockup.

It would also be nice if the Matrix "add new" links were replaced by a "+" icon that appears when you hover between existing Matrix items, like in Bard. That would reduce some clutter in the inputfield and allow new items to be inserted in whatever position is wanted.

This approach would not be quite as nice as a single rich text field containing Matrix items. Because I think the concept of multiple text fragments is not what users imagine for a long-form article. And it would result in more pages behind the scenes, although that probably isn't a big problem. But it seems like it might be relatively simple solution to the Bard idea.

[monollonom]

@Robin S, bouncing on your mockup, I'm not sure if mixing permanent / appear-on-hover UI is good for the end user. To me, what seems to be the issue is the visual space PW's UI takes and I think it could (partially) be solved by allowing (in the field's settings) to remove the label + padding around it. Mixed with the inline CKEditor, it almost looks like your screenshot, except that it's still clear we're still dealing with "components" that the user can move around.

[Zeka]

On 1/7/2021 at 11:12 AM, Ivan Gretsky said:

Just in case we really go that route with dynamic admin pages there is a way NOT to use a reactive JS still achieving similar results, staying in the realm of a server-generated html and avoiding complex build workflows. There is a mature Unpoly library and a new Hotwire stuff from Basecamp themselves. Using those might be an alternative, which would not require such massive changes, as switching to Vue or React (do not think Alpine is enough here))

Hotwire would be a great couple to ProcessWire due to it's name only))

It worth to mentions https://htmx.org/ the successor to intercooler.js.

[szabesz]

23 minutes ago, Zeka said:

It worth to mentions https://htmx.org/ the successor to intercooler.js.

I was also thinking of mentioning it, however, Unipoly seems to implement a lot "more features" and its more advanced, soon to be released new version can be expected in weeks: http://triskweline.de/unpoly2-slides/#1

Note, that while these libraries are similar, but they are far from being the "same". Unipoly is opinionated while HTMX "is not" (at least not that much...), which is a big difference. However,  Unipoly offers a lot  more out of the box, so I'm myself thinking of using Unipoly v2 in the future. Unipoly v2 also – optionally – supports Bootstrap which is good for even more rapid development. I'm not a big fun of Bootstrap, but Bootstrap 5 and Unipoly 2 looks like a good combo, so I will definitely find some time to test them together in the near future.

Edited January 20, 2021 by szabesz
typos

[kongondo]

On 1/7/2021 at 6:28 PM, kongondo said:

Thanks for the defs @Jonathan Lahijani

I'll see if I can set myself a challenge to build a basic clone of this this weekend ?.

Here you go...took longer than planned.

 

[jploch]

@ryan and others ?
Sorry I'm a little late to the party.
I just wanted to share my view as a designer on an update of the core default admin themes and future branding of pw in general.
This is just my opinion, and I'm aware that this can be a very subjective topic. I just want to contribute to the discussion.

I really like that PW gets out of the way when it comes to designing/developing a website. It's like an unopinionated frame around my projects. The branding of PW in contrast seems very loud, opinionated and not very serious. I would enjoy a more professional/reduced color scheme (black and white and maybe one additional color). I wish the default admin themes and UI would act more like a neutral frame/canvas for the content. The future will probably be more about frontend stuff that gets rendered inside the backend (pagebuilders for example), so it would have less of a conflict with the frontend (that might have a lot of colors). Also I would love to have a option for a fixed header that takes less vertical space. While I know that clients love to see their logo, I don't like the Idea to do a custom branding of the backend based on the CI of the client (the client CI, logo and colors might not be working in an UI context). Instead I would prefer a solid default UI that gets out of the way. 

Another area where the branding and use of color gets in the way is on the showcase page of the PW website.
The websites/projects presented here would benefit from a more neutral background (e.g. white, light grey, black). 
Imagine a museum where all the artwork from different artists and contexts, would be presented on a blue wall instead of a white wall.

I recently released my own admin theme, which follows some of the ideas mentioned here.
Maybe this can be an inspiration for a future default theme.

Please don't take this the wrong way. I really appreciate all the work that goes into PW and this amazing community!
I would love to know how others feel about this!

[adrian]

2 minutes ago, jploch said:

The branding of PW in contrast seems very loud, opinionated and not very serious. I would enjoy a more professional/reduced color scheme (black and white and maybe one additional color).

Exactly my thoughts!

[teppo]

4 hours ago, jploch said:

I really like that PW gets out of the way when it comes to designing/developing a website. It's like an unopinionated frame around my projects. The branding of PW in contrast seems very loud, opinionated and not very serious. I would enjoy a more professional/reduced color scheme (black and white and maybe one additional color). I wish the default admin themes and UI would act more like a neutral frame/canvas for the content. The future will probably be more about frontend stuff that gets rendered inside the backend (pagebuilders for example), so it would have less of a conflict with the frontend (that might have a lot of colors). Also I would love to have a option for a fixed header that takes less vertical space. While I know that clients love to see their logo, I don't like the Idea to do a custom branding of the backend based on the CI of the client (the client CI, logo and colors might not be working in an UI context). Instead I would prefer a solid default UI that gets out of the way. 

Necessary disclaimer: just like you, I also mean zero disrespect, and I get that this is a topic where opinions matter, and so on ?

I agree with your point about that the admin should stay out of the way, and I do also share some of your concerns regarding current admin theme. But that being said, I must admit that I quite like the current colour theme: it's pleasant, professional, not at all childish (in my opinion), and brings just the right amount of personality to the theme. Also I personally find a black/gray/white colour theme rather boring — unopinionated for sure, but also boring.

On the other hand one thing that I do dislike about Admin Theme Uikit is the noise created by separator lines. And, as it happens, your theme suffers from exactly the same issue: to my eyes it's still way too noisy.

Opinions, right? ?

Anyway, this is a topic that is definitely worth discussing further. Also Ryan has been extending our ability to customize and build upon the Uikit admin theme lately, and I'm quite interested to see where that road takes us. I feel that with some additional tweaks and customization options it could become a solid starting point. And if that could finally resolve the age-old problem with modules having to support multiple admin themes that all work differently, all the better.

(Loosely related note: I seem to recall that there was some reason why Tailwind's original gray colour set was blue-gray. For whatever reason that type of thing works better for my eyes. There are probably better examples, but Craft CMS makes extensive use of gray/blue-gray/blueish colours, and their admin looks very pleasing to me. It's not opinionated, but it's also not impersonal or boring.)

[Robin S]

1 hour ago, teppo said:

Opinions, right? ?

Exactly. I doubt we're going to all agree on all details of how the admin theme should look.

But I hope that nobody among us is sitting there gritting their teeth because the admin isn't looking how they want it to look. Because we're all website designers/developers and we know how Cascading Style Sheets work (especially the cascading part). And it's not a difficult task to add your own CSS to the admin and override the styling of elements as you like. The admin theme markup changes very rarely and so you can spend half an hour working out your overrides for colours or whatever and then reuse those styles on all projects going forward. If you compile your overrides from SCSS/LESS then it's really easy to tweak colours for specific projects via variables. 

 

 

[szabesz]

28 minutes ago, Robin S said:

...it's really easy to tweak colours for specific projects via variables. 

It would even be easier if the css "framework" was built upon css variables, eg: https://www.gethalfmoon.com ("easy dark mode" is also built in). That's what I call a few lines of code: https://www.gethalfmoon.com/docs/customize/ No setup, no build process, only a few lines of code, and there is no need to talk about color preferences in that case ?

6 hours ago, jploch said:

While I know that clients love to see their logo,...

It has been an optional setting of the UIkit theme right from the beginning. It is easy "not to use it" ? Anyway, I add the client logo and client colors so that I can tell apart the admins I have to work with... so "branding it" is not just for the client's sake but my own, too.

[Robin S]

13 minutes ago, szabesz said:

It would even be easier if the css "framework" was built upon css variables

Sure, the admin theme could make this sort of thing easier. But it's not excessively difficult to tweak the styling now if a person is motivated.

When people make comments or requests about the admin theme styling (not just in recent topics but in the forum generally) I'm never sure if they realise that they don't need to wait for Ryan to do something in order to get what they want. It's CSS101 stuff.

[jploch]

13 hours ago, teppo said:

I agree with your point about that the admin should stay out of the way, and I do also share some of your concerns regarding current admin theme. But that being said, I must admit that I quite like the current colour theme: it's pleasant, professional, not at all childish (in my opinion), and brings just the right amount of personality to the theme. Also I personally find a black/gray/white colour theme rather boring — unopinionated for sure, but also boring.

I also don't think the current branding is childish and it doesn't have to be in black/gray/white either. The current color theme certainly helps to create a unique and recognisable brand, but can be distracting in an UI context. I think a unique branding could also be archived with a reduced color theme and the use of unique typography and the PW logo (on the PW website). I'm aware that it's easy enough to create a admin theme of my own, but my comment was more about the future branding of PW in general. I do think there are other more important thinks to pay attention to than this. And for me this is not really an issue (I created my own admin theme). But I think it will matter to those who are new to PW and see the PW website and backend for the first time, here the first impression matters. I even had some clients choosing another CMS because they feel that PW looks to "technical".

[jploch]

13 hours ago, teppo said:

On the other hand one thing that I do dislike about Admin Theme Uikit is the noise created by separator lines. And, as it happens, your theme suffers from exactly the same issue: to my eyes it's still way too noisy.

I agree! With my theme I removed some of those lines already (take a look at repeaters or fieldsets). But it's still not perfect and I will further investigate how to improve this.

[bernhard]

11 hours ago, Robin S said:

Sure, the admin theme could make this sort of thing easier. But it's not excessively difficult to tweak the styling now if a person is motivated.

When people make comments or requests about the admin theme styling (not just in recent topics but in the forum generally) I'm never sure if they realise that they don't need to wait for Ryan to do something in order to get what they want. It's CSS101 stuff.

Robin, I disagree here. I've modified the admin quite a bit to fit to my needs. The problem has always been, that I had to rely on the old admin theme source files meaning that changes would potentially break my theme or backend fixes would not apply to my old version...

I hope that's fixed now with the latest admin theme updates - I'm currently locked to the latest master as the latest dev does not work with my custom admin theme. I have to investigate... But it somehow proves, that it has unfortunately not just been simple CSS 101...

[kongondo]

I can't recall whether it was this topic or another one but I remember someone asking where best to discuss issues/wish list, etc? In case you missed it, @ryan, I would like to bring GitHub Discussions to your attention. Maybe something worth considering.