teppo

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.

I don't really see what we're missing feature-wise here either, but that being said, I do have to admit that originally I was under the impression that this was going to be a replacement for the old grid view (which never made much sense to me, especially considering how it lacked so many features), not both the grid and the list view. The thing is that I too would prefer list view in some cases: especially when the images are intended to be displayed on the front-end as a list, it would make sense that they're displayed as a list in the back-end too The screenshot above displays two obvious use cases that could be handled better: backgrounds for transparent images (use a grid, not solid colour, just like we did for the old image field) and narrow fields (instead of trying to cram everything side-by-side, in some cases it would make sense to have the image on the top and other elements below it). Additionally this UI doesn't make as much sense for the single-image use cases as it does for galleries and such. In my opinion it would be good to have the option of disabling the buttons on a field-by-field basis. Additionally it feels a bit awkward that even though there's only one image, one still has to click to see the edit fields; though this might be a question of preference, it's also one of the cases where the old list view made more sense to me. That being said, this is a great update, so big thanks to everyone involved. I'm sure we can iron out the glitches and improve the usability of the field in some situations now that the new field is in the core. It's typical that some additional requirements only arise after a feature is in wider use

Again it boils down to differences in use cases. I don't think any of our sites have a single page with even close to a hundred images, let alone that amount of variations. I would assume that this requires some tricks either way; from my point of view variations are temporary data, so one should always be prepared for them going away, and generating hundreds of variation images at one go sounds like an extremely resource-intensive task. If I had this kind of need, I'd probably try to figure out some method of creating the variations as a background task before the page (or images without variations) can become publicly viewable Anyway, I'm not saying that this isn't a feasible situation, just that it's something none of our sites have. For us it's common to have hundreds or thousands of pages with a few images at tops, in which case a method of cleaning out all variations would be quite handy. On the other hand for use cases like the one you've mentioned above a page-by-page solution would make more sense. Perhaps two separate solutions would make most sense? Not sure if clearing unused variations is really feasible, considering how they're requested, but of course that would be nice if it was feasible..

"There's already a file existing for the current time." Apparently I can only create a migration file once a minute. Is there a reason for this or am I just being too hasty?

Depends a lot on the use case. I'm currently working on a site with roughly 10.000 pages, and because of some recent changes, most of those pages have a whole bunch of unused image variations. Per-page solution wouldn't do me much good here Generally speaking I'd say that a "clear all imagevariations" would be more useful than a per-page option.

My thoughts exactly. Currently these panels are fun, but this could increase their potential use cases exponentially

@AndZyk: that's a good point. I don't enjoy working with template engines and thus I don't do it unless I really have to, but in the past I've had a few cases where I really did have to. The biggest mistake I did back then was that I tried to add too much logic on the front-end side. Sure, that's almost always a bad idea, but with Twig (and any other language designed for building simple templates) the repercussions are tenfold. The lesson here is to never, ever add complex (business) logic to your Twig templates. Twig is not intended for complex stuff and even if it can be done – it has macros, is easy to extend with custom features, and supports both includes and template inheritance out of the box – the end result is almost always really ugly and way more confusing than it would be if it was written in plain PHP. In theory this is easy, but then there are the border cases. For an example, imagine that you've got a bunch of raw data you need to format and output; do you iterate over the whole dataset in PHP and handle the formatting part there before sending it to Twig, or do you just send it to Twig and handle formatting and output in one go? If you decide to use Twig for both steps, chances are that you're in for one heck of a rough ride. If Twig helps you keep your templates clean, by all means go for it, but in my opinion you will need another layer for handling the business logic, data formatting operations, etc. Twig is a good companion to a larger architectural pattern (such as MVC), but on it's own it's a major pain in the a*s.

Probably better examples floating around too, but the execute() method in ProcessLinkChecker.module loads JqueryWireTabs, creates a new InputfieldWrapper, and adds child inputfields. In this case children are created by separate build* methods, but you could also create them in the execute() method itself. In this case I need to create multiple similar inputfields, and separate methods help me avoid code repetition. There might be a better way to do this, but in this case I had to trigger the tab feature myself. This is done in ProcessLinkChecker.js, and the target is the original InputfieldWrapper element created by execute() method of ProcessLinkChecker.module. This is why I had to load JqueryWireTabs in the Process module, by the way. You can display fields conditionally by using showIf rules. Something like this, perhaps: public function execute() { $fields = new InputfieldWrapper; $field = new InputfieldCheckbox; $field->name = "field_a"; $fields->add($field); $field = new InputfieldText; $field->name = "field_b"; $field->showIf = "field_a=1"; $fields->add($field); return $fields->render(); } Edit: I'm moving this topic to module development subforum. Modules forum is intended for module support threads, while the module development subforum is where we can discuss development practices etc.

In case you're looking for a way to separate your layouts from template-specific views and your business logic from front-end (markup) while still keeping things "editor friendly", you might want to take a look at one of the MVC-ish output approaches out there. My own take on the subject is available from GitHub as pw-mvc, and I've heard good things about the pvc boilerplate by fixate. Sorry for the shameless self-promotion, but I do think that this approach brings in some very real benefits, especially once things get more complex. Generating and concatenating pieces of markup with code just feels awfully clunky and, at least in my hands, often results in template files that are both ugly and hard to read

While I agree with what Kongondo has posted above, easiest method for just about any form-related need is usually FormBuilder. FormBuilder is a commercial module, and if that's a problem (and you really just need a very simple contact form) I'd suggest taking a look at Simple Contact Form by Bea.

@kazu: module-specific questions should be posted to the applicable module support thread. In this case I'd suggest asking this question via the TemplateEditor support thread here: https://processwire.com/talk/topic/2275-templateeditor/.

A minor correction to the above example: change the ";" at the end to ":"

Just for the record, you could also wrap the function declaration with function_exists(): if (!function_exists("listDefinitions")) { function listDefinitions(PageArray $children) { // etc. } } echo listDefinitions($page->children);

$categories = $pages->get(1077)->children("template!=exclude")->shuffle();

Check the name of the repository at GitHub. In this case there's this line right below it: That's a pretty good indication that this particular repository might be a fork In the GitHub workflow if you fork another repository you can send a pull request containing all your changes to the original repository / author. If you've changed the README in the fork, those changes will also be included in the PR. That's one reason not to include indication about this being a fork or anything like that. Of course you can get over this limitation by creating a separate branch for the changes intended for the PR, but that's extra work and most developers are just plain lazy