teppo

ProcessWire uses quite basic RBAC system and it probably just didn't feel necessary to dive further into this. Some of the basics: Each user has one or more roles; "guest" is always assumed and required, even for non-logged-in users (i.e. visitors) Each role is a named collection of one or more permissions; page-view (as you noted before) is always assumed and required and only displayed because, well, it's there (that's actually supposed to be helpful; you don't have to guess which permissions this role might have, what you see is what you get) Permissions are just permissions, there's nothing really magical about them; for the most part they're just Pages with special purpose Each Page uses a Template and each Template has access settings, where you can define which roles have access to the basic actions on Pages using said template: view, edit, create and add children One important thing to note here is that an user having a role with page-edit (or page-view) permission won't instantly allow that user to edit / view all pages but it is a prerequisite for giving this kind of access at Template level (via access settings). Template level access settings are just one use case for the access control system in ProcessWire; it actually goes a lot further and is much more versatile than that. (Admittedly this part does sometimes cause confusion and thus it might be worthwhile to document it more clearly.) Programmatically managing and/or checking for roles/permissions is explained in the docs. If you want to check if user has specific permission, whether that's built-in permission or one you've added yourself, it goes like this: $john = $users->get("johndoe"); if ($john->hasPermission("read-the-docs")) { echo "Sure thing, go ahead: http://processwire.com/api/"; } Cheatsheet also provides basic info on most (if not all) actions you can perform on/with users, roles and permissions. If you use $pages->find(), it should already only return pages that current user has view access to (unless you add "include=all"), so I'm not entirely sure what you're referring to in your last comment. Pages don't have roles, they have a Template, and that Template has access settings. If current user doesn't (via one of her roles) have access to view that Page, it won't be returned by $pages->find() either. Note: $pages->get() is different from $pages->find(), as it assumes you really want that one, specific Page. It always returns the Page (if it exists) without considering permissions.

Almost. There's also an additional check to see if the returned page contains certain traces of ProcessWire. Simply checking the return code wouldn't be enough here For the record, isit.pw includes roughly a dozen methods for checking if a site is running ProcessWire. In many (most) cases it can still identify your site, even if that one check fails. I should probably mention that isit.pw (which is my project) is both a functional tool (as Antti explained earlier) and an experiment; "can you properly identify a site running ProcessWire or not?" I'm also planning to add an info section later, including details on hiding your ProcessWire-ness from humans and services like isit.pw equally

Thanks, Adrian. I've just fixed the notices you mentioned earlier and removed the stray </em>. View Page seems like a worthwhile addition, but at the same time it makes the UI feel a bit stuffy. I'll have to give this a bit of thought

I've been asked once in roughly a decade of client work if more complex workflow would be doable.. and even in that case the client ultimately decided it wasn't needed. Such things are usually for very specific use cases (online magazines etc.) or huge organisations with tons of "untrusted" content admins (which, based on my experience so far, is still quite rare, at least around here). I can't see any reason why this couldn't be done with ProcessWire already, as a 3rd party module. If there's something that makes it impossible, perhaps we should see if that could be fixed instead. A feature that would most likely be used by very small subset of users isn't something we should force on all users in the core package. The argument that this might attract more users is probably valid, but in my opinion it still doesn't mean that this should be a core-level addition.

Just wanted to step in and confirm that HTML Purifier does, indeed, strip any tags it doesn't recognise as valid (i.e. part of whatever DTD it's following). ACF is the one that allows any tags it's configured to allow using a config string -- there's a world of difference there. Also, if anyone got the idea that I'm against ACF, validating/filtering/sanitising user-generated markup, or whitelisting, I'm not. Whitelisting is a very good security practice, but as long as HTML Purifier doesn't allow valid HTML5 elements, it's outdated and useless (for many of my use cases). That may or may not be true for anyone else, but in many cases I've found it easier to avoid it -- for now. For the record, the issue that originally led me to this decision was the fact that I could, in theory, configure HTML Purifier to allow specific data-attributes, but apparently there isn't any way to whitelist all data-* attributes, using a wildcard. That's understandable considering it's purpose and scope, but not acceptable for some of my use cases.

Thanks for reporting this, adrian Version 1.2.10 includes a fix for aforementioned issue and is now committed and pushed to GitHub. My approach looks kind of complicated and I might tweak that later, but it should work as intended anyway.

HTML Purifier doesn't support new elements added in HTML5. It does indeed support specifying allowed elements (like you've just noted), but here's the catch: Based on a quick glance at those advanced customization features, adding support for new elements is doable, but allowing valid HTML5 tags would seem to require a custom DTD (or something like that) -- or at least a whole lot of new rules. That's where I lost my interest and switched the whole thing off. HTML Purifier has caused me more harm than good and until it gets a proper update, I don't think it's really worth it.

@Zahari: extra allowed content is exactly what the name suggests; it lets you allow elements that are not normally allowed, thus "extra". Admittedly the help text could specifically say "extra" before the "allowed content rules", or it could list defaults, but former seems somewhat unnecessary (it's in the title already) and latter might be complicated (since PW doesn't define defaults, only CKEditor JS plugin knows what they really are). Buttons are doing exactly what they're supposed to, but help texts could use some tweaking -- even if just to specifically mention that enabling HTML Purifier will, in many cases, effectively undo rules added to extra allowed content.

+11. Nope, not a typo -- just how much I want this to happen. I'm not much of a fan of AJAX driven sites, but I do tend to implement template level front controller pattern to all the sites I work on. Being able to route all requests to specific file without having to define that file separately to each and every template as an alternate template file would be very, very nice addition.

Honestly speaking, that's still a bit light for my taste. I'd go with stronger colour. Looks like you had #79B803 as your link colour at some point. That looks great. Just saying

Take what Antti said, replace 90% with 99.9% and you've got my opinion. Anyway, reading this made me cringe; if that's your idea of responsive design, I'm not surprised at all to hear that you're not very impressed with it. Take a look at the RWD patterns library collected by Brad Frost and you might get a better idea of what it's actually about.. or listen what Google has to say about responsive design fundamentals. (In a way you might be right, as that's really what a lot of people are doing -- but that's just because they're doing it wrong. RWD is all about making things usable and future proof regardless of resolution, window size, (physical) screen size etc.) By the way, I liked your sites. Keep up the good work!