bernhard

Fresh on the dev branch: Some improvements for the toolbar (added a toggle):

Thx, already tried that, no luck. Also when updating dependencies manually which I already did I get some PHP errors 😞 Seems there is more to it, so if anybody wants to contribute his/her time and knowledge for this update it would be highly appreciated 🙂

RockShell currently uses the following composer.json file: { "require": { "illuminate/console": "^8.40", "illuminate/events": "^8.40", "symfony/browser-kit": "^5.4", "symfony/css-selector": "^5.4", "symfony/dom-crawler": "^5.4", "symfony/http-client": "^5.4", "symfony/mime": "^5.4" }, "autoload": { "files": [ "Application.php" ] }, "config": { "platform": { "php": "7.4.0" } } } I'm using PHP8.4 on my latest project and get many warnings like this: So I thought just update dependencies... Turns out it's not that simple. "composer update" will only update to the listed versions, which are already quite dated. Any experienced composer users here @teppo @Jonathan Lahijani that know an easy way to do this? illuminate/console for example is version 12.17 at the moment.

There is a free online event on ::: June 17, 2025 ::: 13:30–18:30 CET/CEST ::: 07:30–12:30 EST/EDT ::: 11:30–16:30 UTC https://lp.jetbrains.com/phpverse-2025/ @ryan what about taking part as a speaker on such events to make PW more popular?

Hey @Pavel Radvan thx for your question. I think what you are looking for is exactly what is shown in the example at the very bottom of this page in the mPDF docs: https://mpdf.github.io/paging/using-page.html Does that help or do you need more assistance? 🙂

@ryan I took some time to reflect and let the situation cool down. I'm very interested in keeping up a good relationship with you, which is why I want to address your last post rather than moving on and pretending nothing happened. I think this is neither what I said nor what I did. This statement has really bothered me a lot over the last days. I'm sorry if I made you feel that way. It was honestly not my intention and I apologise for that! I want to add that if you feel that the other person is behaving unfairly, it might be worth considering whether you've given them a fair chance to explain their perspective. I have read this thread again from the beginning, and I see many posts from my side that very much follow your suggested syntax for being taken seriously. However, I didn't feel that my concerns were being heard or addressed. I honestly think we both could have done better. I'm fine with that and I hope you are too! Otherwise please let me know and we can discuss this further.

Regarding the new scrollbars on the menu dropdowns. I think that's a great improvement! Is that part of the new style or is that considered to be part of the base style for all AdminThemeUikit styles? I think it would be great to have it in the base style!

Thx for adding that detail! Considering that Ryan mentioned the nature of the new style being like extending PHP classes, I wonder why settings of the default theme are part of the AdminThemeUikit module. Visible or not - technically they are built into AdminThemeUikit, which feels strange. I'd expect AdminStyleKonkat to be a separate module and therefore all dedicated settings would be on the module config of AdminStyleKonkat. Again, this module could still be part of the core and it could still be turned on by default. At least for new installations - I still think it would be good to not change the style with the upgrade without asking. Settings that apply to all styles on the other hand would be part of the module config of AdminThemeUikit. For example the CMD+K hotkey is independent of the style and thus would belong on the config screen of AdminThemeUikit, which would mean this feature can be used by any style. I think this would be a very clear setup that clearly separates the responsibilities of the THEME and the STYLE and this would very well reflect what Ryan mentioned as strategy.

@jploch sorry for all the posts, but as you can tell I'm spending a lot of time in the PW backend, so I report things as they pop up. Take your time to evaluate them and to respond. Expanding on this suggestion it confuses me a lot to see this part of the GUI inside of AdminThemeUikit: I think it would make much more sense if these settings were defined on the settings page of AdminStyleKonkat, as it makes no sense to me to allow darkmode settings on AdminThemeUikit if I'm using AdminStyleRock which does not offer a darkmode. @ryan I hope this is considered to be constructive feedback and I hope it helps you to understand why I got a very different impression of what this new "theme" is or should be.

Thank you. Thank you.

Because the code of the module would be identical to AdminThemeUikit, and the new theme is still all Uikit. I want AdminThemeUikit to remain PW’s main admin theme, just with more options for the appearance of it; especially one that helps us attract new users. Were it a 3rd party thing for people to install then a separate module would still make sense. But for this case, it would just be unnecessary overhead. I forgot to respond to this one and I'd consider it important. It sounds like you totally misunderstood my request. I'm very much for using AdminThemeUikit and I very much support all the mentioned goals. I was just questioning why it was not built in a way that followed what we pushed to the core in 2021. And probably released as a module first, and then, when early adopters had time to test and give feedback, was merged to the core and set as the new default. I think this approach would have signalled the appropriate care and it would also have helped to identify which parts need to be part of the new theme and which parts need to be addressed in the base theme. If keeping and supporting all existing themes is a goal, then I think this approach would have best signalled this and would have had the best chance to make it happen. Take this comment for example from my rock theme: // @ryan // early stage idea // can we move those colors to the base theme (eg --pw-gray-200)? // then all styles could inherit those colors // and all module developers could rely on them. // the problem now is that modules use their own colors // often based on reno, which make the style break when // someone uses AdminStyleRock or any other style/theme You see that I even used css variables in this comment, so I'm definitely aware of their possibilities and benefits. But the more complex things get the more careful we have to be. --- I can't understand what you mean by "code would be identical to AdminThemeUikit". Just have a look at AdminStyleHello if you did not already. I built it in 2022 to propose a clean way of how to extend the base uikit theme in ProcessWire. I don't see how that would be considered to be "identical to AdminThemeUikit"? As it is not too late for anything may I ask if the current setup can be changed? Could the new theme be called "AdminStyleKonkat" and could it be built in a way that I proposed with AdminStyleHello in 2022 (or better 😄 )? I think this would help in reducing confusion about what is a theme and what is a skin and it would clearly show that all styles are just a skin on top of AdminThemeUikit and all are equally supported and the user can choose whatever he/she wants. If AdminStyleKonkat was built in that way I'm not sure whether supporting AdminStyleRock made sense, as it tackled the same goals, but I think this does not matter. I think the current situation is confusing. We have AdminThemeUikit and there we have two options. The "default" theme and the "original" theme. Then we have some themes and styles lying around somewhere in the modules directory. Like AdminThemeBoss (which is also a skin on top of AdminThemeUikit as far as I know and which seems to also tackle similar goals with having neutral colors and one primary color) or AdminStyleRock. If a user wanted to use one of these modules he had to install it as a module and then he had to go to AdminThemeUikit to select "original" theme. If he didn't do that, the style might cause problems and the user would likely think that the style is broken and can not be used. This has already happened in only two weeks of having the new theme on the dev branch: https://github.com/processwire/processwire-issues/issues/2078 I think this setup is confusing and I think the process for users is currently confusing as well. I could think of the new style being a module (AdminStyleKonkat) and any other style being the same. Being a module does not mean it can not be in the core. I don't understand that conclusion. We have many modules in the core, some of them being installed by default, some being ready to install with the click of a button. AdminThemeUikit could, for example, then pick up all modules that are installed and follow the naming convention "AdminStyle..." and list them as an option to choose from: vs.

Serious question: If it's not too late for anything, then why is feedback like this not considered to be helpful? What I tried to point out is that when using UIkit like explained in their docs, then we would not have these issues at all. To change the primary color all you'd have to do is this: @global-primary-background: red; Then all primary buttons will use that color. All progressbars will use that color. All UIkit components will use that color. And any component that they might add in the future will use that color as well. Which means that any developer in the world can not only use what the core uses but anything UIkit has to offer. Framing that as "features that ProcessWire traditionally did not offer" is what I consider as not being helpful. We, on the other hand, are using thousands of overrides at the moment. Anything that Diogo didn't think of will possibly cause issues. Cause frustration or ugly fixes on our side and cause Github issues on your side and I think your time can be spent better. Seeing reno green shine through tells me that the new theme must be extending (if you don't want to call it overriding) the reno theme and not the base theme, that I carefully split apart from the reno theme in 2021 to make exactly that possible: Properly extending the base theme without applying layer by layer of overrides. Exactly like you mentioned with PHP classes. What I see in the new theme does not match what I read in your announcements and explanations, sorry. I consider that to be a very valuable feedback for anyone that is open to hearing it. Unfortunately for many reasons I got the impression that it's too late for such input. And I understand that this is a difficult situation. That's why I apologised. It does indeed not help if anybody complains about fundamental issues if it's not possible to change them. I get that and as I said I'll try to be more constructive with that situation. But please don't pretend that it's not too late for anything and that we are at an early stage in the process. This feels dishonest to me on my cost. Obviously I also do not think that micro-managing a professional designer would be helpful and that's not what I have been suggesting. I just don't see anything wrong in asking the community for input upfront. At least that's what I did with my calendar module and I think it was a very helpful and pleasant process: What features should a PW calendar module have? The community was just as great as it has always been. It does of course not mean to ask the community to decide every button's color. But it might help to reduce the risk of having blind spots. It might make the process even more creative, not less. It might help in making the community feel heard, accepted and valued. And it might even help in saving development time by cutting on features that sounded/looked cool at first but raised serious concerns in the community. And one more thing about the term "secret": You have some good evidence here. It was not my point though, and it might have been more constructive to ask me what made me feel like that than proving me wrong. I know I'm not the only one feeling like this. English is not my first language, but that sounds ironic to me and I'm not sure if it is the best time for being ironic after I apologised. I'm not sure how a user will feel when using dark mode for everything and some pages suddenly appear in light mode, but at least this means that it's no longer a go/no-go decision when somebody wants to use one of my modules, so thank you for that. Do i interpret this correctly as that darkmode is not any more considered to be experimental and is here to stay? --- @ryan please be reminded that I still very much admire what you have built and achieved. I'm sorry that you have expected a different feedback. But I hope it's ok to not only cheer if we like what we see but also raise our voice if we don't. Thx and all the best

I already got used to the new toggles. In some cases though they still feel wrong. Like in the example above. Also note that the description clearly says "Check the box next to ..." That means we'd also need to change descriptions across the admin. And we'd need to ask all the translators to update their language packs as well. I think a better approach would be to let checkboxes be checkboxes unless they are whitelisted to be converted to toggles (eg by applying a class like "pw-toggles" to any parent dom element).

Thx and sorry for the confusion. It was probably not the best example. Thank you for adding those. What I wanted... Not really. To be honest I just wanted to show why I think the approach you took with this theme is fundamentally wrong. Admittedly, some of my posts lately have not been very constructive, and I apologise for that. The thing is: As you can tell I'm heavily invested in ProcessWire. I don't understand why such fundamental decisions are taken behind closed doors. Why you (Ryan and Konkat) didn't reach out to the community upfront. I even asked Ryan to connect once he announced that someone is working on a new theme. It didn't happen. Why has it been a mystery who is working on this? It's some awesome goals you are tackling. Why not tell that upfront? Why not ask for feedback, concerns or help? Why not just create a module, like everybody else did in the past (AdminThemeBoss, AdminStyleChroma, etc.)? That early adopters can test, provide feedback and maybe think about some decisions before it is too late? I have been on the dev branch for years without any big issues that I can remember. I have always had a lot of trust in the dev branch. Ryan has always been very careful about any new additions. Very careful about not breaking any existing installations. Now that changed. Suddenly we had a new default theme. A theme, that turns checkboxes into toggles. That causes my modules to break, at least in dark mode. All of that enabled by default. And with all the context from the past I had the impression that there must not be much interest in feedback from the community - why else would you develop everything secretly? I'm sorry if that was a misinterpretation as you seem to be open to feedback. I'm just sad as it seems to be too late now for many things. Adding overrides one by one as they pop up still does not feel good, sorry. But I try to be more constructive with my feedback in the future.

Quoting a statement from the other thread here, as that explains a lot and with that context I can totally understand why you disagree with me in aligning css variable names with uikit less variables. In that case it's a valid strategy 🙂

Oh, that's right, it's a bit hidden 🙂 https://processwire.com/blog/posts/new-2.8-version-current-projects-and-pw-usage/ --> https://github.com/processwire/processwire-legacy Maybe you get it running like this?

@JNB the reason for this error is the same as with the other module that you disabled (by adding a dot to the folder name): Namespaces. Please check out this blog post that explains how to best upgrade a PW 2.x site to 3.x: https://processwire.com/blog/posts/pw-3.0.32/ Maybe anyone else has more experience with this topic. I don't really have 🙂 So maybe it would be best to restore the backup, then upgrade to 2.8 and then upgrade to 3.x ?!

Glad you found the issue! Please mark this topic [solved] if you find time 🙂 Thx

Sounds like $field in line 1596 is a string and should not be. I don't understand exactly. Could you please be more specific with your descriptions? Can you please add examples so that I can better understand what you are doing and what works and what does not? Could you also please describe what you mean by "works as expected"? Thx!

I hope I suggested aligning css variables and less variables, not uikit classes 🙂 At least that's what I meant! But to be honest I'm not sure about this suggestions either. I think part of the suggestion was to make it feel less wrong. Having css variables and less variables side by side just hurts and having them follow different naming conventions - if any - hurts even more. I probably hoped that having them at least named equally would make it less painful. But if that really worked at all or was even possible to achieve? I don't know. This question should have been asked long time ago. I have raised my concerns regarding css variables right from the beginning by pointing to an open request for UIkit to support css variables from 2021. Anyway - I appreciate your efforts to help to improve the situation! I hope I can add something useful: --dropdown-menu-background-color @navbar-dropdown-background UIkit uses semantic variable names. The component is called "navbar" (not "menu" like you suggest). Here are all UIkit components. Also UIkit uses the term "background" for background colors and "color" for text colors. You are using "--text-color" where - in UIkit - the "text" would be redundant (and thus left away) and the less variable would be something like "@global-color", which would tell any UIkit user that it's the text color from the global component. For an example look here: https://github.com/uikit/uikit/blob/develop/src/less/components/navbar.less @navbar-dropdown-color as another example tells anybody knowing UIkit that this is the variable for the text color of the dropdown (not the background). Now one could argue that this can be confusing for anybody not knowing UIkit, and I agree. I just wanted to mention that these conventions are there and they have been there since 2017, so any change should (have) IMHO be well considered. Following these conventions would make your variable names a bit less verbose (--top-menu-background vs. --top-menu-background-color). Though that alone can be the fuel for a lot of discussion. So I'm not sure what would be best. I still can't believe that we opened this can of worms... On the positive side, what LESS can NOT do: If you have multiple navigations on one page and you want to style them differently (eg one background red and one background blue) you simply can't do that. There is only one variable and that applies to all dom elements using the .uk-navbar class. This is where CSS variables shine! There we could do this: :root { --navbar-dropdown-background: red; } #my-custom-nav { --navbar-dropdown-background: blue; } This could mean that we probably COULD more or less stick to uikit variable names but at the same time have the flexibility to style different sections of the UI differently. Though I wonder how such a setup would be translated to the old LESS based themes. Whatever, it would result in something like this: DOM: <div class="uk-navbar-dropdown"> LESS: @navbar-dropdown-background CSS: --navbar-dropdown-background My feeling is that this would make a LOT more sense then what we have so far. But I admit I didn't think that that through, so there might be culprits. Your example on the other hand would result in this: DOM: <div class="uk-navbar-dropdown"> LESS: @navbar-dropdown-background CSS: --dropdown-menu-background-color Which does not really look beautiful to me 🙂 But maybe your setup works better in real life. In the rock theme I invented the @rock-primary color that sets several uikit variables once, for example. So I understand that we probably don't need a 100% match. As much as I would have loved to help with this, I just fear that any effort in that direction is wasted love (word pun as we won the ESC with that song recently and I have to take this admin theme stuff less seriously ^^). I guess - like you already mentioned - what is likely going to happen is that the new theme will receive updates, make use of cool new features (why wouldn't we) and then the old ones are going to die, which means many of the 1200+ modules in the modules directory will have to be checked and updated or will sooner or later break or at least look ugly in at least one theme. I think that's the reality that we are facing. To be fair: I have spent many hours already in the new theme and all technical implications and flaws aside I have to say I like it. I like many aspects, and it definitely looks and feels more modern. Maybe this step was necessary and maybe many new users will join our community. Maybe many of them will buy my modules and messing around with those new css variables and overrides will pay off one day. Who knows 😄 It's just that I didn't choose ProcessWire to make a lot of money. I chose it to enjoy my job.

Hey @wesanox congrats on your first module 🙂 I just had a very quick look and saw that your module is "autoload": https://github.com/wesanox/WesanoxFrameworkPackage/blob/b50d538b48f295133cf654838b6002cd0c006c4a/WesanoxFrameworkPackage.module#L19 Autoload means that it loads on each and every request even if you don't use it. I think you don't need this in your case. On the frontend you request it with $modules->WesanoxFrameworkPackage anyhow and on the backend I guess you don't need your module to be loaded? Oh, and I think this line is also not needed 🙂 It only tells PHP that "implements Module" refers to "Module" in the ProcessWire namespace. But since you have "namespace ProcessWire" at the top of your file "implements Module" will be enough, because no use statement means it will use the namespace of the file, which is ProcessWire.

Hi @JNB and welcome to the forum, This means that the error occurs in the file MarkupSitemapXML.module on line 3. From what I see here (not sure if that's the correct link but it's likely the same 3 lines on top) it's likely an issue with Namespaces. Maybe your old site was PW 2.x which didn't use namespaces at all, as far as I know? Not sure how exactly to solve that, but what you can try is first to delete the folder /site/assets/cache (or rename it to be able to restore it if you don't have backups, which you should 😉 ). ProcessWire might maybe apply some magic with the filecompiler to add namespaces and use that instead of your original module code. Not sure why it wouldn't do that already, but who knows... Next you can try to remove the folder /site/modules/MarkupSitemapXML or rename it to .MarkupSitemapXML This should tell ProcessWire not to load the module and it should hopefully boot up. If you get another error check the error message carefully and apply the same steps. Or others, depending on the error message 😄 Good luck!

Thx @rastographics cleaning up old todos and just found your message! did you solve your problem? Thx for the hint about the docs, I've added a link to baumrock.com 🙂

@Jonathan Lahijani just pushed this to v3.6.0 🙂

Ok so here I am again. Very sorry for that. Maybe I'm overreacting. I hope so! But I tried to go on and work on support requests for my modules just to get confronted with the next missing override (uikit progress bar) a few clicks later 😞 So I went ahead as requested and created an issue on github to collect and report all problems caused by missing overrides in the new theme. While posting this screenshot I realised something concerning though 😞 Now I'm wondering: Why are these elements actually showing up in RENO green? Why does that matter so much? Some background... So with all the context I can't believe it 😞 That's why I got so concerned when seeing these elements showing up in RENO green. (and not in the default UIkit blue from the global PW base style without any overrides applied) IMHO it shows a design layer that should not be there which shows what I'd consider to be a fundamental problem with the approach that this theme takes. So I want to add to my list from above: Can the new "theme" please use the base style (pw.less) as a foundation? I fear that the more layers we have that override each other the more complex and the more prone to errors it will get Is there any chance that the new theme properly uses UIkit hooks to add support for CSS variables instead of overriding everything? I think that the readability and the long time maintainability of the new theme would benefit a lot from that. Especially when the same convention for variable names is being used (which I already asked for).