teppo

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.

Cycle2 works wonders for me. ResponsiveSlides is nice and clean, but lacks support for some features I tend to need (such as custom markup).

Can't remember which service it was, but just recently I had to fill in a series of *required* security questions when signing up. There were a couple of them, ranging from "what's your mothers maiden name" to "what's the name of the city you were born in". In short, all of those were questions that anyone can dig up in an hour or so, quite likely without even relying on social engineering. I sincerely hope that they don't use that crap to "validate" anyone. In either case, they didn't provide any details about how that data is used (as an addition to email validation, or on it's own), so just to be sure I filled in some incomprehensible random stuff. I definitely won't be able to answer those questions -- but neither will anyone else. Password recovery based on email is, in my opinion, relatively safe on it's own. Safe enough for most services out there anyway. Of course it's always a question of "how much security does this service require"; combining it with security questions can enhance it's reliability, switching emails to text messages is considered even more secure (and harder to set up), and so on

I don't think I've ever seen or (knowingly) used that tag. Good to know that it exists, would definitely make things easier

When you're in charge of a large production setup, updates require planning, work, and may cause both issues and downtime, which is a huge no-no for the people (and/or services) relying on you. Everyone expects to get the latest and greatest stuff, but they're rarely willing to accept that it comes at a price. The whole point of LTS versions is that you don't have to be constantly updating your machines. It gives you peace of mind and your services much-needed stability.. and, of course, it helps keep your costs at a sustainable level You could always skip the version of any application provided by the OS package manager, but not everyone likes to do that, as it a) makes things more complicated, b) requires extra work and c) means you'll be ditching the benefits of your LTS OS for that particular application. I for one don't particularly enjoy working with old versions, but in some cases I've learned to acknowledge that it's a necessity.

The things you mentioned are exactly what I use GitHub (and local PW installations) for, on a daily basis, though I can definitely see how ApiGen might work as a nice shortcut for some of it. Seeing inherited methods/properties is nice for an example, as it does often require opening multiple files to get the same stuff out of raw code. Either way, I guess we can safely say at this point that it's a question of preference and workflow, and it's good to hear that there really are people who prefer this approach. Right now I think it's just a question of "how do we set up one that actually works" I tend to work (again on a daily basis) with versions ranging from 2.1 to latest dev, so documentation based on the latest dev (or master) alone wouldn't be of much help to me. Hence my suggestion that one should be able to browse through all versions. Perhaps that's a rare need, though -- I don't really know? This is definitely one of the few things I like about the Zend Framework programmers reference; you can easily jump between versions. @Kongondo, did you make any changes to your locally hosted version, or is it "just" an up-to-date off-the-shelf ApiGen? Is there something that we could, perhaps, benefit from? I meant what I said back there: even if I don't personally have much use for this, it would be kind of fun project to set it up so that it gets automatically generated either each time Ryan pushes something to GitHub (perhaps via webhooks), on a daily basis, or something like that