teppo

$page->image (assuming it has the capacity of containing multiple images) returning only first image is a problem if you're going to iterate contained images. Sure, you can make $page->image return first image of many, but then you'd need another method, something like $page->image->getArray() in order to iterate over many items. I don't think that one use case trumps another, especially since it would be a breaking change. Judging from your sample code, I'm kind of wondering if you are aware that $page->image is just a call to custom field called 'image', not something that's really built-in to the core? If that's just a proof of concept, that's cool, but in real-world use cases you can't reliably assume field 'image' to always exist Edit: forgot to mention that the ability for multi-file field to return single item has actually been added to dev branch. It's not quite what you described it (it won't work as a method) and the use case might be different from what you envisioned (though what do I know..) but you might want to check it out anyway: https://github.com/ryancramerdesign/ProcessWire/commit/83826e993ecd57af22373cc878abac8a51f11ffe. Edit 2: re-reading your post, you seem to use 'image' and 'images' somewhat interchangeably, when, in fact, there's no connection at all between these. Changing max files allowed to '1' in field 'images', like you mentioned in your post, definitely won't enable $page->image. Perhaps I'm misinterpreting this (or it's simply a typo), but if you're suggesting that $page->image should point to first item in $page->images, that's not feasible, as 'images' is also a custom field with no guarantee to be around everywhere (and any template might have dozens of other image fields too, which would then need similar logic).

This is one thing that Zend Framework nailed perfectly; in typical setup your entire application lives one level beyond what's directly accessible from the web. I liked it, and it's also something that the security chapter of Programming PHP and the OWASP PHP Security Cheat Sheet suggest.

Perhaps we're talking about same thing here, but what I meant is that these are just about all handled by ProcessWire out of the box, in one way or another. Probably the most important things webmasters can do are a) avoiding shared hosting like the plague (there are a few examples where this is done right, but usually it's broken and/or a compromise between security and usability) and b) handling server-level permissions properly. I tend to stick with pretty strict permission model and, for an example, won't ever give ProcessWire itself (i.e. the Apache user) permission to write anywhere it strictly speaking doesn't need to write. IMHO making things like .htaccess writable for Apache is not such a good idea, but perhaps that's just me being paranoid. In your post you said that "Set 777 permissions on important content", which seems kind of backwards to me. 777 isn't really harmful in controlled environments, but it's very rarely needed either, unless your permissions, groups etc. are configured in a really weird way. Sometimes it's easier to use that if you don't know what sort of permissions, users and groups the server will have, but that's just about all it's ever good for in this context.

Clearly defined review process is a good thing to have, +1 for that. I've found this essential in larger projects, but it's not very easy to get right level of specificity. You do want to make sure that all the important things are checked yet you don't want to limit too much (and a process that's defined but not used and/or followed is worse than not having a process at all, as it only gives you false confidence.) Something that scans for vulnerabilities would be very interesting to see in action. It should not be relied upon, but could definitely be used to spot the most obvious sources of potential issues. The main problem is that it can't really distinguish between valid use cases of those "potentially problematic" things: SQL queries can be an issue, except that some modules really need those (and even Ryan has suggested using them a few times on the forum). Calls to system(), exec() and/or shell_exec() can be very dangerous, but some modules can and do use them appropriately. preg_replace() with 'e' modifier is dangerous, but again far less dangerous if used properly (not letting user input affect it etc.) External libraries (and thus any call to include(), require() etc.) are always sources of potential security issues. Any user input is a potential issue, unless properly handled (nearly impossible to distinguish by static analysis.) Anything related to handling files yourself is potentially dangerous. .. and then there are a ton of very real security issues that would be next to impossible to spot just by programmatically analysing code. Anyway, I'm definitely not against such a scanner (and have, in fact, been evaluating a few code analysis tools lately) as long as it's not thought to be some sort of miracle cure. It's not. RIPS is one of the options for doing this kind of thing without writing a ton of code yourself, but it seems that the project is kind of dead right now. No idea when that happened or at what state the existing code base is in, but I wouldn't count too much on that either. I'm not going to comment on the rest of your post except by mentioning that this doesn't have much to do with ProcessWire

The problem especially with any markup-generating modules -- there's an unlimited amount of possibilities. Unless the thing you're trying to achieve is relatively simple ("list tweets from this user account") or implements very extensive markup configuration options, you'll end up with a ton of modules doing just about the same but with slightly different markup Definitely something to consider for us too: as a general guideline, if there's a module that does just about the same already, it would be awesome if module authors would seriously consider working together instead of posting near-duplicates just to address some minor difference of opinions. Just saying -- I know it's not easy in real world use cases. Still I've seen that happen many times over on our modules, which is great

In addition to what @adrian said above (it's true that without knowing how exactly your "include & bootstrap" code is set up this is very difficult to debug), you mentioned that logging in helps and things start working instantly. This really makes it sound like it could be related to caching, which is then disabled once you login.. or perhaps permissions, though those shouldn't matter at all for API use. Just for the record, is this site hosted on your local machine or a remote server? As a first step when debugging site issues you should always take a look at the error log files (/site/assets/logs/errors.txt) of both sites, in case that something went really wrong. Server logs (Apache logs mainly) may also uncover something of interest. Please let us know if there's anything strange there from roughly the times this has occurred.

Just for the record, here's how PW itself (in current dev branch) is doing it: $config->cli = (!isset($_SERVER['SERVER_SOFTWARE']) && (php_sapi_name() == 'cli' || ($_SERVER['argc'] > 0 && is_numeric($_SERVER['argc']))));

@bracketfire: that's a cool way to do it, but whether it's the best approach depends on what you're trying to achieve. It's entirely possible, although quite rare, for $_SERVER['HTTP_USER_AGENT'] to be missing from non-cli requests too (it's a header after all), so checking for cli use doesn't entirely prevent this notice from appearing. If the underlying issue is that $_SERVER['HTTP_USER_AGENT'] isn't found and it's necessary for this module to work at all (haven't checked the code so can't really tell), it would probably make more sense to simply check for that specifically with isset(). On the other hand, if the module isn't useful in cli use at all and $_SERVER['HTTP_USER_AGENT'] isn't necessary for it to work properly in non-cli use case, it would make most sense to apply your fix (skip the module entirely for cli users) and add an isset() check to prevent unnecessary notices for non-cli clients that don't, for any given reason, send this header (Sorry, meant to point out something simple, but this turned into a kind of a long rant anyway..)

Sounds good to me! Config setting is a good idea too

Looks great Marcus, I'm looking forward to trying this out! Just thinking out loud, but you could, perhaps, simplify this a bit without sacrificing any flexibility: // the sprintf way echo $flags->renderLink("Add %s to flags", "Remove %s from flags"); // the placeholder way echo $flags->renderLink("Add {flag} to flags", "Remove {flag} from flags");

Thanks Adrian! This has been on my to-do list for a while, looks like I can tick it off now. Benefits of free software -- just wait long enough and someone will solve it for you The way I've seen this implemented before was a checkbox titled "Force password change on next login", which was unchecked when a password was changed. That would slightly simplify things by removing the need to check it for existing users.. and perhaps make things a bit easier to understand if you want to use it at some point later (for some reason unchecking "password changed" sounds weird). Just saying, doesn't matter much either way. The module looks great and I look forward to using it.. on all of our sites Edit: by the way, would you mind specifying a license for this module? I'm not suspicious of your motives or anything (honestly), it's just that I try to avoid any code where licensing isn't clearly stated, and modules are no exception here