adrian

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.

Don't forget about: $this->pages $this->wire->pages $this->wire()->pages $wire->pages wire()->pages wirePages() _wirePagesAPI('pages', '') That's a total of 11 variations that I've found so far, although obviously the last one is a bit silly ?

Just added a new Admin Actions panel - the available actions are context sensitive so you only get actions that are relevant to where you are in the admin (or frontend in some cases). This is just a first version, but so far we have: Delete all children This lets you delete all children of the current page without deleting the page itself which can be very helpful when you're testing API creation of page and you have forgotten to enable Tracy's Page Recorder panel. Delete field If you're on the edit interface for a field, this action will let you delete a field even if it is already added to templates, so you don't have to deal with the "This field may not be deleted because it is in use by one or more templates." notice you get when trying to delete the field. Change field type Again, if you're on the edit interface for a field, this lets you change the field to any installed field type. This ignores the compatible field type check that you are normally subject to. This is probably not good to use if you already have page data in this field, but it's really handy when you have already set up a field and added it to templates but decide you want to change its type to a non-compatible type. Delete template Like the delete field, this bypasses the "This template may not be deleted" because there are pages already using it. This takes care of deleting any pages using the template and then deletes the template, all with one click. Uninstall module This will take care of deleting any associated fields (for Fieldtype modules) and modules that require the one you are trying to uninstall so that you can uninstall the module with one click. Hopefully it goes without saying that these can be extremely destructive and bypass core protections against data loss so use with extreme caution. Each action has a confirmation dialog that you must confirm to reduce any accidental clicks and the entire panel is restricted to superusers only, but you must still use with extreme caution. I'll add other actions as ideas come to me, but if you have any requests, please let me know.

More info: https://github.com/processwire/processwire-issues/issues/126

https://github.com/nicoknoll/MigratorWordpress - it handles post and comments automatically but if you already have the posts imported maybe you could at least steal some code from this to help with your comment importing.

Nice - much better than my "Inspect Element" approach ?

Now that Github topics tags have been around for a while and most of us are using them, this is becoming a pretty useful link: https://github.com/topics/processwire?o=desc&s=stars

In the template context, how can $page be any page unless you have overridden it, which we always discourage. Otherwise, $page is always the current page. I do understand that page() can't be overridden like $page can, so maybe going forward the functions API should be the recommended approach, but we are going to confuse the hell out of beginners if homepage examples show both approaches. But the save() example won't work as is and will confuse the user to see an error about outputformatting which they will not understand anything about yet. We have setAndSave() - why not use that example? Same goes for my observation about the image example and the issue with the need for first() on the site profiles which I think mostly come with "images" fields, rather than an "image" field. As a new user to a system all it often takes is one unexpected error early on to send them packing - I know I have done that myself. Sorry to be so blunt but I feel like many of us here have expresses our concerns regarding this - either through lots of likes on my posts above about it, or through their own comments. Please accept these comments in the spirit they are intended, which is to help make PW easy for beginners to fall in love with.

Ryan has just modified all included site profiles to turn on the functions API by default although I am not sure why the change wasn't made in the wire/config.php file so it works for all profiles even if they come from another source - I am sure I am overlooking a good reason though. Regardless I still don't like the mix of approaches used in those examples, but that has been discussed above ?