teppo

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

Perhaps temporary, one-time-only hashes? Apart from making it impossible to continuously re-use your resources on other sites this makes very little sense to me: in order to use those resources the browser needs to download them and at that point there's no reason to hide them, since the user already has them. In other words this would make your site eat an awful amount of resources for very little actual benefit and it would make caching almost impossible. On the other hand, if you really just want hashed URLs, and they don't need to be one-time, check out the AIOM+ module. It does some of what you've asked here out of the box, i.e. provides hash-style URLs for CSS and JavaScript resources. It does introduce some additional benefits speed-wise too, so it's not a bad idea to check it out either way.

I'd say that it's definitely about blocks: concrete5 makes it quite easy to create unique page structures on the fly. It's not like we couldn't do something similar with ProcessWire, but in the case of concrete5 it's a built-in, original core concept, and thus it's no surprise that they excel in this area. Some of their UI's still look really ugly and amateurish, but putting that aside, it's a great product in many ways. That being said, personally I'm not such a huge fan of this strategy. I'll admit that it does empower the content editor and give them a lot of sway on the way the site looks, but that's actually a double-edged sword: sometimes it works out just fine, but sometimes the site ends up being a total mess. Especially for sites with a bunch of content editors and a lot of content, a well planned structure and information architecture is a must I remember looking into concrete5 a few years ago, the main reason being the way they handle page blocks. Their concept is nearly identical with our old in-house CMS (page blocks, content areas, all of that) and when we decided to move on, concrete5 seemed like the obvious choice. For various reasons we ended up with ProcessWire instead, and I'm glad we did.

NoScript apparently has a history of reporting "XSS issues" when there are in fact none, and apis.google.com is listed as one source of these false positives. Personally I wouldn't worry about this too much.

On mobile so just a quick update: vast majority of the sites I manage have more than one domain and I can confirm that logging in works with all domains. Domain name is not a part of the password hash.

I'd start by checking the $config->httpHosts setting in /site/config.php. Make sure that all domains are listed there (or none, though that's not really recommended). If that doesn't help, you could try enabling debug mode temporarily (also via /site/config.php) to see if it displays more information about what exactly went wrong.

This doesn't sound completely unreasonable. I'm sure Ryan will take it into consideration. In the meantime you might want to give ProcessMigrator a try. I get that it's not the built-in solution you're asking for, but for sharing those repeater fields between projects it might be the easiest approach in the short term. It's entirely possible to create a module that adds a repeater field, or any other field for that matter. We don't currently have a specific module category for "field-creating modules", but quite a few modules create fields or even templates as a part of their install procedures. If you've got questions about creating a module that adds fields or does any other specific task, you can always post them to the module/plugin development subforum.