Admin Actions

[Robin S]

Hi Adrian,

If in an action I try and get a page using the short $pages($id) form of selector then I get a compile error:

My demo action:

protected function executeAction($options) {
    $p = $this->pages(1);
}

If I use get() then it works okay:

protected function executeAction($options) {
    $p = $this->pages->get(1);
}

Any ideas why the error is happening?

[adrian]

Hey @Robin S 

I think it's all because you are using $this

If you try it with just:

$p = pages(1)

it will be fine.

Take a look at: https://github.com/processwire/processwire/blob/341342dc5b1c58012ae7cb26cffe2c57cd915552/wire/core/FunctionsAPI.php#L50-L52

Note that the pages function is not a class method, but rather a global function.

All that said, you did highlight an issue with my __call() method which is why the error message is so confusing. I think I have a fix in place - I might PM it to you and see what you think before I commit.

[adrian]

Actually, I just decided to commit the changes - there were issues with calling an action via the API which this change fixes, so wanted to get it committed.

Let me know if you notice any issues.

[Robin S]

6 hours ago, adrian said:

I think it's all because you are using $this

6 hours ago, adrian said:

Note that the pages function is not a class method, but rather a global function.

Thanks Adrian, but I don't think that's it. I'm not using the Functions API in that line but rather the shorter selector syntax that was introduced here: https://processwire.com/blog/posts/processwires-roadmap-in-2015/

$this->pages is the API $pages object - what Ryan calls "a Wire-derived object (alternate syntax)" in the blog post linked to above. And that should work because ultimately a custom action for AdminActions extends Wire.

It all looks right when I do some debugging dumps:

protected function executeAction($options) {
    $is_wire = $this instanceof Wire;
    bd($is_wire, 'is_wire');
    bd($this->pages, 'this->pages');
    //$p = $this->pages(1);
}

But when I uncomment the last line with the latest module update I get a different error:

So somehow $this->pages($selector) is interpreted as being a (missing) method of Test. But I can use the same line in methods of other modules without a problem. Weird.

[adrian]

I was wondering about that short syntax vs the functions API - I think it's actually a bit confusing because:

$pages(1) is obviously the short syntax and pages(1) is obviously the functions API, but $this->pages(1) seems a like it could be interpreted as either. I don't really understand why it's not working either though because as you say, an AA action does extend Wire. 

I just checked this: 

bd($this->wire()->pages(1)); 

which does work without error. I don't know whether this is somehow a bug in my module, or an issue with PW?

Any thoughts?

[Robin S]

3 minutes ago, adrian said:

$pages(1) is obviously the short syntax and pages(1) is obviously the functions API, but $this->pages(1) seems a like it could be interpreted as either.

It does seem like PW could get confused with this, but I don't think that's what's happening in this case because the Functions API is only used when enabled in config.php and I don't have it enabled. I also noticed that the PhpStorm code completer thinks that everything is hunky dory - see how it marks the string within the parentheses as a selector:

My gut feeling is that it's something to do with the File Compiler. It would be interesting to test that by declaring the ProcessWire namespace in the module so the File Compiler isn't used (plus maybe the FileCompiler=0 line to be sure). But I've experimented with that a couple of times (I raised the idea of including the namespace by default here) and I can't get AdminActions to work when the namespace is declared. No doubt because I haven't studied the module closely enough - maybe you can see more easily how to get the module working with the namespace?

 

[adrian]

I have played with namespacing it and had no luck with this issue. I have to head out in a minute, but if you are interested, you can get the module working with namespace with these lines around line #134 in the main module file:

                $actionName = $this->wire('input')->get->action;
                $fullclass = __NAMESPACE__ . '\\' . $actionName;
                $this->action = new $fullclass;

Let me know if you get anywhere, otherwise I can investigate further later and if no luck we can ask Ryan.

[Robin S]

8 hours ago, adrian said:

I have played with namespacing it and had no luck with this issue.

Me neither - still getting the same error without the File Compiler involved.

I found that this works...

protected function executeAction($options) {
    $pages = $this->pages;
    $p = $pages(1);
}

So it's not a difficult thing to work around, just puzzling is all.

[mel47]

Hello!

Do you think it's easy to convert a Repeater -> PageTable ? I don't know enough to see if the existing action PageTable->repeater could be inverted.

Thanks!

[adrian]

2 hours ago, mel47 said:

Hello!

Do you think it's easy to convert a Repeater -> PageTable ? I don't know enough to see if the existing action PageTable->repeater could be inverted.

Thanks!

I'd say it will be a moderate amount of work to convert that PageTable>Repeater action to a Repeater>PageTable action. I don't have time to do this, but would be happy to accept a PR if you or someone else wants to do it.

[mel47]

20 hours ago, adrian said:

I'd say it will be a moderate amount of work to convert that PageTable>Repeater action to a Repeater>PageTable action. I don't have time to do this, but would be happy to accept a PR if you or someone else wants to do it.

ok thanks for answer. I will think if I should or not change my structure.

[Robin S]

An action that I made for my own convenience but that others might find useful too:

Unordered List to Pages

An action for the Admin Actions module for ProcessWire CMS/CMF. Creates a structure of new pages from an unordered list entered into a CKEditor field. The nesting of further unordered lists within the list will determine the nesting of the created pages.

This can be useful to quickly create a page structure; especially so if you are rebuilding an existing non-ProcessWire site that has a Sitemap page that you can copy and paste from. All the created pages get the same template - for any pages that should use a different template you can easily change this as you edit the page to add content, or use the Page Manipulator action for bulk template changes.

Usage

Install the action by copying the "UnorderedListToPages" folder to /site/templates/AdminActions/, and then visiting the Admin Actions config screen and enabling the "Unordered List to Pages" action for the roles who are allowed to use it.

Navigate to Admin Actions > Unordered List to Pages and fill out the config fields:

• Enter/paste an unordered list in the Source field.
• Select a parent page that the new pages will be created under.
• Select the template to use for the new pages.

Execute the action.

Screenshots

Action config:

Result:

 

https://github.com/Toutouwai/UnorderedListToPages

Update:

https://github.com/Toutouwai/AdminActionsUnorderedListToPages

This action module now has its own support topic: 

 

[adrian]

I freaking love this!

It is like the Add mode from BatchChildEditor, but on steroids!

I'd be keen to include this as a core action if you're ok with that and you'd like to submit a PR.

I can see using this for kickstarting many new sites.

If you do want to include, maybe move simple_html_dom.php into the libraries folder under actions, unless you feel like removing this need and coming up with a DOMDocument solution?

[adrian]

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?

[adrian]

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?

[bernhard]

4 hours ago, adrian said:

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.

I've just not created any yet ?

[adrian]

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 ?

[Robin S]

6 hours ago, adrian said:

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.

I think authors maintaining actions in their own repos is the way to go. I know from past experience that when tinkering around I often do several commits after I think I've done my "final commit" for a version as I spot little errors or think of new ideas. I wouldn't want to have to bother you or me with pull requests for these.

Having a list of third-party actions in the readme sounds like a good idea, but I have another idea too. I think it would be cool if we could leverage the power of the modules directory and ProcessWireUpgrade for actions, so users can see when updates are available and easily pull those updates in. So the idea is that each third-party action that extends ProcessAdminActions would have its own "pseudo-module" - a module file containing just the required getModuleInfo() method. So for my action above the module folder would look like this:

And ActionUnorderedListToPages.module would consist of this:

<?php namespace ProcessWire;

class ActionUnorderedListToPages extends WireData implements Module {

    public static function getModuleInfo() {
        return array(
            'title' => 'Unordered List to Pages',
            'description' => 'Creates a structure of new pages from an unordered list.',
            'version' => '0.1.0',
            'author' => 'Robin Sallis',
            'href' => 'https://github.com/Toutouwai/ActionUnorderedListToPages',
            'extends' => 'ProcessAdminActions'
        );
    }

}

ProcessAdminActions would look for third-party actions like this...

$third_party_actions = $this->wire('modules')->findByInfo('extends=ProcessAdminActions');

...and then get the action by looking for an ".action.php" file in the module directory.

ProcessAdminActions could hopefully grab the action title/description from getModuleInfo() rather than this needing to be duplicated inside the action file (but no big deal if that wont fly).

So this would require coding some extra features in ProcessAdminActions but I think being able to use the modules directory would be really cool. And the exact details of how all this would work is up for discussion of course - this is just me brainstorming here. What do you think?

 

4 hours ago, adrian said:

what do you think about extending this to support pasting in an actual XML sitemap from an existing site?

I might be wrong but this sounds like it wouldn't work very reliably. Sitemaps generally just have the URL to the resource and that seems like it would problematic to parse into the desired page structure in many cases:

• There is no page title in an XML sitemap so pages would have to use the slug name as page title, which may not be that close to the desired title - so potentially  requiring a lot of manual fixes later and not making the action much of a time-saver.
• Many sites don't have the tidy connection between URL and page structure that PW has - worst are ones like /index.php?id=1234&view=detail&foo=bar. I'm not sure what the action would be able to do with this.
• XML sitemaps often include entries for non-page resources such as PDF files.

If you think the XML sitemap idea can work I'm happy to be proved wrong. ? Maybe you want to have a play around with it?

[adrian]

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!

[adrian]

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!

[adrian]

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 ?

[adrian]

Just a quick not to mention that Admin Actions now supports two additional properties:

$executeButtonLabel
$icon

I am sure both are self-explanatory, especially when you see them in action.

I think both are useful additions for your custom actions.

 

 

[matjazp]

Hi Adrian, I just noticed a bit odd layout of core tab and actions list link:

[adrian]

Hi @matjazp - thanks for the report but I can't reproduce here. I just tested on Chrome, Safari, and Firefox. Any chance it's due to a cached version of the old css file?

[matjazp]

It's not a cache. I checked css file, no other site css file is loaded, just from wire and from the module itself. For the Core tab, it's .WireTabs top position in main-classic.css, and for the link it's div#links top position in ProcessAdminActions.css. I'm testing in Chrome. It's looking good in uikit and reno theme.