adrian

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

Yes, it's about automatically changing the name to match the new title. Not sure - it's working here: Change title and save: EDIT: I just figured out that there is a bug when the "Allow user to change "Overwrite Names" setting is checked. Can you confirm that it works for you without this? I'll fix shortly. PS - any idea why those table headings have outlines?

Hey @Macrura - these sound like very useful additions - I haven't had to deal with multiple domains for the one site just yet, but I can see it coming up for me shortly. I'd love to see this module have a new life. I used to use WireMailSMTP with MailGun, but recently it started having issues with CC'ing so I decided to start using this and it's so much faster using the MailGun API compared with SMTP. I don't suppose you'd like to step up and take on supporting this? I'd like to, but I already have way too many modules. Cheers!

PS - you can also do this to get the second page of results. So 400 + 161 shows the total 561 modules currently in the directory. I still think we should be able to get all in one call, but this is still useful to know.

BTW, if you try 500, then you'll only get 10 returned. 400 is the highest valid limit. See my revised screenshot in the last post where you can see the 400 items.

Sorry if I wasn't clear - the idea was to have it one the PW homepage instead of (or in addition to) the API examples so potential users can actually play with them and generate output returned via AJAX - just like the Console panel. This sounds really great, but is there actually an interactive code console that can run code, or do you need to edit template files with your code editor?

New version committed and it is now named Admin Tools.

I totally understand. It's a shame though - I feel like this module is going to be lost. I am a big fan of MailGun and I know Ryan is using this but I'd love to see that send method removed in the official version - I think it's cons outweigh its pros. Getting a bit OT, but I think in general PW needs to figure out how to handle modules written by folks who've moved on.

On the issue of page() vs $page it's actually unfortunate that page() can't be overwritten because I often use the Tracy console in the admin when editing a page. $page is automatically set to the page you are editing, but of course page() will return the "/admin/page/edit/" page. I don't think this is a valid reason to NOT promote the use of page() as the default approach, but it is something to be aware of.

I've suggested this a couple of times above - making use of the Tracy Console panel - either as is, or more likely using the code behind it to have something that can be embedded in an iframe on the page itself.

Hey @tpr - not sure what its purpose is, but: html.aos { overflow: overlay; } does weird things to fixed position elements. For example, when Tracy is disabled, the icon that appears in place of the debug bar (to re-enable it) is positioned under the vertical scrollbar. If I remove this overflow rule, it is positioned as expected. Thanks!

What about Admin Tools? I think if all we are trying to do is not match the name of the Admin Actions module, then this is probably this simplest and most descriptive.

Sorry guys - I was never given site submissions approval and I actually don't have a login for the website backend anymore either so I'm afraid I can't help with this one. Maybe just an oversight by Ryan, but I really don't know.

Sorry for the confusion @Robin S - it was a failed attempt at humor ? I was trying to make the point that there are way too many options - some are intentionally provided and some are just due to class inheritance etc, but I personally think we should be very careful to document just one default approach for all examples and then properly explain the other options and where they can/need to be different to the chosen default approach.

Well I am assuming at some point I'll be adding some actions that aren't destructive ? Thanks @szabesz for the name suggestions. I'll marinate on it for a while.

I'm not too worried about it, but I do see your point. I wasn't sure what else to call it at the moment. If you have a better idea, please let me know. Obviously this panel has has a few limited/restricted actions, so it's not meant to be a replacement for the Admin Actions module - just some quick shortcuts to a few things that I come across semi-regularly.

BTW - Pete mentioned to me elsewhere that perhaps the modules directory should take care of caching a json file with the data for all modules - that was this module won't have to take care of it and the load on the PW server will be minimal because it will only be serving a fairly small json file with no database calls accept for when a module is updated/added. Of course we need to get Ryan on board with this approach.