teppo

Yeah, edited my message as well. Didn't read the original question properly, thought it was only about templates. Just gave these both a try and so far they seem to work – though this is a rare use case, so wouldn't be entirely surprised if there were some gotchas along the way ?

Don't think I've ever used this, but according to the ProcessTemplate core module the template part should be possible if you create a new "template-admin" permission and assign it to any non-superuser role. Based on a quick test it seems to work. ProcessField supports similar "field-admin" permission, which might give you the expected result regarding fields. This does seem like a rather unlikely need, so I'd first check if this is really what you want. Certain tasks are limited to superusers for a good reason ?

What you're seeing there is just what happens between browser and server, i.e. spaces getting replaced by %20. If you're echoing the value, it won't get executed as PHP code (you'd have to call eval or something similar to get that effect), but it could still allow HTML or JavaScript through – which is probably also something you don't want to allow. For an example, see what happens if you set the key value as <script>alert("hi")</script> instead. The general rule of thumb is to always sanitize user input ? That being said, if you're certain that you're only reading the GET variable and comparing it to some pre-defined value, and you'll never store or output it as-is, then there's no real harm in not sanitizing it. As you've proven yourself, it won't get evaluated as PHP code.

I'm not entirely sure about the "non well formed numeric value" problem, but your version of ProcessWire (3.0.32) actually predates our current GitHub repository, which means that it's ~3 years old – I wouldn't be too surprised if this was something that has since then been fixed. Of course it would require a bit of testing, but I'd suggest updating your site to a more recent version if possible. Countable notices are also problems that have been fixed in the dev branch, see this issue: https://github.com/processwire/processwire-issues/issues/408. If it's the same issue, this is due to a change in PHP 7.2, where they changed the count() behaviour in a backwards-incompatible way. Note that at least some of those countable-related fixes are currently only fixed in the dev branch; in the case of ProcessWire the dev branch tends to be quite stable, but if this is a production site you may still consider living with some of these warnings until these fixes are merged to master.

I wouldn't necessarily recommend making www-data the owning group of the entire directory, but that's just me. As long as the group doesn't have write access to all files, that doesn't really make matter a whole lot. Technically Apache only needs write access to /site/assets/, and (if you want to use the built-in modules installer in Admin) the /site/modules/ directory. (Latter is something I personally never allow, as I don't think it's worth the risk.) Anyway, in my opinion the setup you've described above should be safe. When configuring the permissions of a system like this, there are always two important factors: Are there other users in addition to you who have access to the system, i.e. is it a shared system? If so, giving "others" write/read/execute permissions can sometimes be problematic, as it could technically allow any logged-in system user to access those files – though in shared systems some sort of jail mechanism is usually implemented to prevent this. Also, I'm assuming that this isn't the case here, since you've mentioned setting up the server yourself. The Apache user (www-data) is what most "third parties" will technically access your site with (through the web server). While ProcessWire is known to be exceptionally secure, it's still a good idea to limit the excess to which this user/group can access (and particularly write to) content on your server. For an example, I prefer not to give www-data write access to directories that contain executable code, such as /site/modules/ (as mentioned above). In the case of ProcessWire www-data needs write access to /site/assets/files/, or at the very least specific directories below it. It also needs read access to most files on your site. So yeah – your settings make sense to me ? This is strange: it seems that a file or image field on your site is saying that the assets/files/ directory it's trying to write to is not writable. I'd start by checking which user/group is the owner of the /site/assets/files/[page ID]/ directory, and if it's writable for www-data. Same thing for the /site/assets/files/ directory. Alternatively: is it possible that sometimes the user actually isn't www-data? Just guessing here, since I'm not familiar with your particular setup. Edit: just realised that in your message above you mentioned adding chmod 664 to all files within /site/assets/. Please make sure that group has write access to directories as well – otherwise you'll no doubt run into problems.

Actually the API provides access to the hashed password. If this password hash (the one you use for your secure URLs) needs to remain constant, I guess that's as good approach as any – mash some non-public variables together, generate a hash, and then check if the user has provided the correct hash. If you're looking for a ready-made solution I'm not aware of one, but on the other hand this sounds like something you could put together in a few lines of code, so not really a massive problem. The specific implementation depends on how your site is built, but technically you just need to add a bit of code somewhere before any markup is rendered – check a GET param from $input->get->token_var_name, and then compare that to a correct token (or one stored in user details – more about that in the list below). I would probably use URL segments here, so that first segment contains the username and second one the token, though. If there's a match, do something (display page content), otherwise throw a Wire404Exception (preferable over displaying a clear message such as "wrong token"; you don't want third parties to know even if they got the username right.) Some additional steps to consider, mainly for security reasons: Instead of calculating the token on the go, you could generate it automatically for every user, and store it in a custom field added to the user template. This way you can also include random data in the original hash, which means that it cannot, under any circumstances, be used to uncover (hashed) passwords or any other type of sensitive data. Note: this would still mean that the token is stored in the database as-is, which would become a problem in case this information ever leaks. Technically the safest thing to do might be to send the private token to the user, and never store it as-is, but rather convert it to a hash using a salt and then store those locally ? Add some sort of brute force protection to the page, i.e. after a few incorrect attempts block the IP for a while. Preferably refresh (recreate) tokens after a set amount of time. This may not be particularly important, but personally I believe it's a good practice in these sorts of situations. Provide a way for users to change (reset) this key, in case there's a chance that someone else has gained access to it. Preferably this new key should also be randomly generated, so that users cannot manually type in a weak key. Use username or some other value in the URL itself, so that keys become much harder to guess (via brute force attack) – but also make sure that third parties can't use these URLs to collect a list of existing usernames ? ... although the security level of course depends on the type of information you're providing via this calendar. If it's not particularly sensitive data, then it won't be such a big deal, but if there's a chance that it may, for an example, contain personal data, then definitely take every possible precaution.

The easiest approach might be setting the owner of the whole /site/assets/ directory (and everything in it) as the Apache user (www-data:www-data). If you want to retain easy write access to those directories (without sudo), you can set your own user as the owner, the owning group as www-data, and change the permissions for that directory to 664 instead of 644 – though depending on your setup when www-data creates new files and directories, it will likely overwrite the owner for those files anyway. Usually this isn't a problem, though, since you shouldn't upload files to /site/assets/ manually, and even then it would only be limited to files that www-data is already managing ?

Thanks for pointing these out. Latest release (2.1.0) includes improvements to spacings and the position of the triangle. Just for the record, the positioning is of the triangle was actually intended to be consistent with Admin Theme Uikit, where it's also off-centre, but I've now centered it in Admin Bar anyway ? In 2.1.0 the problem with "add new" button has been fixed. My initial idea was indeed to leave these buttons out if they have no purpose, but opted to leave them as-is, because that's how it's always been. For the same reason I was slightly hesitant to remove the full stop: this change will break existing translations. I've now done it anyway, since it's a relatively small thing. Note that 2.1.0 is actually bigger update than I anticipated. Class names have changed a bit, all themes had to be updated slightly, there's new JS, layout is now based on flexbox instead of floats, etc. So far things seem to work as expected (better than before), but let me know if there are any new issues ?

Yeah, this should be an easy one. You can hook before or after AdminBar::getItems: either modify $args['strings'] before it gets passed to the method, or modify the resulting array of items before it is put to use ? Makes sense. I would definitely take a route that affects actual permissions. Since AdminBar checks Page::editable() before displaying the edit link, if this was done using permissions, I believe it should just work out of the box, i.e. the edit link shouldn't display at all ?

Thanks, @adrian. I've been using this module for a long time, and it has actually been quite fun to work on it ? A profile edit button seems like a good idea. That was on my list for a while actually, but I wanted to get 2.x out sooner rather than later, so had to leave that for a later release ? I think we'll also need a "select enabled links/features" option to avoid too much clutter. On many (most) of the sites I've built this feature, for an example, profile edit feature wouldn't have been particularly useful – users often edit their profiles really, really rarely – so I'd like to leave it to superusers to figure out which features are necessary. (Could also make the feature selection configurable per user, if there's demand for such a feature.) Restricting editable pages to ones the user has created seems to me like a relatively specific need – at least I haven't personally come across a project where this would've been particularly useful. As such, my initial view is that this might be best implemented as a per-site customisation. Unless, of course, I'm wrong and it's actually a commonly needed feature, in which case it may make sense to add a setting for it ? Note that one key point about the hooks I've added is that it's now quite easy to customise what is displayed in the Admin Bar, and how. One example of this is what I've done with the "Uikit" theme, where I've added icons to existing items, and also the PW logo/mark as a new item. If you hook into AdminBar::getItems, you can easily modify the list, and – for an example – only show the edit link under specific circumstances. (And if this is a feature you require often, you can always bundle this, and any other modifications, into a separate module.) By the way, I'm assuming that this would actually be just about displaying the edit link – not modifying permissions? Modifying permissions would, in my opinion, definitely belong to another module. As far as I can tell, this item has been "Browse" since the beginning – at least for the past 8 years or so, according to GitHub ? I'm slightly hesitant to change what I consider established terminology. Also, I don't personally see the problem: technically what this item being active means is that you're currently browsing the site. Kind of like "browse mode" vs. "edit mode". When you're in admin and want to view a specific page, "view" is indeed better word, but in this context I actually prefer "browse". Again it's quite simple to modify this with a hook, of course, but I think I'd rather stick with current terminology for the default state.

It's quite possible that I've misunderstood what you're saying here, but if by "restricted permissions" you mean current settings (755/644), then I don't really see a problem here – as long as the Apache user (apache, www-data, or whatever it is called in this case) is the owner of the FileCompiler directory and compiled files are created by this user (via web requests), it should work just fine ?

AdminBar 2.0.1 released: Plenty of updates behind the scenes. So far "end user" functionality remains largely the same, though. New options for hooking – decent support for modifying generated output and adding all-new links and other features programmatically. Extended theming support: the module now comes with three built-in themes ("original", "tires" per the theme submitted earlier by @tires, and "uikit"). Uikit is an adapted version of the top bar in admin, and it's now the default theme for the module. Each theme may include its own settings (Uikit, for an example, allows displaying/hiding some or all of its icons and the ProcessWire mark). Custom theme support is still there, but requires a few modifications: custom theme needs to be selected via module config screen, you need to provide a directory where theme files live, and this directory has to contain (at least) a theme.css file (but optionally also theme.js for custom JS, theme.php for hooks, and config.php for custom module config settings). Oh, and the module is installable via Composer now – just run "composer require teppokoivula/admin-bar" in your sites root directory, or the /site/ directory. New requirements for 2.0.1 are ProcessWire >= 3.0.112 and PHP >= 7.1.0. For earlier version of ProcessWire or PHP, use release 1.1.5 (this version won't be updated anymore, but should work in ancient version of PW and PHP). Below is a screenshot of the "Uikit" theme in action on the Wireframe website. In this case I've disabled the icons from the left side of the Admin Bar – by default each action there would have its own icon as well.

644 means that only owner is allowed to write to the files. I'd start by checking if you already have matching files (the ones mentioned in the warnings), and if so, which user is set as their owner (and if the permissions to said files is really 644). In case the owner is not the same as the Apache user, that's likely the problem here. If you've migrated these files with the site, a safe bet would be to clear everything within the FileCompiler directory to get a "blank state" – but if permissions are too strict, that obviously won't help for long. (Note: if you sometimes run ProcessWire via CLI using the bootstrap method as another user, that can also result in these compiled files being owned by the user you've executed that CLI command with, which can cause similar issues.)

Not an answer really, but technically just having ProCache could help with situations like these. The idea is to bypass PHP and MySQL entirely, after all. In fact in the past I've had a situation where MySQL was dead but the site I was monitoring kept working due to ProCache, so the issue didn't become apparent for quite a while... ? Another thing to consider would be something like Cloudflare ("always on" feature in particular), or adding Squid or Varnish (or some other proxy/cache/accelerator) in front of the site.

If you update to module version 0.9.0 (latest release), you can ? More details here: https://github.com/teppokoivula/SearchEngine#rebuilding-the-search-index. Note that indexing the pages is also possible via module config screen. There's an option for "Manual indexing", where you can either index all indexable pages, or those matching a specific selector.

Added a note about new maintainer to the top of the first post, and updated the "grab the code" link. Might make some sense to rewrite the first post altogether, but the forum doesn't (as far as I know) allow replacing it, so creating a new support thread might make sense as well ?

Makes sense to me. To be honest the two things I was mostly worried about with Tailwind were repetition and consistency, but the component approach should definitely help with that ? I wouldn't really describe Foundation as a full design, because the "normal" workflow with it involves more configuration than overriding. That's the main reason I preferred Foundation over Bootstrap and early versions of Uikit: "randomly" overriding what someone else was already doing always felt dirty, and at least in my experience (based on maintaining Bootstrap sites built elsewhere) was somewhat prone to problems... particularly when things had to be updated "upstream" to fix problems within the framework itself. Haven't been keeping tabs on frontend frameworks lately, but at least Uikit seems to include something similar these days with their SASS/LESS builds ? We've been crafting styles mostly from scratch. We have what you might call a frontend framework, but it's relatively unopinionated – mostly just stuff like common file structure, build process, font size management, image helpers, and some utility features. One of the benefits of that approach is that each site gets exactly the styles it needs, while one obvious downside is that there's a lot to do. In my experience this approach works well for very large or very simple projects: you're essentially building your own component library for each site, so you need either big enough budget, or reasonably narrow scope.

Some updates for AdminBar in the latest release (1.1.0): Got rid of the jQuery dependency. Not a big deal, but that's still one setting and one dependency less. As a result the module probably won't work as expected in IE < 11, so if someone is still stuck with ancient browsers, it's better to stay with version 1.0.7 (tagged in the GitHub repository). Some minor optimisations and tweaks here and there. Nothing major, really. Just tested @tiress styles, and they seem to still work as expected, so most custom themes are likely unaffected ? For the record, I'm thinking of releasing a 2.0.0 of this module pretty soon. This would be a breaking change, and require ProcessWire 3.x, PHP 7.x, etc. I'm also thinking of moving custom styles out of the module directory so that the whole directory can be safely removed during updates.

I should definitely give this a proper try ? I was actually writing a longer question here, but then I found this: https://tailwindcss.com/docs/extracting-components/. One of the benefits of BEM approach has been that when a site has been designed with components in mind, it's easy to start from the lowest level ("button looks like this"), and then re-use the same element. For big sites in particular this is quite nice, while you can still create variations of those elements for use in specific situations (.button--cta, .button--success, .button--click-to-call, etc.) It looks to me like you achieve a very similar result with Tailwind. Please correct me if I'm wrong, though ?

Thanks for reporting this. I'm not quite sure why the Modules Directory won't recognise the module version properly, but I've now updated it manually and so far it seems to stick. The info JSON examples at the API ref show a format that isn't actually supported by ProcessWire itself, so it's a possible that this is a bug in the modules directory parser ?

Don't worry, that's not a bad sidestep ? I mean – sure, I've seen folks take a library or framework that perhaps even boasts about being "accessible" and implement something with it and actually think that they've now got it all handled. While that'd be nice, in reality we're far from that. Where I currently work we care a whole lot about accessibility. Part of that involves not believing everything third parties say, but actually validating the services we build, and making sure that they are up to standards. For an example I'm currently not aware of a carousel plugin that would properly fulfil WCAG level AA – let alone AAA – out of the box. While I'm kind a Slick fan myself, even their idea of a11y is rather cringeworthy: Yeah, because that's all there is to accessibility, right? Similarly one of the biggest issues I see with a lot of these modern web-apps (or whatever you choose to call them) is indeed exactly that gross neglect of "proper markup", and all that follows: "Can't we just use something generic and sprinkle it with some magic dust to make it accessible? Isn't that what ARIA and all that stuff is for anyway?" Sure, assistive technology has been evolving and these days it is indeed possible to tell the browser that a div is a button. Tricks like that might not work everywhere yet, but support is likely to increase. Regardless there are all sorts of problems with that approach, one of the biggest ones being is that we're essentially offloading accessibility and usability to someone else and expecting them to catch the ball where ever and when ever we decide to drop it. And then there's the problem that something as intangible as accessibility – or usability for that matter – is really hard to summarise into a set of algorithms. Each and every case is different. It's a lot like assessing code quality programmatically: sure, to a point it can be tremendously helpful, but the reality is still that (for the time being) we still need humans to complete the assessment. Tech alone is not the solution. I know there are some parallel topics going on here and this was perhaps related to another idea altogether, but: this is a very good point, in my opinion. "React made me do it", or "it's like this because components" are not very good excuses to mess things up. It's just tech, and particularly unopinionated tech for that matter. The problem isn't React or components – it's how people use them ? I feel that this is again very much related to the stuff Brad Frost wrote about in frontend design, react, and the bridge over the great divide. To summarise, even though these days "frontend" goes way beyond HTML+CSS(+JS) and simple GUI level tasks/responsibilities, there's still plenty of demand for so-called frontend designers. Folks who are specialists in crafting that clean, semantic, usable, accessible, and (in the long term) likely maintainable "front of the frontend" layer. That's roughly the direction I've been going on for a while now. With a few twists. We discussed Tailwind with Antti a while ago, but I've yet to try it on a real project. Some of the examples I've seen look kind of horrifying, but admittedly I've recently found myself gravitating towards the general idea of utility classes. Perhaps it's the sort of sites I work on, but one key problem for me is that I often find myself using same components (there's that word again) over and over again. So far I've found this easiest to handle by using as little markup as possible, and delegating the bulk of the visual side to CSS, utilising a loose adaptation of the BEM methodology to manage these so-called components. Grid is a big reason I've used frontend frameworks, so once that's properly usable (read: no one demands IE11 support) those are going to feel less and less attractive. I used Foundation for the longest time, but their built-in components are – excuse my language – kind of crap. Menu is completely unusable, and other components have at the very least various a11y problems. I haven't yet given a good try to Uikit. Probably should, but after investing all that time into Foundation I'm somewhat vary about diving head first into another "full-featured" framework ?

That is so true! Our industry has a long tradition of adopting both tech and practices because they worked for [insert a name of a web giant here], with little understanding of how and why they worked – and even less consideration given to the question "is this really a good idea for us?" ?

Interestingly one of the first things to consider when making a site accessible – according to experts, whom I have plenty of trust in – is to always use the correct semantic elements. Screen readers, for an example, have varying support for aria properties and roles etc, so overall I have very hard time believing that Twitter did this because it's somehow "the best way to handle it". Rather it looks like they didn't think of accessibility until the very last moment, and since it was essentially added as an afterthought, modifying the source (read: existing components) big time was no longer feasible. Another thing that points to that direction are complaints I've seen from regular users about the UX of the new service. It's not just about the missing labels and odd ("non-standard") icon choices, but overall the whole experience doesn't seem particularly well thought out. Some of that is no doubt a result of trying to control the user experience as much as possible (prioritised content and all that), but the new site does feel a bit overengineered and underdesigned. Also, I'm not really sure how nesting dozens of non-semantic elements to create what could be done with a couple of semantic elements and a few of lines of CSS – and then sprinkling it with loads of extra attributes and JavaScript magic to simulate what those semantic elements would've done right out of the box – is good for performance. Or long-term maintainability for that matter. ... I'm sure you're right in that the way these services are built is intended to minimise the amount of time it takes to get new developers on-board, or because the internal processes demand it, or because it's difficult to find those devs with crazy ninja skills who can single-handedly master every single aspect of a modern web application without even breaking a sweat. Still, to me this seems like a larger, almost industry-wide trend – one that Mike Taylor quite aptly described as the backendification of frontend development. Anyhow — the point I'm trying to make here is that while there's no doubt that products like React make all sorts of interesting stuff possible (and feasible), that still won't magically make it a good idea to neglect even the most basic design / architectural principles of the "front of the frontend" (as Brad Frost has described his area of expertise on various occasions). In other words: I'm not saying that everything new must suck, just that it seems like too many devs are currently diving head-first into a world of hurt chasing something new and shiny ?

Not sure if this a topic for the dev talk area or perhaps rather the pub, but just wanted to share this little gem. It's a small part of the new Twitter web site/app. I'm not quite sure what's going on with that site – but whatever it is, it's getting out hand, and that might have something to do with current craze with components within components within components within... you know the drill ? For the record, I was trying to figure out what that weird star-icon in the top right corner is/does. Turns out it's some kind of "top tweets on" button (whatever that means), but to learn that you'd first have to a) just randomly click it and see what happens, or b) dig through a whole lot of messy markup to get to the aria-label. Another thing I found interesting is that when you hover the icon, it gets a background colour. Now, there's nothing particularly interesting in that alone – we have the :hover and :focus states in CSS exactly for that purpose – but the thing is that when you hover over the icon, JS adds the blatantly obvious "r-zv2cs0" class to one of it's parents, which in turn results in that slight shade of blue you see on the site. I'm glad they've made the effort to make that mess of a markup accessible by applying aria properties and all, but is this really the direction we want the web to go? The obvious ugliness of the markup is one thing, but when you have to explain to the browser things like "this particular div here, buried ~20 levels deep in other divs, is actually a button you can focus on"... that feels wrong on so many levels ? (And sorry for the clickbait title, by the way.)

Awesome, thanks Mike! ?