teppo

For the time being it's fine to use 2.7.2 – that's our latest stable release after all – but if you're just now starting a new project, and especially if it's going to be under development for a while, I'd strongly suggest basing it on either 2.8 or 3.x devns. If you're feeling slightly adventurous and choose to go with 2.8 or 3.x, the choice between these two depends mainly on whether you plan to make use of external libraries etc. in your project. 3.x includes namespaces, 2.8 doesn't – other than that they're essentially the same and will remain so thanks to the fact that Ryan has mostly automated the process so that updates to 3.x also get applied to 2.8. While namespaces are cool for serious development and can make it a) easier to pull external libraries into ProcessWire or b) pull ProcessWire into other projects, in my experience most site projects don't benefit much from them. If the idea of namespaces makes you uncomfortable and/or you have no idea what they are, it's absolutely fine to go with 2.8. For the most part the built-in FileCompiler in 3.x hides namespaces from plain sight, but if you just want to build a regular site with ProcessWire and don't want to worry about all that namespace stuff at all, you'll probably feel more at home with the 2.x branch

It would be good to see some code here, i.e. what exactly you're doing, but based on this comment it sounds like you're caching all the books with the same name and thus always overwriting previous one with the next one. Does this sound familiar? If this is really the case, you should either generate unique name for each cached portion of the content OR cache them together instead of book-by-book. Also: if you're using a relatively new version of ProcessWire, I'd suggest looking into the $cache API variable. MarkupCache is still valid approach, but $cache is a newer solution and widely used by the core itself. Additiionally it provides improved tools for invalidating the cache, which could come in handy here.

So this is where the zombie apocalypse begins. Seriously speaking: for-page-20044 is the parent of repeater items connected to page 20044. The parent of this page should be named after one of your existing repeater fields. Do you have page with ID 20044 in the system and does it have repeater fields? What about those other pages you mentioned? If, say, you have a repeater parent called "for-page-12345" and there's no page with ID 12345 in the system, then this could be a sign of cleanup not working as expected. On the other hand if a page matching each repeater parent does exist, this probably just means that you've got hundreds of pages using a template with at least one repeater field attached. Just an idea, but perhaps you could post a screenshot displaying these pages in the admin. These things are sometimes difficult to explain with text alone

Thanks for letting me know.. and good to hear it's working now

Thanks for reporting this, @grimezy! One issue I can see right away is that date_diff() can indeed return "false" on failure, and this case is not properly handled by the code visible above. Real question, though, would be why this happens. Mostly guessing from the error you're seeing and the code visible above, most probable cause would be some kind of an issue with $login_date, which in turn could either mean that login_timestamp row in database is empty or contains something unexpected.. or it could mean that $date_format is somehow broken. I was unable to reproduce this issue based on a quick test and I'll have to step away for a few hours now, but I'll try to debug this further (hopefully) later today

Agreed, that makes a lot more sense. I'm one of those developers who tend to lean towards the simplest possible implementation and as few external dependencies as possible, even if that means writing a few extra loops, but I can definitely see the value in this

Fun series, but every time someone blurts out something like "shorter code is better", I get the feeling that they've never heard of Perl. Granted he did claim that this is almost always true, but still Say hello to this actual solution to a round of Perl golf back from '02: $_=pop;s#.#push@;,$;until$;++&$;;$@[$_]^=$;/$_&$&for@;,$;#eg;print@@,$/.

I'm mainly thinking about the way ProcessWire makes it possible for third party modules to alter the source of a page, inject their own scripts or styles, etc. While this does require a lot of trust in installed modules, it's also something we wouldn't want to disallow. Inputfields are another thing consider: many third party inputfields rely on existing libraries, in which case the implementation details are more or less out of our hands. Unless I'm missing something obvious, CSP would mostly be useful if users were able to inject their own scripts or styles for other users to see. In order to do that, you'd either have to be a superuser and use some rather specific features to achieve this, or exploit a third party module that allows this. Latter option is absolutely something to consider, but the first one not that much: generally speaking we consider users with access to the admin interface "trusted"... and superusers even more so. While we could introduce a method of "registering" embedded content with the system, I'm not entirely sure if that's worth it. It could make the lives of perfectly legitimate developers more difficult, while the benefits are — in my opinion — somewhat questionable. It's also good to keep in mind that this isn't something that would protect you from malicious / hacked third party modules: a module could simply hook into an earlier (or later) point in program execution and override any CSP rules you've got in place. That being said, I'm not against the idea of implementing this as a configurable option. It would no doubt be possible for ProcessWire to generate nonces for any inline content it requires, and as long as this would be a configurable setting, it shouldn't come as much of a surprise if some third party features stopped working afterwards. I don't see this as such a big thing and I'd imagine the potential use cases to be limited, I for one would be OK with this as long as it doesn't needlessly complicate things ?

What Adrian said If the question is whether I plan to release a separate 3.x version with namespace declarations in place, I honestly haven't even thought about that yet. On the other hand I do intend to support both 2.x and 3.x for the time being, so if this module isn't playing nicely together with the compilation feature of 3.x, please let me know.

Inline scripts are used widely in the admin interface, so this sounds like a case where you wouldn't want to enable CSP. It's fine to enable it on your front-end if it's something you want, or you could use the unsafe-inline keyword to get past this issue, though. CSP is well-intentioned, but some of it's rules don't make that much sense in certain use cases, and our admin interface is in my opinion one of those cases. On the other hand ProcessWire doesn't dictate any of the markup you see on the front-end of your site Note: this topic has been moved to the security forum.

That's not an option; in this case the field becomes unusable. In my opinion this is correct behaviour: not having anything defined here sounds more like a half-configured field or a mistake than something the developer did intentionally and knowingly.

A while back while importing some 10k pages from another system I wrote an import script that would sniff the extension of the file, and if it wasn't yet allowed, it would first add it to allowed extensions and only then add the file. In this particular case I knew that all files were "safe", but there were dozens of different extensions to account for. To me this idea seems to make sense: as a developer I should have the option of saying that it's safe to insert "anything" in this specific field. A warning would still make sense, considering that not everyone who has access to these options will understand the risks involved. On a related note, I'm wondering if supporting regex would make sense here? Seems to me like one way to support just about every imaginable requirement in a future-proof way. It might confuse some vs. the old * trick, but then again, simple regex is not that much more difficult; just prefix the star with a dot

Thanks, that helps a lot. I'll get back to you if I get green light for the project. Took a quick look at the API docs, and seems like the channel implementation is almost identical to regular one, so probably not a big deal

Hi Antti! I'm currently looking into a project that could be a potential use case for Padloper, but this being a local client there's one rather specific requirement: support for Paytrail – or perhaps Checkout, though I'm not really familiar with that one. Is there any chance that you might have something like that already available, or do you have any idea how much work it would require to set it up? Thanks in advance!

Agreed that we don't really need the wiki that much. Still, I'd suggest rerouting the queries there to some other location on the site. Having an empty directory listing there looks a bit weird

Sure – where I work at we did exactly that, and haven't looked back since. First of all, it's important to understand that at it's core ProcessWire is a (web) application framework. We prefer to call it a content management framework, but that's not very far from what most web applications do: they store, process, and output content. The way I see it, the main difference to so-called traditional frameworks is that modelling and handling data is a built-in feature, not something you have to reinvent on a case-by-case basis. I have rebuilt a couple of old projects from the scratch using ProcessWire, and in all of those cases this has saved me a lot of time and made most of the model layer obsolete. Before we started using ProcessWire we were doing sites with another CMS and custom applications with Zend Framework. At the beginning I had this idea that we would use ZF for "apps" and ProcessWire for "sites", but in just a few short months we realised that there just wasn't anything we could achieve with ZF that couldn't be done, usually with less work, with ProcessWire. Sure, sometimes we pull other libraries into the mix, but that's not a shortcoming; in my opinion it's just good design Regarding some of the things that have been mentioned here: One thing I was originally missing from Zend Framework was a clearly defined structure. Built-in "one file per template" concept is great for simple sites, but that's just about it. This is why I built the original version of my MVC project. It's not perfect, but it has served us well for years. To get most out of ProcessWire you really should be using it's data modelling abilities. Sure, you can still mock up your own data structures and write SQL to fetch content from the database etc. but that's kind of missing the point: ProcessWire makes data modelling a breeze and the selector engine is both flexible and secure. Some users prefer to build custom management panels, but in my opinion that's another thing you should try to avoid. ProcessWire's admin GUI is flexible and extendable (see Process modules), and again: in most moderately sized projects it can easily save you days of work. For routing you can use page URLs, but I'd also suggest looking into URL segments. For me, coming from the world of Zend Framework, templates are a lot like controllers and URL segments make it easy to implement the concept of actions Try not to invent your own access management system. ProcessWire has a very good implementation of RBAC already in place, and if you need more flexibility, I'd suggest looking into modules such as Dynamic Roles and/or User Groups. Rolling out your own solution is risky, tends to cost a lot, and just generally speaking is a very bad idea. Form validation has been mentioned twice here already. I don't have much insight into this, except that in the beginning we used to build forms using Zend Form, which has it's own validation built-in. That was always a bit tricky (not because of ProcessWire), and these days we use Form Builder for pretty much every form-related need. Sure, it's a commercial module, but it has saved us so much time that the price is absolutely not an issue. In my opinion the answer to your original question is yes and no: ProcessWire can't substitute an application framework because it is an application framework

@bernhard: exactly the question I've been meaning to ask too! Syncing a site to another location periodically and preparing a failover mechanism for static data is one thing, but I'm also curious about how data gets merged back and forth in a situation like this

this is not possible with no existing system on the web..... Actually I believe @JRW-910 was referring to the users not having to know any coding. Please correct me if I'm wrong, though In addition to what @mr-fan said above, I'd suggest taking a closer look at the devns branch of ProcessWire. This is the future 3.0 version, still in development, and among other features it includes a kind of a front-end editing support. Perhaps not exactly what you were looking for, but this could come in handy anyway. Other than that, Fredi provides front-end editing support right out of the box, and you can always embed admin views into the front-end by applying "&modal=1" to the URL of the edit view. This is all good to know in case you don't actually require a fully customised front-end editing experience, but would rather use the one ProcessWire provides out of the box. If it is a fully customised front-end editing feature you're looking for, that's relatively easy to achieve via the API. ProcessWire is awesome for this kind of stuff, but again: unless you really need a fully custom solution, I would suggest looking into the existing solutions first. For an example the FrontendUser module mentioned above is definitely a viable solution for the user registration part For managing permissions ProcessWire makes use of a simple role-based approach, but if you need something more specific, here are a couple of alternatives: Dynamic Roles provides a very flexible method of defining new "dynamic roles" in addition to the real ones based on various factors. There's very little in terms of permissions you can't achieve with this module. User Groups allows you to define page-specific or branch-specific permissions, and adds the new concept of "user groups" for grouping users together, regardless of roles they might have. Page Edit Per User does what the name says: assign edit access to individual users on a per-page basis. This module is a bit older already, so not entirely sure how it works with the latest versions of ProcessWire, but it's also a relatively simple one, so if it doesn't work it's easy to cook up something similar.

For the most part I agree: classes don't have actual semantic meaning, so technically speaking they're fine, and I believe we're pretty much on the same page regarding pseudo elements too. It's just that I've recently started to emphasise pseudo-elements over classes whenever it makes sense. There are many cases where it doesn't make sense, but for something as simple as alternating background colors for predefined elements it fits the bill perfectly. I've also grown tired of trying to guess which classes I should add to my markup in order to make it easy enough to style, and I strongly dislike having to change any aspect of the markup (including generated classes) if I later on decide that I need to do something purely style-related – such as make odd items have a different background color. Pseudo elements are awesome for separation of concerns, and they can reduce the clutter quite a bit. While classes rarely add a considerable amount of extra weight to the document, unless we're talking about a serious case of classitis combined with extremely large scale use, that's another (however minor) argument against them: why add something that isn't required in the first place

So the gist of this issue is what Martijn said above: pseudo-classes and classes have the same specificity. Actually I was under the assumption that this would be the case, though I'm not sure if I've ever actually checked. It's just that this makes a lot of sense considering that pseudo-classes are essentially a way to support stuff like .odd, .even, .first, .last and .list-item-number-3653 without actually cluttering your markup with a whole bunch of style-related stuff. This doesn't, though, mean that you can't override these; just that you'll have to be specific with your selectors. Just like in any other language, CSS also requires you to be exact with what you mean. I also don't see this as a very good reason to ditch the pseudo-class stuff, especially if the alternative is to write new code to generate an army of classes for identifying parity, position, order, etc. In my humble opinion it's an awful practice to use markup (even classes) to generate what should – and could – be purely a question of style, even more so when code is required to generate that markup. At the same time I do also tend to steer away from some variations of ::before / ::after + content(), for the same exact reason: CSS should define style, not content, unless that content is strictly for the looks and doesn't provide any real value

Not entirely sure we're on the same page here, so just to clarify: what exactly do you mean by not being able to overwrite these? Just in case I prepared a little demo here: https://weekly.pw/odd.html. Seems to me that overwriting :nth-child() with a class works just fine, but then again, I'm probably missing your point here

Just wanted to throw a quick +1 to this approach. CSS classes like .even and .odd are very much a thing of the past and generally speaking one should steer away from those. Also: I'm having hard time imagining a front-end framework that doesn't support some variation of source ordering (pull/push classes)

Saw some missing CSS files on modules directory too, but a refresh seemed to fix the situation. Could be browser cache, or perhaps something was a bit off with CloudFront after the switch. Not seeing any of those now.

Noticing a huge difference in speed here; all my earlier issues are gone now and the forum feels extremely slick. Not sure if it's server location or increase in resources, but I'm quite happy with the switch. Twitter feed and at least one profile pic missing, though I guess you're already on that

One more thing to mention: personally I've really enjoyed the courses from Codecademy. Their system isn't exactly perfect, but it's still pretty awesome, and "learning by doing" has always worked better for me personally than learning from books. If you enjoy a hands-on experience, I'd suggest giving them a try. It's free and they've got an easy-to-understand PHP course for beginners On a related note I wrote a blog post about PHP templating a few years ago. It's mostly about PHP vs. Twig, but could also work as a kind of an introduction to templating in PHP.