Leaderboard

Work continues on the new processwire.com website. I’ve nearly finished developing most of the modules directory this week and next week will be working on the development side of the API reference and sites directory. Some more good news to share is that when the new site launches, the new admin look and feel will launch as well. The website and admin share a similar design language in some areas, and I’m confident you will love them both. When we use screenshots of ProcessWire in the new site design, they will be from the new admin look and feel. It is still admin AdminThemeUikit, but with a new face that is beautiful, modern and professionally designed. I’ve been using for more than a week and it’s fantastic in my opinion. If for some reason you end up wanting to keep the current look of AdminThemeUikit (perhaps a client doesn’t like change), it will remain as an option too. If you are extending AdminThemeUikit or using the admin.less feature (developed by Bernhard) to custom style the admin, all of that will continue working too. What will likely be changing is that we’ll be moving the older AdminThemeDefault and AdminThemeReno out of the core and into the modules directory. I’d rather keep the core efforts focused with AdminThemeUikit, but continue to support the older admin themes as installable options. Prior to this, most of what you’d seen in ProcessWire’s core admin and website has been designed by me (excluding AdminThemeReno). And I haven’t worked full time as a designer since 2005 or so. If I ever had any site design skills, they are long gone. So PW has always had a “designed by a developer” look. Having professional designers take over the design of both the admin and the website just feels like a major upgrade to ProcessWire all around. More than I could have guessed. I look forward to when I can share the new site design, admin look and feel, and the designers with you. Thanks for reading and have a great weekend!

Hey @BrendonKoz, Thanks for the tip. No, I haven’t tried anything yet. Been busy these last weeks. I’ll try your solution. Thanks again.

I guess that YOOtheme probably will implement CSS variables with UIkit 4. Here is an open issue for ideas and suggestions for UIkit 4: https://github.com/uikit/uikit/issues/3967 Yes, there is one partial file for variables, but I don't think you can easily change every variable to a CSS variable. Some variables use for example darken() and lighten() which I think don't work with CSS variables. I have tried it once, for some variables it is possible but for most not. One simple enhancement I mentioned several times over the years would be to include the CSS source map in the AdminTheme. But it seems that I am only one with this wish. 😅

Sorry for the delay — this method is now hookable 🙂

Looks like I've got some catching up to do here 🙊 Thanks for reporting this. It should now be fixed in the latest version of the module!

Thanks for the clarification! Still hoping that we can make some minor improvements, though. Loosely related, but I'm not sure if you've noticed that there is a are a couple of comments related to one recent admin change 🙂 That sounds a bit disheartening. I've never actually built anything from scratch with Uikit so I'm not too familiar with its structure, and I must admit that digging into AdminThemeUikit just now made my head spin, but it looks like variables are defined mostly in one place. Is that right, and if so, would it be an option to set those based on CSS variables? That might not work with — or rather stay in sync with — custom admin styles, though. Of course there's always the option of somehow duplicating LESS variables to CSS variables. This way they could at least be used in modules etc.

Sorry, I don't have any ideas why the challenge is getting corrupted like that but there is something in the back of my brain saying it's seen something similar before - if I remember, I'll let you know. On a side note, have you seen this WebAuthn module: https://processwire.com/modules/tfa-web-authn/

Hey @TomPich, I don't know if you gave it a try, but I just did. Although I was able to get the button to work after manually modifying InputfieldTinyMCEConfig.php, I wasn't able to get it to actually work using the default interface of a Textarea field's Input config for TinyMCE fields. As the Accordion plugin is not an external plugin, there doesn't seem to be a simple way to use the UI of the field's Input config settings to enable the accordion. I played around a bit, and did get it to work, but after saving the injected "accordion" (details/summary elements), the HTML of those elements got stripped via HTMLPurifier, so there's another problem. Turning off HTMLPurifier allowed it to work, though I'm not sure if you'd want to do that. There's another recent topic where someone is attempting to adjust HTMLPurifier a bit. Currently, it seems that to get the Accordion plugin to work until/unless the core TinyMCE module is updated to include it, you'd currently have to migrate your customized settings via the field's UI into a custom JSON that overrides what you have set via the field UI. Example "Custom Settings JSON" (PW default + accordion): { "plugins": ["anchor", "code", "link", "lists", "pwimage", "pwlink", "table", "accordion"], "toolbar": ["styles bold italic pwlink pwimage blockquote hr bullist numlist table anchor code accordion"] } After playing around with the accordion interface, I don't find it quite as intuitive as some other elements, but it does work.

@ryan Makes sense. Really looking forward to seeing what y'all been cooking up! I paused the other day and appreciated all the quality of life improvements that have come over the years and value them as much as the big features. Almost can't wait. It's like Christmas for adults, who are also developers.

Thank you Zoeck, you are right. I have purchased it.

Hey Ryan! First of all, this all sounds very promising. In my humble opinion you are vastly underplaying your own skill in terms of design, but that's also why we can trust that you'll recognize amazing design once you see it. Looking forward to seeing what the team working on the design has cooked up 😉 Now, please forgive me for jumping directly into asking for stuff, but... I know this is small thing, but it would be quite nice if the new admin made use of CSS variables wherever it makes sense; colors, font sizing, etc. (Or provided them as an alternative for non-core tools to use, in case it is not feasible to use them for actual admin styling.) The reason I'm saying this is that I've built various admin tools that I wanted to look like the admin theme, and since there is (to my knowledge) currently no simple way to access existing colors etc. in CSS, any non-Uikit elements I've had to "hard-code" to use current styles. This includes the default green/cyan/blue color theme, current spacing and font size practices, etc. As a result said custom elements may look out of place once the theme is updated 🙂 (Just for the record: SCSS/LESS might be an option, but that feels like a lot of unnecessary overhead and complexity where vanilla CSS would easily suffice. I'd really like to avoid that if possible, and to me it seems like CSS variables are an easy and well supported alternative.) Additionally: it would be awesome if accessibility was a consideration while creating this new admin theme. I know it has been considered to a point in the past, but has never been a major goal. Hopefully we can push things forward in this regard in the future. If there's something I can help, I'd be happy to 🙏

The "summary", just in case this was overlooked, isn't (entirely) an in-built feature for the module. It needs to be told what field in your template(s) will be used for the search result summary when rendered. From the documentation on the Modules page, under the "Options" heading, check the render_args property of the module's config, and look for the below: // Summary of each result (in the search results list) is the value of this field. 'result_summary_field' => 'summary', In the config, the "result_summary_field" points to the field used in your instance of ProcessWire this module is being used in that will be used to render the search result template's summary. So if in your templates you either don't have a summary field, or the field you use to define a summary is named differently, you'd need to use whatever value you have for your template(s). If maybe you used something like "short_description" as a page summary field, go with that. If you don't have a summary, you could use a "body" or "content" field, and in the render template use some form of string truncation, such as sanitizer()->truncate($your_summary_field, 80). If you're using JSON, slightly further down is a different section for that: // These settings define the fields used when search results are rendered as JSON. 'results_json_fields' => [ 'title' => 'title', 'desc' => 'summary', 'url' => 'url', ], Does that help at all?

Hi Teppo, Would it be possible to make the 'isRepeatableField' in Indexer.php method hookable. I would like to attach our FieldType 'FieldtypePageTableNext'. That would be great. ?