teppo

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!

Just for the record, since it's closely related to this thread, there's a pull request in GitHub about SQLite support (opened back in May). There are quite a few changes and most likely it isn't in sync with current dev branch (it's based on the master branch), but still works as a nice proof of concept for SQLite support. If any SQLite user here is able to get that one running and could run a few tests to see how well it behaves (the questions Ryan asked in his comment to the PR, like how well selectors work etc.) it would be interesting to hear.

@mvdesign: sorry, corrected my earlier post -- meant to say bootstrap use, not API use. The principle was correct, though; if I'm guessing right, you're bootstrapping ProcessWire, and thus output formatting is always disabled and file fields will always return arrays, regardless of output settings (including the "output single item if limit is one" setting).

Bootstrap use, presumably? In that case output formatting is off and field value is returned in array format. You'll need to call wire('pages')->get($id)->file->first()->url etc.

Probably the easiest way would be using Schedule Pages. If you need the unpublish date to be automatically set to x days after publish, you'll need to write a simple module to auto-populate the value of field 'publish_until'.