adrian

So this is what is being returned: user_name]]. This is blah [[central_name so it's removing the opening delimiters from the first tag. I have tried a few different delimiters with no luck so far. Any other thoughts?

Also wondering what you might think of an option to disable the dialog popup. For the needs of my current project I just want the dropdown for inserting the tags, but none of the tags have editable attributes so I think it would be preferable to not add the double-click handler on the inserted tags.

Hey @Robin S - I am seeing something weird where if I insert more than one code into a block of text. It all looks good until I save the page and then it reloads, and then all the text between the first and last code is highlighted in blue and connected so that's it no longer editable. Can you reproduce? Thanks!

@bernhard - is it worth adding a comment to this issue? https://github.com/processwire/processwire-issues/issues/480

You can use any type of field directly, but if you have more questions, I think your hunch to start a new thread is probably a good idea - this isn't really AdminActions specific anymore.

Replace: $recipients = $this->wire('pages')->find($options['pages'])->children(); with: $recipients = $this->wire('pages')->get($options['pages'])->children(); You can't get the children of an array of pages. find() returns an array, get() returns a single page. Also, since you have Tracy installed, please use bd() instead of print_r() and make your life a little easier

This will take care of changing the published date: $query = $database->prepare("UPDATE pages SET published=:pub_date WHERE id=:page_id"); $query->execute([ ':pub_date' => $pubDate, ':page_id' => $pageId ]);

I'm still not quit certain of the goal, but you can make a page not viewable at runtime by hooking into: Page::viewable - is that of any help?

Hi @B3ta - I'm afraid I don't really have time to look into this at the moment. I am extending this module for my needs and I rarely have multi-language websites so it's not high on my list. I am happy to accept PRs though so together we can build a better version of this module. Once we are all happy with the stability/functionality of the new version I'll try contacting Nico to see what we can do about getting it into the main repo. Hope you understand where I am coming from.

Hey @Tyssen - please install Tracy Debugger - there are several notices that will indicate to you what the problems are. The key one is: PHP Notice: Undefined index: email in .../AdminActions/EmailBatcherCoordinator.action.php:42 but there are several others. Once you go through those I am sure you'll be able to get it working

@Tyssen - using a selector doesn't select the parent's children, it selects whatever matches. If you choose a "parent" selector then that's what you'll get, but it's not automatically behavior to get the children of a single selected page. The email field is shown because that dropdown just shows all defined email fields on the site - it's not limiting to the ones on a specific template. Remember that with the page selector approach we could be sending to pages with different templates. Yes, it is meant as more of a site administrator tool, but you could easily make it simpler by cloning this and placing in /site/templates/AdminActions - just adjust this line: $recipients = $this->wire('pages')->find($options['pages']); to: $recipients = $this->wire('pages')->find($options['pages'])->children(); and you'll get the children of the selected page. You might also want to remove the email field from the options phase, and maybe also the Roles option. Basically pare it down to the bare minimum of options that your users will need - does that make sense? Remember that AdminActions is more about the interface it provides for building and presenting an admin interface than the actual core actions that come with it. It's a tool to make your development of custom admin actions really easy - go forward and conquer

Thanks @kongondo for moving here - I wouldn't have seen that post otherwise! @Tyssen - I just changed the email batcher to use pageListSelect and the email came through just fine. Not sure what might have gone wrong, but can you try again please? If it still doesn't work, then you should try to debug the executeAction() method in that action to see if the recipients are being populated correctly. I would ask though how you are using this because a single page with one email field will only have one recipient - I don't really understand your use case - can you explain in a little more detail how a single selected page can work for your needs?

Hey @rick - sorry you've hard a bad run with Tracy here. 1) I believe the issue with MarkupRSSLoad to be a bug in that module. Replace this line: https://github.com/ryancramerdesign/MarkupLoadRSS/blob/16e735b9ccc015eb36814689f862c007bff935a9/MarkupLoadRSS.module#L207 with: protected $items = array(); and this function: https://github.com/ryancramerdesign/MarkupLoadRSS/blob/16e735b9ccc015eb36814689f862c007bff935a9/MarkupLoadRSS.module#L428-L430 with: public function getIterator() { return new ArrayObject($this->items); } If that works and you find the module still works as expected, perhaps you could post an issue for Ryan on that module's github page. 2) As for the snippet name field in the Console panel - that is fixed in the latest version just committed. 3) I am getting a horizontal scrollbar in the Console panel here. Maybe there is some specific I am not doing to reproduce - can you provide more details? 4) I have seen the "Failed to init module: TracyDebugger - Tracy\Debugger::dispatch()" error a few times - it can happen when some error is output to the browser before Tracy is called. I am keeping my eye on this to see if it's something that can be fixed, but not sure it can. Let me know if you continue to see it on a regular basis and if something specific triggers it. 5) I can select text from the results pane, but maybe I just fixed that at the same time I fixed the snippet name focus issue. Let me know if you still have problems with this.

You could start debugging around this line: https://github.com/adrianbj/TableCsvImportExport/blob/a4e6ad668fd92f668546ba62cf726d29871b6d05/TableCsvImportExport.module#L424 Make sure that $rows contains the data. Then continue through the rest of importCsv() to see if you can figure out where it's failing. If you don't have any luck, is this site live somewhere I can take a look? Do you have debug mode on and Tracy installed?

If anyone is interested, I have a new fork of this module available here: https://github.com/adrianbj/MarkupSEO/commits/various-fixes-enhancements It's very much a work in progress, but it includes several bug fixes and lots of new features. Please read the commit log to learn about what's fixed and what's new. At the moment you should not upgrade an existing site (new fields won't be created) and probably don't use it on a live site just yet. It's not well tested at all yet, so use at your own peril I'd really appreciate any feedback on it.

Thanks for the field details. I just added the field to my system and then imported your example row and this is what I got:

@Tyssen - can you send me an export of your Table field so I can see the settings you have and can test that example row import?

Not quite sure how a save feature would work at the moment without a significant change to the interface. One possibility might be to store the last used options in a cookie and load those again if available. Would that suit your needs, or do you want something more permanent? If we can come up with an approach that works, I'd be happy to implement at some point though - any thoughts? The quickest option for you might be to simply clone the action into /site/templates/AdminActions and edit the defineOptions() method to hardcode the values you need. Or you could remove that method entirely and hardcode them into the executeAction() method so you wouldn't even get the option to change anything - this would be a good option if you have site editors using this - prevents them from breaking anything. Let me know if this works for your needs and if you need any help implementing.

Hey @Tyssen - what version of the Profields Table are you running? That error actually sounds more like something that might happen with the Export function than import. Can you please confirm that you are actually importing? I just tested import and export here and everything seems to be fine, so unless it's an issue with an old version of the Table field, I will need a little more info to figure things out for you.

Glad you sorted out a solution. Any chance you'd like to share in case someone else wants to achieve this as well? Thanks!

It is a page selector. See this example of selecting all pages with a certain parent. Note that you can click on "show" to see the matches to confirm they are what you expect. It uses the WireMail class which the Mailgun module extends so it should send through that.

The key thing about the AdminActions module is that you can easily write your own actions to do exactly what you need. Take one of the existing actions as a starting point, rename and save it to /site/template/AdminActions/ - easy to build and easy to access.

Not anymore! Can't find where it was announced, but all pw variables have been available for quite some time now.

Thanks for your help @lpa in fixing those issues. FYI for everyone else - all the changes that were included in that zip posted above are now in the master repo on github.