bernhard

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).

That sounds too good to be true. I'm not sure I understand how that is supposed to work, for example: Does that mean that the sticky navbar, which is great, will somehow also be moved to the base theme to make the rock and reno themes benefit from that addition as well? Does that mean that the CMD+K hotkey will be moved to the base theme as well? If that is the case, I apologise. Because then it means that I misinterpreted the current setup. My interpretation from what I saw in the code and folder structure was that there is a lot of stuff going on in the new theme that seemed to me like it was designed to be part of the new theme only. Sorry @ryan, but this does not work! If you have a <button class='uk-button uk-button-primary'> anywhere in the backend the hover effect that you showed will not be applied to that button. If that's expected and "uk-button-primary" is not supposed to be used, then it would be great if you could add docs about how to add basic UI elements like a primary button to the PW backend in a correct and reliable way. Thx. Sorry @diogo but what might look like a simple line of css to you is actually much more. First, I can't just fallback to #000 when supporting other themes (like reno or rock), it needs to be a LESS variable. So it would probably be something like var(--text-color, @global-color). This also shows why I think it would be great for module authors to have css variables and uikit variables at least follow the same naming conventions, if we have to support both from now on. Second, this line of css is one line that was not necessary before. This might mean for many modules that they need to provide a CSS file now. Still sounds like I'm making a mountain out of a molehill? I'm not. Having to provide no css file compared to 1 css file means that we need to deal with a lot. We might need to add an additional build step. Maybe even an automated CI workflow. Or we need to add a dependency (like RockDevTools) that watches our LESS assets and compiles them to CSS that every module user can use without any hassle. These are all a lot of costs. I'm just wondering whether they have been considered. @diogo you are taking my example out of context! I was trying to explain the problems that evolve from the PW backend using different classes for different things (ui-button vs. uk-button-primary etc). And your out-of-context reply shows me that there seems to be a blind spot about the fundamental problems that we are facing now. UIkit has hundreds of classes. My point is that trying to override them instead of actually using them is a very bad idea! So please try <h1 class='uk-text-primary'>Hello World</h1> This is what I mean by the cake does not taste. Having to file github issues for all UIkit classes that are not yet "properly" overridden by the new default theme is... Not elegant. It's not what ProcessWire has been for me for such a long time. It's not fun. --- PS: Don't want to restart the discussion about details here. I just tried to respond to answers that are related to and underline what I wrote above. For me it's not about details. For me it's about the bigger picture.

What we are doing here is basically reinventing the wheel. We are trying to invent a new design system that makes it easy for developers to be used and to be customised. But we already have this design system. It is called UIkit. It is in the core. It is built on logical and semantical components (base, text, buttons, background, utilities, ...) and it has thoughtfully defined and well documented (!) variables and concepts. Yes, it uses LESS (or SASS), which is not the coolest technology on earth. But this decision has been taken by @ryan in 2017. If the decision was that CSS variables are superior and we proceed with them: More than happy! I'm using CSS variables all over in my projects (on the frontend). But keeping UIkit/LESS as the foundation and then adding a new theme with 3200+ lines of overrides just does not fit with the genius and beautiful image that I have had of ProcessWire. To me it looks like somebody was decorating a cake here. Adding layer over layer to make the cake look good. For me it just doesn't taste 😞 It never really did (ui-button vs. uk-button-primary, etc), but it was ok. It was the reality that I grew up with. Now it's different. Now things got a lot worse and I think this was not necessary. I guess I was hoping that all the effort that was put into a new admin style would bring some fundamental improvements of the overall situation. @ryan, you have pushed so many great updates over all those years and you have solved so many problems in a way that just left me behind with deep respect and amazement. Now we have yet another layer of complexity to deal with when working on backend modules. I'm not happy this time 😞 I appreciate all the effort that you put into making PW attract new users and I understand that it must be frustrating to get such a harsh feedback by some of us. Especially after putting so much work into it. The thing is: It did not have to be like this. Why not ask the community upfront? Before all the work has gone into it? To have an unbiased view? To keep the risk and emotions low (for everybody)? To hear what others might think of such a fundamental change? To get feedback and maybe even good ideas? Or to explain what is considered to be fundamental and what is considered to be experimental? The question is: What now? The decision was obviously taken long time ago, so I guess we have to deal with it (even though I think it would be the best to take it back completely). If you ask me - as a long term member and contributor - what I'd like to see to make things less painful for now and make things better long term, here are my suggestions: make the css variables used in the new theme be aligned with UIkits less variables (--main-color vs. @global-primary-background ...) remove dark mode completely, or, at least, disable it by default and add a warning that it is experimental - I think it will cause 99% of work for very little benefit add docs for the new theme and the concepts it uses rewrite the whole admin theme/framework from ground up with a modern stack (css variables + Alpine JS + darkmode) as soon as possible Thank you and all the best for the future of ProcessWire

Thx for adding some of my requests. +1! These toggles can be a no-go. And I think the current solution is a no-go as well. Imagine you are a module developer and you want (or need) to use checkboxes in one place. What do you do? Instruct all your clients/users of your module to set their backend to not use toggles? Easy solution? Not really... What if they had some modules installed that rely on the toggle-styled toggles? For example because they built an interface like this: This interface would break when using checkboxes! Because checkboxes don't have this left-right pointing indicator. I think there needs to be a better solution. And I think, again, that the new toggles look nice, but at what cost? I think we module authors have to have the option to control whether something is a checkbox or it is a toggle. This can't be the decision of the style that is being used. Maybe you can make the toggle-styles only apply to container-divs that have the class "toggle-style" or something? That would be a progressive enhancement. All checkboxes would remain checkboxes and if you @ryan decide that toggles look nicer on the page editor's settings tab, go for it and add the class "toggle-style" there. If I develop a module where I think toggles look nicer, I can add the class "toggle-style" too. But if nobody decided to add that class, we should get good old checkboxes. And a working user interface.

Ok... the list goes on Light is OK... Dark is basically a nightmare: That also means that any of my RockGrid customers (or RockCommerce, which also uses it) will not be able to use those modules with dark mode 😮 @ryan I'm "a bit" concerned... I agree that the new style looks nice. But at what cost? 😞 I'm not sure whether they have been properly considered this time, sorry. To be honest I think the decision to offer a dark mode in that way was a mistake. Or does anybody have some good ideas or answers? Am I missing any obvious solutions?

Another checkbox issue, here on my calendar module: Also the space on top of the tabs inside the modal is far too big. But I think that has been reported already. And on darkmode we see another example of how problematic using default uikit markup got with this update. I'm using "uk-background-muted" for the "enter time" and "enter range" elements. These visual helpers get lost on dark mode:

Hey @ryan I'm preparing to add some new features to RockCalendar (looking at you @FireWire 😉 ), so I thought it's a good opportunity to see how it works with the new theme! As you can see, the light mode looks a lot better and the dark mode totally loses the day headlines (Sun, Mon, ...) Could you please share some information how we as module developers can make our modules work with the new style? It might sound easy for you or the style authors or any CSS ninja out there, but it might not be easy for backend-focused devs. In this specific case I'm wondering: How can I make the headlines show up properly in dark mode? Which color would I set? Which css variable would I use? How can I make buttons like "today" and "left / right" at the top right look like all other buttons (like publish, for example)? Regarding the buttons I'm quite confused for a long time and it might be the right time to mention it now: Many buttons use "ui-button" as class. As far as I understand this was the class coming from jQueryUI and with the old style this was giving it some rounded corners (compared to default uikit buttons). Then UIkit was added to the mix and from that time on I thought we can use "uk-button uk-button-primary" to style our buttons. At least to get matching colours. That meant that anybody using admin.less to customise their backend and changing the primary color saw a button in the primary color. Now we have another layer on top. A style using CSS variables, overriding UIkit, which overrides jQueryUI. This might be wrong - I don't yet understand how all of them play together and which layer overrides another, but I think you get my point and I'm happy to be corrected or get an explanation of how these layers are supposed to work together. May I also ask for some help or explanation how we can deal with that to provide good and reliable modules? What classes shall we use for which elements of the UI? This also brings me back to this question I raised earlier regarding all the UIkit UI components: Most likely it's something that PW doesn't use, so it isn't styled, but I'm sure it can be. I think we do use uk-alert boxes, but always of a type like "primary" or "warning" or "danger", etc. So maybe we just need to add a style for alerts that aren't of a specific type. To be honest I'm very confused about your statement, so it would be great to get some more details here. I understand that jQueryUI has been used for several aspects of the admin (like the drag&drop etc). And I understand why UIkit was added to the mix in 2017. What I do not understand is how UIkit is supposed to be used by us developers now. Using ProcessWire as the CMS of choice does not only mean to use the backend and all its features as is, it also means (for me and I guess many others) to build something on top of it. This does often not only involve the frontend (where we have full freedom), but also the backend. It might involve adding some details here and there via hooks, it might involve building custom inputfields or it might involve building custom process modules (aka custom admin pages). I always thought that having UIkit as a common ground is something that I/we can rely on. At least as long as the UIkit theme would be supported. That meant to me, that I can build anything for my clients (both direct clients or clients using my modules) that is based on any of the UIkit components listed on their docs (eg https://getuikit.com/docs/accordion). Now your statement makes me wonder whether that is still the case. It sounds a bit like that some components are simply not supposed to be used, which would be unfortunate and less than ideal, in my opinion. I'm a bit confused and afraid how I would ideally build a module (or upgrade any of my existing ones, which are a lot...) to make them work well with the new style, the old default style and maybe also the rock style, if anybody prefers it over the others. As you stated several times anybody is free to choose whatever admin style he/she wants. But that means in return for me as a module developer that I have to support all these options. When using UIkit, there are some proven standards that the company Yootheme defined. We have "uk-button-primary" for primary buttons. We have "uk-text-lead" for slightly bigger leading text. We have "uk-text-muted" for subtile grey text for explanations and such. We have tooltips to add additional information on hover, etc. All this is documented well on their docs. So it is obvious for anybody how to use it. It is not obvious to me any more in how to use anything related to UIkit when I have to expect that at least one of my clients/users might possibly be using the new style and might possibly be using dark mode 😞 For example I just added this hook to ready.php: wire()->addHookBefore('Inputfield::render', function ($event) { $inputfield = $event->object; if ($inputfield->name != 'title') return; $inputfield->description = '<div class="uk-text-lead">This is a test</div>'; $inputfield->entityEncodeText = false; }); Which renders fine in light mode: But does break on dark mode 😞 I wonder what the idea is to solve such issues? Are we supposed to NOT add any standard-UIkit markup to any of our backends that is not part of the PW core admin theme and that is not supported by the new style? Or are we supposed to add custom css overrides for such cases to our modules? Or are we supposed to report such issues whenever we find them and then wait for you or the authors of the new style to add support for it? Or do you think the the new style could be improved to support default UIkit markup without breaking? What would be the correct way to add a slightly more prominent intro text to my title field that works properly across all new and old (uikit based) styles? Thx in advance - it got a bit long, sorry! But this change basically effects years of my work...

Hey @marie.mdna sorry for the delay. I was sick and had to have some days off the computer 🙂 Thx! And thx for your question! The answer to these kind of questions is probably always the same: Yes and no. Yes, you can for sure build such a scenario. No, not out of the box. It's similar as if you asked "does ProcessWire support selling digital goods?" RockCommerce tries to be a good foundation for selling anything online and using ProcessWire to manage all the data. So it will handle the basics for you that are the same for any store that I can think of (meaning handling orders, for example), but everything else usually has to be built by the developer. With product variations being one exception as not every store might need it, but if it does, it would be an absolute nightmare to have to build it on your own. So to answer your question: Just have a look at my website - I'm doing exactly that! You can buy my modules there. Once you buy one, the store sends you an email with the license key. The mail is sent by WireMail, the logic for the license key is built on my own. The invoice is created using RockPdf. The thing is: Every shop is different. Every business is different. How long is a license valid? What does it allow? Etc, etc. I tried to provide a good foundation that saves you a lot of time and makes a lot possible with the least possible effort. Just like ProcessWire does with the $page magic and the admin interface to manage content. Does that make sense? The great thing about RockCommerce is that when using it, you have all your data in ProcessWire. You control that data, you define its structure. And you can easily add your own business logic on top of it - exactly like you want. So many things are just some lines of ProcessWire API away 🙂 But that also means that you might have to build that logic on your own, that other shops might already have built in. In the way they think is best, of course 😉 Which might fit your needs or not... I have added this to the docs: https://www.baumrock.com/en/processwire/modules/rockcommerce/docs/checkout/

So happy to hear that, thank you 😍 Would be great to see what you built!!

Great you got it working and yeah, if you need to compare multiple values, then having all available in the $page object in saveReady sounds like a good solution! Some notes here: I think this is the same as just using pages()->getFresh($page) ? I think the variable name $cachedPage is not ideal, because it's actually the non-cached page. It's the page fresh from the DB, not the cached copy that lives in memory I don't know this syntax: $actualPlace = $page->get('location_place', 'text', ''); And in hooks I tend to avoid nested IFs, so you might consider refactoring your hook to this (though yours is absolutely fine, of course): <?php // Ensure first three chars of the required field 'location_place' can't be changed. $wire->addHookAfter('Pages::saveReady(template=location)', function (HookEvent $event) { // Ensure we have a valid page. $page = $event->arguments(0); if (!$page) return; if ($page->isTrash) return; // Load old page from DB $dbPage = wire()->pages->getFresh($page); // Get actual field values (required) entered by the user. $newPlace = (string)$page->get('location_place'); $oldPlace = (string)$dbPage->get('location_place'); // if new and old value match --> nothing to do if (substr($newPlace, 0, 3) === substr($oldPlace, 0, 3)) return; // otherwise reset location_place to previous value and show an error on the inputfield. $page->location_place = $oldPlace; $inputfield = $page->getInputfield('location_place'); $inputfield->error('First three characters can not be changed. Input reset to previous value.'); // If you prefer less drama, just show a message instead of the error state on the input field itself. // $event->message('First three characters can not be changed. Input reset to previous value.'); }); But when checking for multiple values it might be better to use if(...) { ... } multiple times as early exits won't work in such a scenario 🙂

Maybe it's a caching issue. The navbar in the backend has unfortunately very aggressive caching built in, so you need to either log out and log back in or you use tracydebugger:

All good so far, no worries 🙂 Just wanted to say it early enough to not bloat this thread more then necessary. Thx and good luck!