apeisa

Diogo, you might want to edit the other link too

I don't know what our guidelines are about affiliate links, but I think it would be cool at least always mention when using affiliate links. Referring to above post.

Hmm. It should be pretty easy now that PW supports page add without the two step process. No promises though about schedule.

There is definitely issues with last commit and module requirements. I opened discussion about that in GitHub (see the last commit in dev). For now I suggest using second latest commit.

Well, I think it just took a little nap (in a wrong time).

You can even show multiple fields from same page relation: architect.title architect.age etc.. And these go into "Table fields to display in admin" from "Input" tab of field settings.

architect.title

I guess Teppo is on holidays

Ah, you are right. It can be found if you go to Access => Users and use InputfieldSelector there (in regular fields). That must be because roles is system field. Good find, I think this will be fixed soon (I would assume roles is pretty common selector there ).

No need to use custom (field=value), just choose "roles" => "has" => "newuser"

Any plugins etc installed? Autosuggesting false password?

Yes, I understand And I think 90% doesn't need this kind of UA management, but those that do, will benefit this greatly. So hoping for eager testers, but not on live site fellows.

I think the one of the many super cool aspects here is that this beast sits on top of the current role system. So if you have all setup, but you want to add all those users with certain criteria (like email, age, some page relation etc) view or edit something that they currently cannot, then just add this in and all just works. Without this module, those scenarios would be pretty much impossible. Hopefully many of you find this interesting. There are huge possibilities, so this is also pretty big one to test. I am sure there will be few edge cases, but Ryan has already thought many of those (like doing edits, that remove the editing rights, adding new pages and then saving it with values that are not available etc).

I think there are two separate issues regarding 3rd party plugins/modules and their safety: 1. How good and well documented platform is to others to plug into? This "protip" from other of the articles was pretty confusing for me: Whaaat? is_admin() sounds like a function I could use to check if it's admin user... It of course could mean something else, like "is this page admin page" and then page like login could be admin page too... but none the less, it's confusing for sure. 2. Is there any kind of "approval" seal from official or credible party? It doesn't necessarily need to be "official", but if there is some company that I trust saying "this plugin is well coded and we didn't find any security holes from it - or the ones we found are already fixed" - then that of course adds confident towards that plugin. The first one is handled brilliantly in ProcessWire - documentation could always be more coherent, but I think most module developers get the basics pretty easily and source code is very well written and commented. And I haven't seen a module/hooking system anywhere that is better than ProcessWire's - and the API is very clean and coherent. Second one is more problematic, since security reviews require lots of time and high skills, that not many have. Currently I only use modules that I fully understand what they do and how they work. Module that does something with file uploads, logins or UA in general are of course most critical in this regard.

We (Avoine) have the (hairy) balls also in ScheludedPages basket.

I haven't had any need for shop since the site I build it two (or was it three) years ago. That's one reason that shop hasn't got any love from my side. I build this paypal module since it was requested so many times. It should work just fine. I would like to build some of the components again, like better shopping cart, more general payment methods, independent checkout process etc, but not sure if I have time for it (especially since the need on e-commerce had been so little on my day job).

That is bad example you have there. For pagename you need to use $sanitizer->pageName() method. But it's also possible in newer versions to let pw handle the name field, just give a title and pw transforms it to a unique name (and adds number suffix if required).

Very interesting tools, especially the upgradewire. Did I understand correctly, when using upgradewire, you don't actually use the templates & fields through admin at all, but always create new xx_xx_xx.php script, that runs all the required field, template and page changes?

It seems to be a habit for him...

Sure, Owzim, or any other fellow who wants to contribute are welcome.

I am hoping someone could take lead on this development, it's clearly going towards much more advanced use cases than I and Marty first implemented it. I have been poor maintainer (and since this is not very important for my own projects, I will be in future too) for this module - maybe you horst could take lead on this? I would start by forking this and creating the clear naming convention for this module (thumbnails ... cropimages is just messy).

It's simple to build yourself using jQuery. Try it, happy to help.

You mean instead of the default Setup page? Just create new page with admin template, give it same process than setup page has and move the pages (like changelog) there.

Congratulations on your module Pierre-Luc! I was little confused about the module name, since it doesn't really generate fields, but field values?

I think markup module that takes few variables: selector, fields, results per page and then renders the list would be cool. That could be used together with InputfieldSelector or just as independent helper. Teppo, you should build that!