teppo

Some additional observations: The way a version number is appended to module name in the docblock at the top of the file feels weird. It's a small thing and I can always remove it manually, but if the purpose is to mention the version of the module, I'd suggest using @version tag instead. (A question with both approaches is whether module authors will remember to keep this up to date with the module version recognised by ProcessWire, though.) Seems like basic docblocks for methods such as getModuleConfig() would make sense too, otherwise they'll have to be added manually for every new module (or worse, they'll be left out altogether). It would be awesome if the generator could make it easy to choose and include a license, preferably as a combination of @license tag + LICENSE file. A few common license types would suffice for starters; GPL, LGPL, BSD, MIT, and perhaps something like WTFPL too. I've seen many modules lately that haven't specified a license, and to me this is a huge red flag, as it literally means that I can't know how, where, and for what I can legally use said module. I was a bit surprised to see that implementing ConfigurableModule didn't enforce "include configuration page", as it seems like an obvious choice. Part of the confusion was that "configuration page" made me think it would add an actual page somewhere to contain configuration settings, which is why I left it unchecked in the first place.. For some reason I'm also getting blank array items in module config. Not sure if those are intentional or not, but they do look a bit strange: 'requires' => array("PHP>=5.4.0", "ProcessWire>=2.5.3", ""), 'installs' => array(""),

Nico, I'm having an issue you might want to take a look at: if the summary contains non-ASCII characters (in this case "ä" and "ö"), they seem to get stripped from the final file. Doesn't seem intentional. Another thing I noticed, and this is more a gotcha than a real bug, is the optional "implements" setting. It's true that "implements Module" can be disregarded if you're extending something that already implements Module or ConfigurableModule, but leaving it out unintentionally will result in weird errors, and currently the UI seems to suggest that this would be optional in all cases. This could be confusing, especially to beginners. Your default configuration options "+" UI made me wonder whether it would make sense to allow creating and bundling multiple module files at once? Most of my modules seem to actually consist of more than one module – a Process module for UI or API, another module for hooks, perhaps a third one for optional features, etc. This could be a border-case and would require some sensible server-side limits either way, so perhaps not worth the effort though. I'm also wondering if the source code for this tool is something you'd like to share and/or open-source. Not sure what your long-term plans here are, but I'd be happier if I could see how this thing works, perhaps report bugs and send PR's via GitHub, and just overall be sure that if something goes wrong I can have another copy of this very useful tool online (or installed locally for cases where I'm not connected to the Internet at all). .. and finally, I can't select ProcessWire 2.6 as "min. required PW version" yet For the record, I'm currently writing a paper that'll discuss module development in detail, and I'm very happy to be able to suggest this tool as the preferred method of setting things up. Of course I'll mention the "old-school" method of duplicating another module as a starting point (and even starting from the scratch), but IMHO your module generator has made other approaches obsolete in many cases

Agreed. Such things are no deal-breakers, but annoying nevertheless. Additionally, since we're (kind of) discussing smaller details here, what's with the "mod" part -- why not call it "module"? Seems like it's the only thing that gets shortened, and thus looks like another API inconsistency to me. Again: small, but annoying

Agreed with Pete. At this point Flash and Silverlight are nothing more than unnecessary legacy payload and clutter. I'd rather use a clutter-free library than one attempting to cater for the needs of all the old (and outdated) browsers with any means necessary.. so to speak

I'm seeing two settings that could have something to do with this: maxFileSize and loadImageMaxFileSize. Latter seems to be 10MB by default, so not too far from what you've mentioned here.

Haven't tried it and can't provide any real expertise here (sorry!) but the problem is quite familiar. If this solution (or something similar) works, and if we could benefit from it right within ProcessWire's Admin, I'd be very, very happy "ecause you didn't give PHP enough memory or increase the max execution time" tends to be the problem with server-side solutions. There's always finite amount of memory, and vastly increasing memory limits in order to account for some specific memory-intensive tasks means that one can no longer count on the memory limit as a safety mechanism.. and that is just asking for trouble. Same thing goes for max execution time.

Depends on your use case, but I personally prefer GET variables in cases like search features. This way users can link to search results, share or bookmark them, and so on. What the URLs look like tends to be less important to me, though I do get your point too. Generally speaking GET requests are preferable for "query" type requests, while POST requests have the edge when it comes to requests that trigger changes, shouldn't be cached or stored as-is, etc. This article by Jukka Korpela contains a pretty good summary about the differences, why they matter, and what are the preferred use cases for each method. Anyway, glad you got it working!

@heldercervantes: actually, it looks like you're missing one part, which would be $input->whitelist('q', $q). Check out the code (and comments) here for an explanation. Whitelisted GET params are automatically included in the pagination.

Thanks. Sounds like second update was triggered before first one was fully finished; database schema was already up to date, but revision number wasn't incremented yet. Looks like I'll have to add another check there to make sure that update doesn't get triggered unnecessarily like this.. If the site and module are working properly now, I wouldn't worry about this too much. If you want to be 100% sure that everything is fine, check that "schema_version" in the ProcessChangelogHooks config is "2" (easiest to check via the modules table) and that table "process_changelog" has column "templates_id".

Soma: this should be fixed in the latest version; check issue #7 for more details. Please let me know if this still happens!

WireData::get simply explodes given string from "|", iterates found keys, and compares them one by one to existing items. In the case of WireArray::get the argument is used as an actual selector string, which means that in your first example there you're asking for all items with type "one" or "two", and the rest depends on sort settings. You might be able to use "sort" to do what you're describing here, though it really depends on your actual use case

My thoughts too. The site looks stunning, but 7MB+ for the home page without lazy loading is a lot, even for current connections.. and for my relatively slow (and very unstable) 4G it's way too much. Additionally this is going to cause some serious bandwidth usage on your side, though I'm sure you're already aware of that

Sorry, a bit OT, but this is exactly why PHP has version_compare(). Either way, three digits can't properly represent version numbers (1.11.1, etc.) so that's not a very good convention to have, whether or not it makes some things slightly easier

Take a look at this topic, and particularly Soma's answer there. The question mark means that ProcessWire doesn't yet know which page was requested. Either your site is getting more traffic than the (MySQL) server can handle, or there's something else going wrong. Might be worthwhile to take a closer look at Apache logs if you want to find out what exactly is going on traffic-wise. Additionally checking MySQL slow queries log (if you've got that enabled and can access it) could provide some sort of insight

That's a double-edged sword, no doubt about that. By offering something for a price too low you might get kicked from the race altogether (based on the argument that "you probably misunderstood the scope of the project", which might or might not be true), and on the other hand price is often a big factor, and you should aim for the lower end of the "acceptable range" if you want to impress the client. Pricing projects is hard work

When it comes to security, one important thing to note is that Ryan has taken a very strict approach to that in ProcessWire. Our codebase is clean (free of unnecessary clutter and legacy stuff), attempts are made to mitigate known attack patterns, and strict filtering is applied before requests even reach the system itself in order to protect it from possible future attacks. ProcessWire 2.x may have it's roots in much older systems, but it's also a complete rewrite, built from the ground up for it's current design philosophy and set of features. Not having a huge user base isn't the most important factor when it comes to the amount of existing/found vulnerabilities, even if some folks out there like to claim so. There's a lot more to software development than that, and the truth is that not all software is born equal. In some ways it's actually unfair to compare ProcessWire with some of the older projects out there. Not only did some of them start out as something entirely different and just grow organically (and without much planning) to what they are now, they've also got a lot of legacy payload under the hood. By legacy stuff I mean features they can't remove in fear of breaking backwards compatibility and/or can't rewrite because it'd be an enormous task. It's true that we're still relatively young, small, and agile, and for the most part simply don't suffer from those issues.. but it also looks like we might be able to keep this up for a very long time. Some of the key factors here are not leaning too much on the idea of "never break backwards compatibility", making the right architectural choices (API design, etc.) and honing our development process all the time. As a side note, regarding ProcessWire modules, the quality of those is pretty good too. The amount of 3rd party module authors is still limited, and so far we've been able to, more or less, go through each new module submission and make sure it's quality is acceptable. If we had tens of thousands of modules, that'd be pretty hard to pull out, I'll give you that.

There are resource-intensive tasks, though, and especially for very dynamic sites where caching is less helpful this could be a good thing. I'll admit that it probably doesn't mean shit for my personal site, but in the case of large services (or if you're hosting a lot of stuff) smaller savings here and there add up. So, if anyone's looking to build the next Facebook completely in PHP, better wait until 7 is out. Would be interesting to hear how PHP7, with all it's speed improvements, compares to HHVM though.. or is that comparing apples to oranges? I'll have to agree with LostKobrakai too. It'll take a very long time until this is widely used. For the most part 7 coming out will just mean that we can start using it for our own, cutting-edge projects (or projects big enough to justify setting up a customised server environment).

It does indeed sound like fulfilling this need would benefit from a completely different approach: instead of being able to globally state that "in order to see the Settings tab, your role has to have the tab-settings-view permission", this could mean creating multiple rulesets, each of which defines affected roles, uses a selector field to find pages, and allows selecting visible (or hidden, either way would work) tabs separately. Sorry, just thinking out loud..

Not really such a big deal, but.. this made me smile. Perhaps Ryan could implement couple of vulnerabilities somewhere, so that we can get some CVEs of our own?

Not saying that it's the only way to go, but I've also built a few sites where authenticated users never get to see the Admin backend, yet so far I've never considered rolling my own system for managing those users. You can simply redirect users away from Admin based on, say, roles -- or whatever other criteria you might have -- so that they never actually reach it. Works fine, and means that you can let ProcessWire handle all the troublesome authentication / permission checking parts

@adrianmak: MySQLi ($db) is kept around for backward compatibility, but $database should be used for all new stuff. In templates you use $database. In module context you'll have to use $this->database, which is automatically available there. You can also use wire('database'), available everywhere.

Otherwise this looks like a valid solution, but editing *anything* in the /wire/ directory is a bad idea. For config settings, see /site/config.php. If the setting you're trying to edit only exists in /wire/config.php, copy it to /site/config.php and it'll work just fine.

@Horst: without taking this too far off-topic, hopefully, I couldn't agree more; both about static code analysis in general (I've written multiple lengthy posts about that here and in GitHub, and have a half-finished blog post on the way too) and your real-world example. My opinion is influenced by the fact that I don't use modern IDEs at all, though, so take it with a grain of salt. Google has apparently increased the weight of those "above the fold" rules, and while they have good intentions, in many cases those have very little to do with actual mobile usability (or speed, for that matter). If it wasn't Google, I'd disregard the whole thing as another well-intending idea hindered by broken implementation, but because their opinion matters a great deal (from search engine traffic point of view), it seems that I'm going to have to make some sites worse than they are now (for humans) in order to make robots happy

None that I'm aware of. Of course you can always use PageFinder for this, but it's going to look a bit hacky: $selectors = new Selectors("template=blog-post, limit=5, sort=name"); $pagefinder = new PageFinder(); $options = array('returnVerbose' => true); $sql = $pagefinder->getQuery($selectors->getArray(), $options)->getQuery(); // .. and so on, depending on what exactly you're looking for

@bbeer: additionally, if you're using the latest version of Version Control for Text Fields, there's an option in the module settings to *not* remove it's database tables when the module is uninstalled. The purpose of this is to make transition to Version Control easier: it should be able to import old data from Version Control for Text Fields during installation. I've only done limited amount of tests with this feature, though, so I can't 100% guarantee that it will work. It has worked for me so far, but making backup copies of the module's tables might make sense if you're going to try it.