adrian

Have you tried like this: $options = "1=option1|Option 1\n2=option2|Option 2\n3=option3|Option 3"; BTW - I haven't tested this, just going on what is exported when exporting the field.

You don't sound thrilled Do you have any other ideas / preferences? I could add support for pulling in a template stored in the file system, but I feel like that might be overkill for a simple email like this - I can't see it requiring very much structure/styling for a simple account registration email.

Hi @Timothy de Vos - I could simply support HTML in that email body field and have the email sent as HTML along with a plain text version (automatically generated from the HTML version). I think that would be the easiest approach. Would that suit your needs?

Thanks @Martijn Geerts - glad you're finding it useful - I appreciate the feedback! Hi @Ivan Gretsky - just to clarify - are you talking about simply separating the "core" actions in the module's "action" folder from those "site specific" ones in the /site/templates/AdminActions/ folder? I think tabs sounds like a good approach - I'll take a look at doing that. Also something else to consider is the tables filter feature of @tpr's awesome AOS module - that will make finding actions nicer once there are lots more, although to be honest sometimes I just like good old CTRL/CMD + F Just an FYI - if you don't want certain/any core actions available, you can remove the superuser role from those actions and they won't clog up your list of actions.

Hi @Harmen - how do you envision all the languages being formatted in the CSV - using a "|" or some other separator, or do you have some other approach in mind? Currently BCE only supports direct children of a page. I am not sure how to come up with a standardized approach for handling sub-pages/grandchildren in CSV format. Perhaps if you could explain (or provide an example) of how you'd like the CSV to look I could implement it, or you could provide a PR

My apologies - you are right I am actually in two minds about supporting this via the API - I wonder if perhaps it should be controlled by an additional module config setting so devs can decide if they want this or not. I feel like this is something you can do in the API yourself when you change the title? But maybe it would be easier if this module handled any required logic so you didn't have to think about?

Actually, it should work for saves via the API as well. At least it used too This save hook: https://github.com/adrianbj/PageRenameOptions/blob/12d18066b89a37fd9a7e05204599b09388bf6f82/PageRenameOptions.module#L117 should take care of it. Let me do a little investigating here.

Hi everyone, I have committed a new version that takes care of @Ivan Gretsky's issues with guest access for calling actions via the API. The new version also includes the ability to add actions to the Setup > Admin Actions submenu which could be really handy for quick access to key actions that you use regularly. At the moment you could add them all if you want, but perhaps in the future we'll have too many to make this usable, which is why I have made these configurable. See the new "In Menu" column:

You can read more about that here: https://processwire.com/api/selectors/#or-groups

In a rush, so no help on the selector, but here is the info on has_parent now supporting multiple values: https://processwire.com/blog/posts/processwire-core-and-profields-updates-2.5.22/#has_parent-selectors-now-support-multi-value

$child->Image->url;

Yes, that's true that you can't use $page inside a function, but the other thing here is that you already have wire('page') - there is no need to get the page from pages again, so this should be fine: $this->set('successMessage', '<h2 class="enviado-ok">' . wire('page')->mensaje_form_enviado .'</h2>');

Hi @Ivan Gretsky - ok, a new version has been committed that adds a new module config setting for determining whether database backups will be automatic, optional, or disabled. 1) Automatic - database backup will happen without user intervention. 2) Optional - adds a new checkbox at the bottom of every action's "options" form before the user clicks "Execute Action". 3) Disabled - this means no database backup will occur. If you do want to do a backup when calling an action via the API, simply add a new item to the options array: 'dbBackup' => true I am still working on figuring out the best approach for guest access. The biggest problem I see is that adding the "admin-actions" permission to the guest role means that any logged in user can now see the Setup > Admin Actions menu, even though they don't have permission to view or execute any of the actions. I have been playing around with adding a new helper module to handle the API calls, rather than calling the main ProcessAdminActions module directly, but there are a couple of inheritance issues I am not thrilled about, so looking into other options. Will hopefully have a good solution soon. Please let me know if the backup side of things handles your needs on that front.

Ah yes - I hadn't got that far yet - just noticed the weird conditional. The easiest option might be to just return the entire link/title as a string, rather than relying on the array key/value to create the link? Try this: function pedigreeParents($value) { if ($value->id) return '<a href="'.$value->url.'">'.$value->title.'</a>'; else return 'No Parent Defined'; } Note that I have changed the conditional. I would assume that your father and mother page fields are set for "single page", or at least they should be, so the approach for checking if there is an ID works well. You could even do something like this if you want separate "No Mother Defined" and "No Father Defined" entries where appropriate. function pedigreeParents($value, $parent) { if ($value->id) return '<a href="'.$value->$parent->url.'">'.$value->$parent->title.'</a>'; else return 'No '.$parent.' Defined'; } and call it like this: pedigreeParents($page->father, 'Father'); and: pedigreeParents($page->mother, 'Mother');

It's hard to tell what problem you are having with the table. Is it that in some cases "No Parent Defined" is being replaced with "Our Corgis"? I don't really understand this code: function pedigreeParentsLink($value) { if (count($value->title) > 0) return $value->url; else return $value->url; } Isn't this where you need to deal with no parent defined? Your conditional is returning the same result whether there is a title or not.

Thanks @szabesz - I really appreciate everyone's positive feedback and support for this module - glad it's been useful for everyone! Good luck with your new project.

A few more updates to mention. 1) Tracy now correctly reports warnings/notices coming from PW's file/image AJAX uploads For those following the thread on CustomUploadNames and on Github, not only did Ryan make some changes in the PW core to make this work, but David Grudl over at Nette also added a workaround that now allows Tracy to report errors from vanilla JS ajax calls, even if they don't call xhr.getAllResponseHeaders(); which should help with debugging your own vanilla js ajax calls as well. 2) Easy toggle for Strict Mode Not sure how many of you have played with the Strict Mode config setting. It turns notices and warnings into errors and shows a full expandable stack trace. For example, here is the above notice in Strict Mode. Clicking on the "source" and "arguments" on the entries further down the call stack can be very helpful! This is great, especially for AJAX notices/warnings which are often harder to dig into. The catch has always been that Strict Mode will halt your scripts for these notices/warnings, which can often be painful when you are early into something complex and just want to get it working before dealing with these. Now on the Panel Selector panel the new toggle button makes it easy to turn on Strict Mode when needed (note this is only available if Strict Mode is off in the module config settings): 3) Time and memory of Console Panel code I recently added time and memory of the code run in the console panel. Note the 11.59ms and 0.07MB at the bottom of the output. This could be very handy if you want to test the performance of different selectors or loops. Hope you guys find these new additions useful!

Ryan just added those xhr.getAllResponseHeaders() calls to the dev branch! Keep in mind that Tracy will still remove warning/notices from the AJAX response, so uploads won't be stalled but now you'll at least be notified about the problem.

Where do you define $pic ? Is "pic" the name of your images field? In this case you would want $match->pic->url Also, check the max files setting of that field. If it's not "1", then it will return an array of images and you'll need: $match->pic->first()->url

Or you could have new child pages automatically added to the page table field: Be sure to read the comment two posts lower which mentions a bug and a fix.

Hi @ukyo and @horst - just another follow up on the suppression of notices/warnings by Tracy. I have discovered that it's because PW image and file uploads use vanilla JS calls that don't use xhr.getAllResponseHeaders(); This prevents Tracy from being able to update its AJAX debug bar with any notices/warnings returned from the AJAX request. I have just posted an issue (https://github.com/processwire/processwire-issues/issues/137) in the hopes that Ryan will consider adding xhr.getAllResponseHeaders(); to both of these. I have tested here and it works great and I actually think it will be of great benefit to beginners debugging image/file upload problems who aren't used to looking for AJAX errors in the Network panel of the browser dev console because now any notices/errors will appear very obviously on the Tracy AJAX debug bar. If you're willing, I'd love a show of support for this change on that Github issue. Thanks!

Any chance it's a third party module? Maybe you could rename the modules db table and the site/modules directory, and clean up the filecompiler cache directory. Maybe also the caches db table?

Have you tried to debug the contents of $page that is passed to the loaded() method in the line above?

Looks like you are not alone:

Leave that line the way you had it and just delete this line: $wire = $this->wire();