teppo

Problem might be that anyone planning to pay their taxes properly (and sell digital products to EU) will need this by 1st of January. As long as there's a manual step involved (someone buys a digital product and I ship it, i.e. send it as an email attachment or something like that, manually) this is not a problem, but if the system automates this, the shop owner will have to consider EU tax legislation. Minimum support would consist of logging two separate details about the users location, such as IP address (perhaps automatically converted to a location) and a separate question for location. If those don't match, there's a problem, but if they do, the shop owner knows where to pay taxes for that specific product. You're right in that digital goods are only the first step. Unless, as I really (really really really) hope, they eventually realise that this whole legislation is an awful and broken idea..

@NorbertH: https://github.com/apeisa/ProcessUserExtended. UserGroups isn't in the directory either, so no big difference there. Also, UserGroupsProcessUserExtendedIntegration (so proud of that name..) is a module that you install by hand, so just leave it out and this should be even less of a problem. It's only a bridge between UserGroups and ProcessUserExtended

Sure, though the approach depends a lot on your needs. Are your top menu items always placeholders for grouping pages or can some of then be actual pages, how deep or complicated will your site hierarchy be and does the top menu have to reflect that somehow, etc. Assuming that this is a very simple setup (no real pages in top menu at all), one approach would be creating top menu structure somewhere else (as pages), and adding a "top menu parent" Page field to pages. If a page has this field filled, it'll be displayed under said top menu item: - Home - Who we are - About us - History - Values - Meet the Cashmaster Team - ... - Topmenu - About Us - About You - ... You'll need to write your own code to create markup for the top menu, and probably side menu (if you use one), but that's just about it. Something like this should work: echo "<ul>"; foreach ($pages->find('template=top-menu-parent, sort=sort') as $parent) { if (!$parent->numChildren(true)) continue; echo "<li>{$parent->title}<ul>"; foreach ($parent->children as $child) { echo "<li><a href='{$child->url}'>{$child->title}</a></li>"; } echo "</ul></li>"; } echo "</ul>"; Anyway, this is just a very crude and basic example, so if your needs are more complicated than that, there are other approaches that may make more sense. Path/URL rewriting might be one option, etc. In any case most likely you'll never need to change any core code

Antti: are you planning to include tools needed for complying with the new EU tax legislation? Just checking, since you've included things like "downloadable products", which would probably benefit a lot from this

Try Google image search for "padloper". Just a guess, though, Antti might have completely different explanation for this

On mobile so just a quick reply: strings work just as well. I've posted about this earlier, but IMHO whole integer version idea is flawed, exactly for the reasons you mentioned above. They can only represent a subset of version numbers. People also keep confusing them with octals, which is another issue..

+1 for the idea. For the implementation, I'd suggest encouraging module authors to implement Semantic Versioning or similar strategy; no need to include special flags, fields, etc. when version number itself clearly states if there's a (potential of) breaking change.

@kongondo: had to check, and apparently column is a reserved word, row and value should be fine. Either way, prefixed values make sense after all, no point in having only one prefixed. Also, I kind of prefer matrix_* over m*, and matrix_value over data, so wouldn't chance anything to be honest

@kongondo, this looks great, thanks for making it available! Will take a closer look soon, but just a (very) minor note at this point: I can't help wondering why the subfields are prefixed with matrix_ -- doesn't honestly matter that much, but I fail to see much value in that either, just slight increase in verbosity compared to non-prefixed alternatives

Agreed. The modules directory is the only guarantee we have of a module being of good quality. I don't find it harsh at all to say that don't trust modules not submitted/approved to the modules directory (I've been stating that already on many occasions), and when it comes to security, it's always better to be too harsh than too lenient In my opinion a module not being submitted to the modules directory is a sign of the author a) not knowing much of the ProcessWire environment / ecosystem (which can be a bad thing), b) not considering the module ready enough for the directory (in which case it definitely isn't ready for production use), or c) the author being too lazy or busy to submit the module (which means that the support will most likely be lacking too).

Antti: I've been looking into this particular tool, and so far I'm liking it a lot. Just wondering if you've had the chance to run it against any real projects, and if you found it useful? Did it spot any real issues, etc.? I'll have to go through the rest of my own projects to see if it can spot anything really suspicious, but so far only issues have been a README file not ending properly in a newline character (!) and a module file having a bunch of @todo comments (makes sense to flag these as potential risk, though in this case they were ideas for future enhancements/additions, so not really relevant at all).

Thanks. That would be very helpful (probably), since right now I'm kind of out of ideas here. It's probably something simple, I'm just failing to see what it could be.

So you've subscribed to php[architect] too? That's kind of cool, actually Anyway, that article was intended as an introduction to ProcessWire and it's core concepts, so don't expect to find anything too fancy. Just trying to get the word out there

@Macrura: if I'm getting this right, you're just adding a page to a PageTable field, and when Version Control is installed, this fails with a 500 error (internal server error). The page (review) itself gets added and saved properly, apparently. To be clear, which template did you remove from Version Control enabled templates -- the one used for reviews or the one containing the PageTable field? Also, is there anything added to the error logs of Apache or PW? I was kind of assuming that this module would attempt to store values for the PageTable field itself, which could've easily resulted in an error (don't think that I ever tested that), but since it's not in the supported fields by default, that's unlikely. Unless you've manually added PageTable to the list of supported fields? Any additional info would be helpful. I'll continue testing, but at the moment I'm kind of lost here, and haven't been able to reproduce this issue. Edit: added PageTable to supported fieldtypes locally. Doesn't work (as expected), but doesn't seem to break anything either. Will continue debugging.

Also: http://modules.processwire.com/modules/inputfield-textarea-markup/. Self-promotion, again

I guess this counts as "on the web": http://www.phparch.com/magazine/2014-2/december/.

@apeisa: definitely. I've been test-driving a few locally-hosted solutions, with mixed results (some were "kind of useful", but none really convinced me). Sensio Insight seems interesting alternative, though so far it seems to think that my code is safe, which is a huge red flag to me .. oh, and for the record: programmatic vulnerability scanning is helpful, but I'm always a bit worried that people could trust it too much. There are too many logical issues for it to be "perfect", and thus it might give some users false feeling of safety.

This is the key point here: API. It improves the security a lot compared to having to rely on plain SQL, which is always more or less prone to human error, leading to injection vulnerabilities, etc. Another thing is that most modules seem to avoid potentially harmful methods like exec, shell_exec, passthru, etc. Not sure if that's really anything specific to ProcessWire, though Anyway, one can still easily write a ProcessWire module that trusts user input too much, or trusts input from wrong users, or simply displays too much to unauthorised users. This is why some sort of security audit process would be most welcome, though perhaps as an addition, not something that automatically applies to every module submitted to the modules directory.