teppo

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.

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).