teppo

From what I can tell, mod_php is really less secure in some ways than FastCGI (or SuPHP, for that matter) , thought it's (partly) a question of configuration and environment: Main issue is apparently that mod_php runs as the Apache user (in Ubuntu that would typically be www-data), which means that you'll have to give this user r/w access to various files and folders on the disk. Some articles make this sound worse than it really is, though; you most definitely don't need to give it full access to all your files. Still, this can be a problem, especially in shared hosting environments. Also, unless you set up separate Apaches for each hosted site, if one of those sites has (critical) security issues, it could potentially compromise all other sites too. To answer your question: when you're in control of the whole server and can set up permissions as you wish, I don't see this as a huge problem -- or, rather, I see it as a reasonable compromise. PHP as a module happens to be extremely fast, especially compared to something like CGI. You do want to be careful about what you install and run (and how you setup permissions on your server), but on the other hand, that's common sense anyway. FastCGI needs more memory than mod_php, but provides more security too. CGI is by default both insecure and slow, but can be configured to be somewhat more secure. SuPHP is somewhere in the middle, more secure than mod_php but also slower than FastCGI or mod_php (though SuPHP memory consumption seems reasonable; this seems to be something of a problem for FastCGI). Looks like your best bet would be either FastCGI (for security) or mod_php (for speed); latter requires care when setting up your environment, while former will apparently be slower no matter what you do. Decisions, decisions (Note: I'm not an expert on any of this. I've always used mod_php for various reasons, and am pretty much used to any insecurities it brings about. Right now I'm looking into FastCGI myself, and I know that others have made PW run with it, but this isn't very high on my list to be honest.)

In a bit of a hurry right now, but if I'm reading you right and resizing couple of images takes 20-30 seconds, that's definitely not normal. Of course source images can make a huge difference, but still that sounds really slow. Unless you're running a really, really low-end server, perhaps, which doesn't seem too likely judging from your previous post. (Note: most of the time there's no need to store images larger than, say, 1280..1600px. Of course this depends on your needs, but usually I find it more sensible to resize huge images to a slightly more reasonable size when they're first uploaded. This is where max image size settings in image fields come in handy.) I'm actually a bit confused about your setup. Worker and prefork are different MPM modules, so which one is it that you're running? Also, you've mentioned you're using CGI; that seems like a bit of a weird choice. CGI is supposed to be very slow compared to running PHP as a module (mod_php). FastCGI is apparently faster than CGI, but to my best knowledge mod_php is still going to be faster (and from what I've seen, FastCGI seems to cause weird issues here and there -- though don't take my word on it!) So, as a first step, you might want to take a closer look at your Apache configuration

I'm not aware of any magic config flags that would solve this, sorry. Actually, I'm not even entirely sure if this is something that PW alone can handle -- not much of an expert when it comes to stuff like multithreading, but I'd say that it probably depends a lot on how your Apache is configured, which MPM it's using (prefork, worker, etc.) and so on. Sure, I've seen tricks like sleeping a few (micro)seconds between tasks to allow other processes get resources too, but that's just about it Before getting too worried, though, you might want to consider if there really are going to be hundreds of operations on huge images all the time after after your site has gone live. For most sites this won't be the case, and in a situation like you mentioned above (one core with 50% load, another sitting idle), you've still got plenty of resources to serve regular visitors. In any case we've had no issues with image resizing on our production sites, ever, so I wouldn't worry about this too much. One thing you could try if you're really worried about images in particular would be Imagick. From what I've heard, Imagemagick (which Imagick uses behind the scenes, unless I'm somehow mistaken) seems to be in some cases faster than GD. This thread would probably be a good place to start, if you're looking for a PW solution (not entirely sure about the state of that project, though). Hope this helps a bit.

Not going to argue that you shouldn't try renaming the wire directory (you shouldn't), so I'll just jump in to mention that what @interrobang pointed out above is very, very important. The .htaccess file, among other things, protects ProcessWire's core system. If you do end up renaming the wire directory, make sure that you also make changes to any protective rules in that particular file (and potentially elsewhere too). The important thing here is to understand that by making changes to something like the wire directory location, without fully understanding what it means and how it might affect other things, you could easily be causing new security issues where there were originally none. Just saying. "You've been warned", and so on

Don't worry -- you've made yourself more than clear, and I agree with pretty much everything you've said here too. Very good points, and hopefully we can address some of them soon

@Ivan, that's good to hear. Didn't think that you'd be criticising either (sorry if it sounded like that), just wanted to address some of the points you listed as "tasks for organised community which have not been covered yet". I most definitely appreciate what you're saying -- and, like I said, you've made some very good points What I meant to convey was mainly that many of such tasks are handled already, we just haven't listed (or gathered) any official teams for specific tasks -- other than the forum moderating team, in a way. There are also named people taking care of some specific tasks, such as approving sites directory entries, but those probably haven't been listed anywhere publicly either. It's true that perhaps we should have named teams, and make it obvious who's responsible for what. We've mainly been trying to avoid creating any unnecessary structures and (harmful) bureaucracy, but things like the community rules and guidelines are already an obvious step towards being more organised, and we've always tried to make it obvious who you should contact if in any doubt. Either way we're still a relatively small community, and we don't want to (or need to) act any bigger than we are. Doesn't mean that we won't act when it's time for that, of course, and I personally see discussions like this as valuable indicators about whether we should already do something "in a bigger way"

@Ivan: you've got some very good points there. At the very least these are things that should be mentioned somewhere; for most parts the situation isn't quite as "unorganised" as it apparently seems You're right in that Ryan Cramer Design is the only company "officially" behind ProcessWire, but we do also have some corporate sponsors, such as Avoine. Programs like the ones mentioned here could still be a bit problematic for us, as those probably work best when there's a larger company behind the system, but I'm not an expert on this, so what do I know. About your other points, the forum has a dedicated moderating team, and there's some kind of a process for most of the things you've mentioned. Regarding the roadmap, for an example, anyone can make recommendations; that's what Wishlist & Roadmap is for. Modules directory is currently managed by Ryan, and a lot of folks contribute to ProcessWire, though at the end of the day all core contributions go through Ryan's hands (intentionally). We're also already doing a lot of marketing, though it's often somewhat subtle; word of mouth, comments here and there, articles, videos, and blog posts. ProcessWire Weekly, ProcessWire Recipes, ProcessWire.tv, isit.pw, and many other sites and projects are geared towards getting the word out there too. Sure, we can (and should) do even more, but just wanted to point out that a lot of stuff is already happening

@Marvin: thanks for this, the module looks great! Would be interesting to see some sort of a comparison between GIM and PIM features, though, as it's not really obvious from a quick glance what the differences are Would you mind adding a link to this support thread to the modules directory page, by the way?

How 'bout simply doing this? $page->$fieldName->address = $value; See Ryan's first post in the Map Marker Fieldtype thread for usage examples.

Site profiles are definitely the way to go if it's something you can decide right from the start; "to begin with, this site will have these fields, these templates, ..." etc. Module would be more beneficial if it's a feature you may want to add later on. A blog or discussion module installing its own fields and templates, and so on. For the actual answer, you don't use hooks for this. Include install() method in your module, and create anything you need there -- and uninstall(), if you want to be able to clean up anything created by this module just by uninstalling it. These run automatically when ProcessWire installs or uninstalls a module. For examples, this is how ProcessVersionControl does it, and here's how it's handled in ProcessUserGroups.

On a bit of a hurry right now, so just hopping in to mention keyword "circular reference". This has been discussed every now and then, and current situation (unless I've missed something) is that it's (intentionally) prevented for Page fields. There have apparently been some changes regarding circular reference checks recently, so it might've been possible at some point, though it was never really intended Anyway, I'm not saying that this shouldn't possible, just trying to provide hopefully some insight about why this might happen. If you need a quick way to get past this, one option would be removing current page from selectable options and including a single checkbox, something along the lines of "this page itself". Or something like that

If it's log messages you want to catch, as long as they go consistently through the API (instead of creating separate FileLog objects, as we used to do it), there's no need to wait for anything; WireLog ___save method ($log->save()) is already hookable. Messages and errors are a different thing in ProcessWire, and catching those would probably happen using $notices. There are few things that aren't doable in ProcessWire as it is, and we've been adding new possibilities all the time. The value of aforementioned concepts and standards, as I see it, is framework interoperability (d'uh) much more than enabling something new in ProcessWire specifically Anyway, my first impression was that both PSR-3 and PSR-7 seem pretty solid, but we already have similar solutions in place, and whether those should be dumped in favour of PSR -- or altered to be more similar -- is a bigger question and depends on Ryan. PSR-2, on the other hand, has been discussed here a few times already, and currently it seems unlikely that we'd be adopting that for PW. The way Matthew's post explains middleware makes it sound like an interesting concept too, and certainly being able to switch components and even share them with different frameworks etc. is a neat idea, but other than that I can't really comment on this yet.

True Anyway, you haven't specified where you deleted these fields from; since they're referenced (at least) in tables "fields" and "fieldgroups_fields", in addition to having their own database tables ("field_fieldname"), you'll want to make sure that there's no leftover data anywhere.

I've seen this before, though didn't debug further, so can't provide any additional insights right now. Just confirming that it's a real thing, and affects at least some Mac Chrome users

Thanks for this, folks. Looks great, can't wait to give it a try! As a minor observation, you might want to repeat some of the recent fixes for Thumbnails module here too (strict standards, repeater permissions, etc.)

Just for the record, aforementioned issue is now fixed.