teppo

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.

Our main audience are currently web designers/developers that require a platform that does most of the heavy lifting for them, but allows them to freely modify data structures, markup, and even back-end functionality of their sites. WordPress, on the other hand, is famous for trying to cater for all kinds of users – even those who don't ever want to touch or see any code *or* markup at all. As a result they're not particularly good at anything and just trying to keep their current codebase in good shape seems to be nearly impossible task. I'm not saying that ProcessWire is already as good as it can get – quite the contrary. We've taken huge steps in so many ways in just a few short years and will no doubt continue doing so in the foreseeable future. The point I'm trying to make is that "converting all WordPress websites over" isn't necessarily a goal worth striving for. At the very least that's not what motivates me personally. Correct. Site profiles provide a starting point, and after installing one of those you can customize your site as you see fit. While I have no idea what you mean by "making it custom", the thing is that site profiles in general are not interchangeable like WordPress themes. This is what I was referring to in my previous post: we've had some discussion about agreeing on specific fields, based on which we could develop interchangeable themes. Not entirely sure what's up with that project right now, but it sounds like this might be something you'd be interested in pursuing too. Actually you could make any module output styles, and some modules already do that. Some existing options include using the $config->styles or $config->scripts arrays (though they also need to be included in your markup somewhere), altering generated markup with a page render hook, and simply outputting styles or scripts in the middle of generated markup. I'll have to agree that these may not be exactly clean solutions at all times, but on the other hand, have you ever debugged a WordPress site with a ton of plugins adding their own styles/scripts? Trust me, "clean" is not how one would describe that either In my opinion this is a very cool idea, but absolutely not something the core should do. Without going into specifics, nothing you've mentioned so far can't be done with a third party module. If this is something you feel is missing from ProcessWire, feel free to give it a try. You might even find some like-minded people here who'd be willing to help. In some ways I'll have to agree, but it's really not that simple. WordPress a) was around at the perfect time, b) decided relatively early to cater for the needs of everyone out there, c) doesn't care about how they're perceived by the technically adept audience, and d) doesn't care how much technical debt they amass in the process. I don't think that any platform can really take them head-on when it comes to number of users: at this point their popularity is also their biggest asset (assuming that "being the most popular platform out there at any cost" is really a sensible goal.) Agreed, and we *are* already expanding our audience. You haven't missed the Composer stuff we've been adding lately, have you? It's just that we've been aiming for expanding our audience to a slightly different direction than you had in mind I hate repeating myself, but I'll do it anyway: build a module. Publish it. If it's awesome and a lot of people love it, it has a good chance of becoming a core feature one day.

Currently we're catering for this need with Markup modules, site profiles, and to some extent Textformatters. In my opinion these are all "easy ways to share design". If these are not enough, you could also share template files and smaller snippets of code, but considering that each site may have different fields in place, that only works as long as you also standardize those fields. There has been some discussion about this too, but more as a community project than something the core should take part in. If you're using the devns branch, there are also field-level template files. These would be much easier to share between different projects, so I'd suggest taking a closer look at them. I've built quite a few sites using ProcessWire, ranging from very simple one-page sites to news and intranet sites with (tens of) thousands of pages. I've never felt that the API "only works for simple websites". Admittedly I've used SQL on some extremely rare occasions, but that has mostly been due to the fact that I've either had a custom database structure too, or I've needed to optimize a potentially slow query for just one very specific task. Assuming that the API is awesome for *at least* 95% of use cases (that's my impression anyway), I don't really think we can state that it's "not good enough". For use cases that a few people here and there might face in some rare situations it's entirely acceptable to figure out a custom solution. Just checking, but you do realize that you could easily add a custom queryArray() method to $pages API var and even publish your solution as a module if you feel that it has potential for wider use, right? That being said, I'm not against this feature per se. It's just that every added feature also adds complexity and the core absolutely shouldn't contain features that are known to be used extremely rarely (not entirely sure if that's the case here, but based on my experience so far it very well might be.)

To be honest I'm not particularly worried about the amount of issues, but I do agree that it doesn't look very good for a random visitor. The obvious solution to the "too many open issues" issue would be two-fold: Get rid of all the "fixed" and "not a bug" tags. If an issue is fixed it should be closed, and if the fix doesn't work it can be reopened. If we want to get rid of as many issues as possible, we could move feature requests to another service. Personally I would vote against this. In my opinion closing unresolved issues, whether old or new, should never be an option. "Can't reproduce", for an example, doesn't mean that the issue isn't real. Just my two cents.

jQuery-inspired is in my opinion the best short description of our API. "An easily approachable and powerful API" is way too generic, especially since the jQuery connection is actually an important point. ProcessWire's API is modeled after jQuery, after all, the general idea being that "if you know jQuery, you'll learn ProcessWire development in no time". On a related note, personally I prefer to discuss it as the "developer API", not just API. On a couple of occasions I've had to specifically explain that ProcessWire doesn't actually expose a public API automatically. The Finnish translation ("rajapinta" vs. "kehittäjärajapinta") seems to be even more prone for misunderstandings

In my opinion this is a good idea, though it should be made clear that feature x getting a lot of votes doesn't mean it will be implemented – just that it's what most users voted on. If product development was all about "ask the crowd what they want and do it", products like ProcessWire – ones that dare to approach things from a different point of view – wouldn't exist. We'd just have a ton of WordPress clones. I'm not sure where I've heard it from and if it's even really true, but they claim that Nokia once asked their users what were the main griefs they had with their phones. The one they heard most was that the battery was drained too fast. For a long time their phones had terrific batteries, but in all other aspects they were way behind companies like Apple who literally decided not to listen to their customers. Sorry for going slightly off-topic, but my point here is that while it's good to ask what your users think, it doesn't mean that you should always do as they tell you. It can, nevertheless, provide you with new ideas and feedback regarding the direction you're going with your product. The idea is good, but needs to be put into right context