Chris Bennett

Nice one! Will keep that in mind for future as well. if($inputfield.hasClass('InputfieldIgnoreChanges')) return false; That said, it wouldn't have quite fitted my needs as I wanted it to be saved after the first ignore, so I would have had to remove the class anyway. Would definitely come in handy elsewhere.

Reminder to myself to occasionally step back and think about what I am trying to do. Background: Working on an autocomplete function using google places. Allows clients or me to fill out boring address block and accurately geocode all at once from single input. No repetition, no fuss, for single business or multiple branches using repeaters. Not at all necessary, but figured why not, feels kinda nice and will not be costing me anything tucked away in the backend. "Problem" and ridiculously easy solution: Was working nicely, except when using enter/return to choose location, as save was getting fired on original input, throwing off the auto-filling. Stupidly, I spent too much time trying to chase down php and api solutions, using many hooks without success attempting to prevent the page and field from saving. Finally, feeling like a dumbarse, I took a step back and cursed my silliness. Yep. If the thing you want to work around is javascript, maybe try javascript to work around it. In the end, much to my embarrassment, the solution I sought was adding a few simple lines of js. Define the form, and preventDefault on the form's submit once. I cringe at how I missed the very simple solution while looking for the complicated workaround. Won't be the last mistake I make, by a long shot, but hopefully the last time I make this particular one :) window.addEventListener('focusin', function (event) { const input = event.target; if (input.classList.contains('autoComplete')) { // Below, the 4 very simple lines I should have thought of much, much sooner const form = document.getElementById('ProcessPageEdit'); form.addEventListener('submit', function(e) { e.preventDefault(); }, { once: true });

Hi wise ones, have been going round in circles for a while, so figured I'd ask it's possible before going down the rabbit hole again. If it is possible, I'd love to maybe get a nudge in the right direction. I'm playing around with multisite using index.config.php and I can't get the usually simple symlink stuff for CSS/JS etc working. Have confirmed that I can access the directories and files and create the symlink. Unlike single site install, which has always been delightfully simple, I can't seem to get it working. Am I missing something really obvious or does it just not work because of the index.config.php symlinks to the site itself? As always, any pointers in the right direction are much appreciated.

No worries Joe, yep Devtools is surely a little confusing at first, but once you get familiar with it, life gets easier. Definitely a very important tool in your webdev toolbelt, so the more you get used to it, the better. It will tell you about your javascript errors, show you what is getting loaded, from where, what is missing, let you know what your CSS is doing and all manner of stuff you need to know. The header problem might have gone away by simply renaming main.css if your page could no longer link to the CSS that was causing the problem. No idea which site profile you started with, but if you, for example, renamed main.css to anythingelse.css and didn't update the link to the css in your page with the renamed file, then the page rules set in main.css would no longer apply because they wouldn't be found. So something along the lines of: #masthead-logo img { /* image for masthead logo */ width: 100px; } would simply disappear removing the width restriction on that element.

Hi @Joe_H. You can make whatever CSS changes you want to main.css, it is very much a starting point. Devtools in your browser of choice is really useful when troubleshooting why something isn't behaving how you want. Right-click on the culprit, inspect element, and the CSS involved is all there, which you can alter at will to test possible solutions You can also add as many links to your own CSS as you want by following the general method set out in _main.php. <link rel="stylesheet" type="text/css" href="<?php echo $config->urls->templates?>styles/whetevernameyouchooseasyourdefault.css" /> Processwire is not very opinionated at all on what you do with the data, so frontend styling is not something dealt with in the admin console by default. Basically, all you need to do is tell processwire what file to get and it will get it for you, but what you put in there is gloriously and flexibly up to you. All the fun stuff is up to you, processwire will just throw in data where you tell it to.

Thank you to both @Zeka and @Robin S. I finally troubleshot my own head-scratcher to the point I was able to search for the right thing and, of course, was not surprised to find Robin involved in the exact answer I was looking for. You are both legends.

Yes, you are absolutely correct that the nonce should be unique for each HTTP request. The nonce is basically just a handy way to load a number of scripts from different domains and have those permissions filter through to other scripts that might be loaded by the allowed scripts. So for a static page you'd probably want to go with the url allowlist method instead, similar to the $hasMapStyles / $cspStyleSrc combo.

Sorry @DV-JF I can't be sure as I don't use ProCache. I can't imagine why it would, but I just can't say for sure. If there was a problem, I guess nonces could be replaced by URLs instead. Naturally, you'd want to make sure your CSP settings are suitable for your site or the devtools will quickly fill with lots of red :)

2021 update: bit easier, better security, no warnings about using <meta http-equiv="Content-Security-Policy">. Rather than rely on <meta http-equiv="Content-Security-Policy"> I have tweaked things a little. Bit more secure, bit easier to do and added nonce function as well to further lock down script-src. If we remove all CSP from htaccess we can define everything in one place and set header() with php instead, right before <!DOCTYPE html> I find it cleaner and easier to customize that way. Allows as much logic and conditional loading as you need. For example: <?php if ($user->isGuest()): $loadMap = $page->name === "map"; $hasMapImgs = ($loadMap) ? " https://*.googleapis.com https://maps.gstatic.com https://*.ggpht.com" : ""; $hasMapStyles = ($loadMap) ? " 'unsafe-inline' https://fonts.googleapis.com" : ""; $cspImgSrc = " img-src 'self' https://www.google-analytics.com data: 'self'" . $hasMapImgs . ";"; $cspStyleSrc = " style-src 'self'" . $hasMapStyles . ";"; $cspCond = $cspImgSrc.$cspStyleSrc; function generateRandomString($length = 25) { $characters = '0123456789'; $charactersLength = strlen($characters); $randomString = ''; for ($i = 0; $i < $length; $i++) { $randomString .= $characters[rand(0, $charactersLength - 1)]; } return $randomString; } $nonce = generateRandomString(35); $csp = "Content-Security-Policy: base-uri 'self'; frame-ancestors 'self'; default-src 'none'; child-src 'self'; manifest-src 'self'; form-action 'self'; connect-src 'self' https://www.google-analytics.com https://maps.googleapis.com; font-src 'self' data: https://fonts.gstatic.com; frame-src 'self' https://www.youtube.com; script-src 'self' https: 'unsafe-inline' 'nonce-" . $nonce . "' 'strict-dynamic';" . $cspCond ; header($csp); ?> <?php endif; ?> <!DOCTYPE html> https://observatory.mozilla.org/analyze/www.alfresco-bar-bistro.com.au

Sweet! ? I love your work and many, many thanks! Although I am disappointed not to be able to use Option B: Percentage based, this at least got rid of the plethora of inline width declarations and the very unwanted maxColHeightSpacer div. Also helps narrow down where the issue might lie. Maybe something about the upgrade has 'reverted' the B option to use the older js inline width and height declarations? Or perhaps a newly added feature to deal with some use-case. Either way, I am stoked for your help and mightily relieved. Love your work, you are a legend!

Thanks Robin, I will have a play with that. Anything to help me avoid the pain and unnecessary layout shift is welcome. That said, I was definitely previously using the Percentage based widths option.

Thanks Robin, I appreciate your comments. I have never used any theme apart from AdminThemeUiKit and 100%, the inline styles are injected by js. My confusion comes from them not being injected in this way in the previous master dev. It's why I was surprised both the inline styles that hadn't been there previously and maxColHeightSpacer suddenly appeared after upgrading from 3.0.165. In fact, looking again, both maxColHeightSpacer and style="width: 35%;" data-original-width="33" are being added on the same custom module. Previously it had been a perfectly horizontally aligned radio inputfield, with a simple data-colwidth="width: 33%", which could be over-ridden easily allowing margins and borders and fun stuff. On upgrade, it suddenly had a 24px vertical spacer div inserted underneath, flex alignment was thrown out, and the style="33%" meant it wouldn't flex properly any more. Examples shown using my tweaked AdminThemeUiKit theme. Admittedly, I have played around with AdminThemeUiKit for probably way too many hours. I guess it has to be in the 1000's by now ...sheesh... That means very little, except to say I am pretty familiar with how it works, what it does and how it does/did it. Results are the same in default AdminThemeUIKit. Example: Post upgrade, pre addition of formerly unnecessary !important overrides. Example: Post upgrade, after a long string of formerly unneeded !important declarations applied, back to what it had previously looked like. But throughout the admin, wherever there was formerly a simple data-colwidth, there is now a new inline style declaration. It's the new bit that I don't get. I don't understand why the js injection wasn't necessary for 3.0.165 but needs to be there for 3.0.184.

Hi all, have just upgraded to 3.0.184, a little late to the party. Not sure about a few things and would love to understand better. It seems to me like there is now an increased over-reliance on inline style width declarations on Inputfields. To me, they seem like extra bits of unnecessarily specific css that impede easily customisable CSS. I can't wrap my head around why they are needed. Surely CSS and flexbox can do this better, easier, with much greater flexibility, less javascript, less thread work, less bytes and less layout shifts? In previous versions, data-colwidth on everything with a width worked just fine. Was very easy to target li[data-colwidth] and use calc to add a margin if desired and use flexbox to flex like a champion, taking up available space. Lovely, simple, flexible and lightweight. Now it seems some wrappers have a style="width: ..." where once they had data-colwidth and some Inputfields have data-original-width. Each can technically be over-ridden using ...sigh... a multitude of repetitive !important declarations, but that is not ideal. Is there something I am missing? Is there a reason the inline width styles were needed? Is there a benefit I am unaware of? Can I help provide possible alternate solutions to whatever use case necessitated it? In a similar vein, I also got to see maxColHeightSpacer for the first time. Can't say it was a pleasure for it to appear. Similar to the use of inline style="width:..." on Inputfields, in the age of flexbox I don't understand why a spacer div with inline height is needed. Is there a need for it I just don't get? Hadn't seen it before but found some info from a few years ago here: Anyway, I would honestly love any insight on any of this. Would love to understand the 'why' and, if possible, help.

Thanks to the excellent feedback from @matjazp , have re-vamped way the whole module works. Minimizes potential conflicts and was just a better idea. Now draws CSS variables, conditionally loaded source CSS and framework CSS together to generate single minified CSS file, with version control link to refresh cache for other pages. Only occurs when the module is visited, as it should, and after that other pages draw the minifed CSS straight from cache. Now loads in parallel with other CSS. at somewhere around 30ms, same as other CSS files. First load (in the module itself, not subsequent pages) comes in around 17 kB compressed (somewhere around 96kB uncompressed and with all options selected), so considerable improvement, especially given the elimination of almost all processing overhead. Very happy I was prodded into action. Took a little time, but I am much happier going forward. As part of the re-working, I am in the process of splitting up CSS for conditional loading according to user selections. Opens up a far greater range of user options, which I am rolling out to module as I go. As a bonus, splitting the source CSS up is making it easier for me to track and alter, allowing me to simplify the CSS and balance specificity better. Always nice when file sizes are going down, not up even though you are adding new stuff :)

https://github.com/chrisbennett-Bene/AdminThemeTweaker Inspired by @bernhard's excellent work on the new customisable LESS CSS getting rolled into the core soon, I thought I would offer up the module for beta testing, if it is of interest to anyone. It takes a different approach to admin styling, basically using the Cascade part of CSS to over-ride default UiKit values. Values are stored in ModuleConfig Module creates a separate AdminThemeTweaker Folder at root, so it can link to AdminThemeTweaker.php as CSS AdminThemeTweaker.php reads the module values, constructs the CSS variables then includes the CSS framework Can be switched on and off with a click. Uninstall removes everything, thanks to bernhard's wonderful remove dir & contents function. It won't touch your core. It won't care if stuff is upgraded. You won't need to compile anything and you don't need to touch CSS unless you want to. It won't do much at all apart from read some values from your module config, work out the right CSS variables to use (auto contrast based on selected backgrounds) and throw it on your screen. You can configure a lot of stuff, leave it as it comes (dark and curvy), change two main colors (background and content background) or delve deep to configure custom margins, height of mastheads, and all manner of silly stuff I never use. Have been developing it for somewhere around 2 years now. It has been (and will continue to be) constantly tweaked over that time, as I click on something and find something else to do. That said, it is pretty solid and has been in constant use as my sole Admin styling option for all of those 2 years. If nothing else, it would be great if it can provide any assistance to @bernhard or other contributor's who may be looking to solve some of the quirkier UiKit behavior. Has (in my opinion) more robust and predictable handling of hidden Inputfields, data-colwidths and showIf wrappers. I am very keen to help out with that stuff in any way I can, though LESS (and any css frameworks/tools basically) are not my go. I love CSS variables and banging-rocks-together, no-dependency CSS you can write with notepad.