adrian

There are lots of issues with Roles and Permissions hooks as well: https://github.com/processwire/processwire-issues/issues/360 Perhaps it would be worth commenting on that issue that User hooks also have the same problem. These really need to be fixed.

I've just added docs for PW procedural functions including the functions API. These are available in the API Explorer, and also code completions for the Console and File Editor panels. I refactored quite a lot of code to add this, so please let me know if you notice any problems.

BTW, I know that https://processwire.com/api/ref/users/added/ shows that Users:added is hookable. Interestingly, I don't think there is actually a link to this page anywhere, certainly not from here: https://processwire.com/api/ref/users/ where you would think there would be one. I think there still needs to be some work on the docs for stuff like this. @ryan ?

There is no direct Users::added method. Maybe you can use Pages::added instead and check that the template is the user template. I feel like Users should inherit Pages::added, but it doesn't seem to work, but Pages::added does.

No idea why, but https://processwire.com/: results in a 404 page without any loaded assets. In fact a semi-colon in any url causes the same result. Actually it seems like it's a procache issue based on the pwpc errors in the console.

EDIT: I see that the functions in question are tagged as pw-internal so I guess that's why they are not listed so you can probably ignore this post! @ryan - regarding the new procedural functions docs, it seems like there are several ones missing. Not sure if these are intentionally not listed or it's a bug in your API Explorer code. I have been updating the API Explorer in Tracy and on first glance I have noticed that you're missing tabIndent(), wireEncodeJSON, & wireDecodeJSON in the main Functions.php file and in FunctionsAPI.php you're missing the inputCookie(), inputGet(), and inputPost() functions. However I expect there might be others also missing. I haven't committed these changes to Tracy just yet, so here's a screencast of what it is finding.

I have mentioned this one before, but I think it's weird that we have a $urls variable, but not a $paths variable. With the functions API we actually have both urls() and paths() which seems like a weird inconsistency to me. Is there a reason for no $paths variable? Even the docs (https://processwire.com/api/ref/functions/paths/) suggest: // basic usage $paths = paths();

Of course, but even if you haven't overwritten $page, if you are using page() and you get a message to do $page->of(false) it is still confusing.

I have an interesting scenario for you though. Say you try this: So then you try: which of course also doesn't work if you're not actually on page 1023. So maybe it's a simple matter of changing the exception message to not specifically state: $page->of(false) because that could cause new users some pain. Hopefully they won't be mixing $page and page() calls, but if they did, then it would be confusing.

@Robin S - That's a really good point about needing to turn of outputformatting before setting the field values. You're absolutely correct that it must before off beforehand. I knew I must be forgetting something ? I guess there really is no shortcut for this, other than setAndSave() which is obviously one field at a time, rather than all fields on the page/template. My only other thought is when would you want to actually set a field value to a formatted version? Could setting always apply unformatted values? I guess this gets messy because you never know how the developer might want to handle things so I suppose the current situation is probably the most flexible option. I'll go hide now ?

@ryan - I have been thinking about that save() API example on the homepage and my complaint about the fact that as is it will fail with an error. It has made me wonder why the pages->save() method can't automatically turn off outputformatting itself? So I started looking around and found @thetuningspoon 's excellent thread here: https://processwire.com/talk/topic/10485-simplify-output-formatting-when-saving-pages-via-the-api/ Obviously when saving via the admin, PW takes care of turning off outputformatting, so, I am curious why it can't handle this for us automatically via the API as well. I know you must have a good reason (you always do), but the only thing I can think of is that it's basically an educational thing - it helps users to understand what output formatting is. If so, I agree this is important to understand, but I still don't see why the save method can't do this for us. Thanks for your thoughts on this.

@flydev - it's not currently possible, but I am interested in implementing something along these lines. The question is how and what. What format would make things easiest to compare? What info do we need to export? What panels are relevant? Should we have a separate export that combines certain key data from multiple panels? Any thoughts?

Thanks @Macrura! One note about the readme - it says: $mail = WireMail(); I think this should be changed to: $m = $mail->new(); or at least it should get the case correct so it's wireMail() instead of WireMail() Regarding a config setting for the public send() method. I think the way you are thinking, but I think we need to work towards it not being there by default. I think if you do a major version number bump before your fork goes into the modules directory we can get away with this. I just think it has the potential to break other modules because of the issue with hooking into send(), most notably is Tracy's Mail Interceptor which I use all the time for testing which I expect others use too.

I do like the style - sorry if that came across incorrectly. I just it could be trimmed a little, but not a big deal.

Ryan - thanks for all the work on those docs. I'm afraid my concerns around mixing approaches in the examples on the homepage still stand, but it's definitely great having the differences / pros / cons documented, even if a little verbosely at the moment. I am kinda curious why the procedural functions are documented now. Perhaps there are still several that don't have object oriented versions, but I guess for consistency I'd rather see them all have an OO version available and make it clear that those are the primary methods to use. Or do you find yourself using the procedural versions in certain situations still? Could you please document when you would use these over their OO versions?

Nope, I just tried and it was converted to: minitab-statistik-datenauswertung Based on what you are seeing with BCE and PageRenameOptions, I feel like maybe you have some other code that is hooking into page name generation and messing with things.

Hope you like it - I can't imagine using PW without it ? , especially during the development phase.

@dragan - any chance you have the Settings tab hidden? If the title isn't changed, nothing gets updated. It shouldn't be relevant, but do you have PageRenameOptions installed? If so, what settings?

Is it a Vue issue or CORS with AJAX in general? https://codepen.io/adrianbj/pen/QzXwGz?editors=0010 If it's just Vue related, I use AXIOS for this stuff: https://vuejs.org/v2/cookbook/using-axios-to-consume-apis.html PS, it's looking great! PPS - why AJAX - given how small the JSON for all the modules is, why not just load everything at once via PW's $http->getJSON()

I doubt that Ryan has rejected you for any such reasons. I would PM him and see what he says

Actually, I've had another look at this and actually it seems to be working just fine. Given that you have the "Allow user to change "Overwrite Names" setting checked, are you then actually checking this in the edit interface:

I guess I am talking about the approach that module uses of loading up an admin page in an iframe. Perhaps you could adapt it to your needs to allow access to certain parts as a guest user. Not sure - sorry if I am completely off-base with what you are looking to do.

I still really like this solution:

Of course Gitlab has: "Unlimited private projects and collaborators" but this move by Github will probably have me move from Gitlab for most things.

Awesome! Can I make a request to remove the public send() method so that it doesn't break hooks to ___send ? The catch with this is that it's a breaking change for anyone using: new WireMail() but I think it's an important change. Let me know if there is anything I can do to help.