adrian

Go to the field edit page in the PW admin and then in TracyDebugger open the RequestInfo panel. This shows you all the properties currently set for a field. Just use these in the API as needed.

Try @Mike Rockett's sitemap module: http://modules.processwire.com/modules/markup-sitemap/

I just posted a new version of Tracy that may also help a little with this sort of thing: https://processwire.com/talk/topic/12208-tracy-debugger/?do=findComment&comment=173674 by highlighting invisible characters (as well as the non-printable ones in the above screenshot).

New version adds some configurable settings for the ACE code editor used in the Console panel and the File Editor panel: I went with the defaults I like, but adjust to suit your preferences - don't judge my use of spaces over tabs - it's mostly about consistency when pasting into web forums and other places, but if you need another reason: Developers Who Use Spaces Make More Money Than Those Who Use Tabs ? I am also a big fan of 4 character indentation but I do know that some people prefer 2, so take your pick. The one thing that is new is the intro of Show Invisibles being set to true. That results in the following which I find quite useful at times. Note the highlighted (in pink) character at the end. That actually isn't due to the Show Invisibles setting, but I thought I'd include in this screenshot to bring attention to this thread: https://processwire.com/talk/topic/19995-changing-structure-of-pages/?do=findComment&comment=173671 and how the Console panel can be a useful tool in finding non-printable characters that are causing syntax errors in your code.

You can also paste the code in question into Tracy's Console panel. Note the highlighted non-printable character at the end and also if you try to run the code, you'll get a syntax error.

On the Advanced tab: Also, in case it's useful, there is this module for restricting by page / branch: https://processwire.com/talk/topic/14891-restrict-multi-language-branch/

Well I do sometimes have an unpublished page as a parent for published and viewable children. Is there any reason to exclude unpublished - so long as they are not being added to the sitemap themselves, I am not sure why it matters. What's your reasoning for not wanting to include them?

I'm afraid I don't understand this - how are you setting them to false? Are you saving pages via the API, rather than the admin backend?

@Mike Rockett - I'll admit I haven't investigated things properly at all, but I guess I don't understand why you can't use include=all and then have $page->viewable check to see if the page should be included in the sitemap or not. I don't really understand why this option needs to be configurable. I am not talking about having actual hidden or unpublished pages in the sitemap, just allowing for published/ not hidden children of unpublished/hidden pages to be included. That is what is currently missing. Does that make sense, or am I missing your point completely ?

Awesome work Robin - I can see this being my goto approach for quickly getting new site structures up and running!

One more thing - the new version of Admin Actions now automatically "installs" new actions for superusers without needing to first visit the module settings page. Of course you can still go there to adjust the authorized roles and checking "In menu" if you want. Thanks to Robin for pushing me to make this happen ?

Just a quick note to say that AdminActions now supports installable custom actions like @Robin S suggested above. He has posted his new Unordered List to Pages action over here: If you have any ideas for custom actions, please take a look at Robin's example, but the key things to note is that you need to include a .module file named like: There are two requirements: The classname must start with "AdminActions" It must have 'requires' => 'ProcessAdminActions' This is the entire contents needed in a file named AdminActionsMySharedAction.module class AdminActionsMySharedAction extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'Admin Actions My Shared Action', 'summary' => 'My new action does really cool stuff', 'version' => '0.1.0', 'author' => 'John Doe', 'href' => 'https://github.com/JohnDoe/AdminActionsMySharedAction', 'requires' => 'ProcessAdminActions' ); } } Once the module is installed on a site, AdminActions will detect it and allow users to configure and use it like any other action. A big thanks to Robin for his ideas and significant feedback on getting this implemented!

I know this is ancient, but: $session->errors('clear');

Try this out https://github.com/mr-fan/AutoImagePages/blob/master/AutoImagePages.module

It might be a module load order issue. Please try grabbing the latest dev version of PW and the latest Tracy and see if that helps. Tracy is now the first module loaded so that should hopefully solve things for you.

Yeah, you might be right about the XML sitemap idea. I think for some sites it could be ok to convert slugs to titles etc, but obviously some would be less useful. I might still have a play on a rainy day though ? I really love the idea of using the PW modules directory as a way to install these action pseudo modules. I'll make the adjustments to AdminActions to support this. Thanks for a great idea!

Nice! Glad to hear it's already proving useful ?

Another idea that is probably taking something that is currently simple and effective and overly complicating it - I have a habit of that ?, but what about: About | basic-page Contact | contact History | basic-page People | people John Smith | person Jane Doe | person Blog | blogs Events | events as a way of specifying the template to be assigned to each page? There could even be a selected default template so only when one is specified will that default be overridden. Maybe it is too much, but I just wanted to throw it out there ?

Maybe also of interest: https://processwire.com/blog/posts/processwire-3.0.107-core-updates/#what-pages-point-to-this-one

Hey @Robin S - what do you think about extending this to support pasting in an actual XML sitemap from an existing site? For this you'd obviously want a plain textarea field rather than an RTE. I think it would be relatively simple to parse the xml and the number of segments in each url to determine what pages are children of which pages, etc. What do you think: a) of the idea in general? and b) are you interested in doing it?

Turn on debug mode to see if you get a more meaningful error. You might be able to increase memory available to PHP to solve it.

Hey @tpr - sorry I just realized it was a bit rude of me to not acknowledge that change as your idea when I posted about it above. Sorry about that!

I know, it was your suggestion that prompted me to make the change ? Sometimes I am slow on coming around to a good idea ?

Given that no-one else has submitted any actions yet, I wonder whether you guys would prefer to maintain themselves in your own repos. Perhaps the best approach might be to add a list of 3rd party actions to the AdminActions Readme. Would you guys prefer that?

Another round ? 1) I have revamped the fullscreen / halfscreen buttons that are on many of the panels. They have been replaced by a single Maximize / Restore button which I think it much more useful. Hope you guys agree! 2) I have removed the "open in window" link from all panels - I never used this feature and it was painful to get the layout of some of the more complex panels to work in this mode. If others are finding they miss it, let me know and I'll see about reinstating it.