netcarver

@MindFull Nice example of how to use PW hooks to extend a class, thanks!

@Isag Glad you got this sorted out. I've unmarked your reply above and instead marked Fokke's answer as the "best answer" to your problem so others can more clearly see which post solved it.

Hi Tom, Would it make any sense to have an option that allows you to keep the Pages sub-menu open all the time? On my installs I often have spare vertical space in the left-hand menu and having that sub-menu always open would allow single-click access to the pages tree/find/recent links. Thanks for the lovely theme regardless!

Just wanted to feedback that the new module config options are working fine for me here after upgrading my development installation. I did have a little trouble at first as I started out by calling my options file XyzConfig.module rather than ZyxConfig.php. Once that was sorted out everything just worked. Thanks for listening to the community on this one Ryan!

Now added to the module repo and the opening post has been updated. Please report any issues with installation/use here. Thank you!

@gebeer Great to see you get a solution to this. Really glad you benchmarked the options too.

@Macrura Glad this worked out for you. Actually, the PW admin interface does what you are after already (if I understand you correctly.) If you edit a template and look at the AsmSelect list of fields in the template - each one of them is clickable and brings up a modal edit for that field's properties when used in that particular template. This would suggest that everything you need is already built right into AsmSelect so I'd suggest you have a look through the source code and see what's commented in there and how Ryan uses it.

Thanks for that guys. This solution is quite brittle and may break with future releases of PW as it relies on the current way that PW marks up the submission form with a class that contains the template name. If PW ever stops adding that markup class, this will break. Also take note of that space after the end of the template name in the search string - which is needed if you have templates with matching substrings: like "patient" and "patients" where both would match if you tried to apply it only to "patient" and don't have the space at the end. I'd much rather be able to access the template name directly somehow from the hook method (preferably as the form is built rather than post-rendered) but I just couldn't find the right way to access it.

Ok, as promised, here's my solution. public function init() { wire()->addHookAfter("ProcessPageEdit::execute", $this, "tryThis"); } public function tryThis(HookEvent $event) { $render = $event->return; $template_name = "xyz"; // Change this to match the exact template name of pages you want to apply tab-renaming to. if (false !== strpos($render, "template_{$template_name} ")) { $render = str_replace("Content</a>", "New Title</a>", $render); $event->return = $render; } } I'm not totally satisfied with it as it makes no allowance for possible changes to the default string or the internationalisation of it - but it is still relatively easy in PW. I've raised an issue about this over on the home repo as I think PW should be able to solve this more elegantly. It will do for this current site as I only expect to use the English default string for the content tab.

@Philipp Thanks for posting this tutorial! I'm currently getting a 404 for the image from abload.de.

@Martijn, I've unmarked this as solved as it's not quite the whole story. If I put a breakpoint in my hook routine I can examine the $event object and I can see all the information I need to be able to make a rename decision as the $event object's page's template has a title that I want to compare against - but it doesn't seem possible for me to access that information via the API using $event->object->page->template->title which always gives a blank, despite me being able to inspect the data in the debugger. I suspect that some of these fields are protected or private members of the $event->object. If I do find a full solution I'll post it.

@jordanlev Sure, but be warned, my code currently does it across all pages you edit as I've not added anything to restrict it to just the template I'm after. In fact, I'm now worried that I won't be able to do it on a per-template basis this way. But the day is late and I'll worry about that tomorrow. In the meantime, here it is... public function init() { wire()->addHookAfter("ProcessPageEdit::execute", $this, "tryThis"); } public function tryThis(HookEvent $event) { $render = $event->return; $event->return = str_replace("Content</a>", "New Title</a>", $render); } That's part of a little auto-loaded module. Oh, yeah, it also currently updates any links that end with the word "Content" but that's fixable with a more complex match.

From the source code it looks like the title of the first tab is set by adding the title attribute to the form in buildFormContent. I can successfully overwrite that attribute with this code... wire()->addHookAfter("ProcessPageEdit::buildFormContent", $this, "tryThis"); public function tryThis(HookEvent $event) { $form = $event->return; $new_title = $this->_("Personal Info"); $title = $form->attr('title'); $this->message("Updating form title [$title -> $new_title]"); $form->attr('title', $new_title); } And I've verified (by single stepping the code) that the attribute gets overwritten and returned and even makes it through several stages of hook return. Despite this, as Martijn mentioned, it seems to be protected as it still gets rendered as "Content" even with the change. I have no idea why at the moment. Update 1: Ok, it is getting saved in an instance variable ($this->tabs[$id] = $title) and it is that variable that's being used to render the tab via WireTabs. Will need to look at hooking execute() and doing a replace on the rendered output. Not a pretty way to do it - but at least I know it should work. Update 2: Just to confirm, I have succeeded in doing this using an after hook on ProcessPageEdit::execute - but it's not a particularly elegant solution.

@mr-fan Thanks for the reply. I thought about that already but it does it for all labels. I only want to do it for the labels of one particular template's children. I'm actually getting a little closer to this now as Martijn's answer has pointed me in the right direction; which seems to be to hook buildFormContent().

@Martijn Thanks for the snippet. Here's the result... ...not quite what I'm after - but interesting. Enjoy your time with your little one.

Can anyone point me in the right direction to rename the "content" tab of pages in the admin page editor? I wan't to rename it when editing pages of one of my templates. It wouldn't surprise me if I had to hook a render method somewhere. I've googled for this but not found anything particularly useful. Thanks in advance!

I'll add a pull request to the PW repo for this feature. Edited to add: Done.

Hi Macrura, Here's a version for select multiple... <?php class InputfieldSelectMultipleExtended extends InputfieldSelectMultiple { public static function getModuleInfo() { return array( 'title' => __('Select Multiple Extended', __FILE__), 'version' => 1, 'summary' => __('Multiple selection with extended attributes. An enhancement to select multiple', __FILE__), 'permanent' => false, ); } /** * Adds an option with extended attributes */ public function addOption($value, $label = null, array $attributes = null) { if ( is_null($value) || (is_string($value) && !strlen($value)) ) { return $this; } if (null === $attributes) { $attributes = array(); } $extra_atts = $this->extendAttributes($value, $label); $attributes = array_merge($attributes, $extra_atts); return parent::addOption($value, $label, $attributes); } /** * Hook this and return an array with whatever extended attributes you need. * */ public function ___extendAttributes($id, $value) { $atts = array(); /** * Either hook this method to do what you want or implement things directly if this * is the only use of this Inputfield. * For your example you'd grab the fields you want from your page and put into data * attributes... */ $page = wire()->pages->get($id); $atts['data-description'] = $page->description; return $atts; } } Here's how to use it... Save this module as InputfieldSelectMultipleExtended.module in your site/modules directory of a development install of PW. Install it in PW. Edit InputfieldPage's module configuration and add InputfieldSelectMultipleExtended to the inputfields that can represent pages. Create a new Page field and select InputfieldSelectMultipleExtended on the input tab and setup the parent and other fields as required. Add the new page reference field to a template. Add some pages that use this template. Check the HTML of any of the pages using the template and you should see the options for the select have data-description attribute for every page referenced that has a non-empty description field. Hope that helps!

Hi Macrura, I've just done something similar to this for my current project. I needed to add data-start-time attributes to every option in a select dropdown so I decided to extend the InputfieldSelectMultiple class to provide a replacement addOption() implementation that added the required data attribute as part of the internal attributes array for each option. Here's what I did... public function addOption($value, $label = null, array $attributes = null) { if ( is_null($value) || (is_string($value) && !strlen($value)) ) { return $this; } if (null === $attributes) { $attributes = array(); } $extra_atts = $this->extendAttributes($value, $label); $attributes = array_merge($attributes, $extra_atts); return parent::addOption($value, $label, $attributes); } public function ___extendAttributes($id, $value) { $atts = array(); /** * Either hook this method to do what you want or implement things directly if this * is the only use of this Inputfield. * For your example you'd grab the fields you want from your page and put into data * attributes... */ //$page = wire()->pages->get($id); //$atts['data-description'] = $page->description; return $atts; } I've updated the example above to output data-description. Hope that helps you with some ideas!

@gebeer, Good to see some benchmark results for those; thanks for posting them. So, it sounds like option 1 might be the way to go for creation/deletion and I'm now curious to know what happens when searching. There are timer helpers that you can use when in debug mode in PW's debug class. Hope that helps!

So it is you, Joe. Good to see you again and hope you grow to enjoy using PW. Thanks for the pointer to the module notes; I've updated them now.

@joebaich Welcome - are you visiting us from the Textpattern camp by any chance? I seem to remember a joebaich from over there, many moons ago. Regardless of the answer to that quesion though, I'm sure you'll find the PW community a nice and welcoming place. To get back to your post now; I can't see why this wouldn't work with PW 2.5, have you noticed an issue with it?

Thanks for posting the link to recurr - looks like another interesting library. I should have posted the link to the development branch of the when library. Most of the documentation is done by example in the tests subfolder. Minutely recurrence is handled, check out the second example here. Let me know which library works out better for you as I'll be needing one of these myself really soon.

@gebeer I'd steer towards the page field option above or go with a custom DB table handled by a module. Anyway, I'm not sure you have to be constrained to a full-text search selector. Is there some constraint on this project that's forcing you to use fulltext fields for some reason? I think you can arrange to do things with a normal "equals" selector (which is probably a lot faster) though it might require some more setup. It would be good to benchmark the solution you are using with the ad_publish field as a text field and doing the fulltext-search in the selector and then comparing it to something like this (untested)... Create a timestamp field called "publish_at" and a page field called "advert_id" which is setup to a single value or null in the config page. Create a template called publishing_schedule and add both the "publish_at" and "advert_id" fields to it. Create a parent page called "Publishing Schedule" in your page tree somewhere (it can use the basic-page template) and set up its children to use the publishing_schedule template. Setup a page save hook so that when you save an advert (where you specify your start date + time, end date + time, frequency etc) you then calculate your publishing timestamps using existing code or the when library and, for each timestamp, you'd create a new page under the "Publishing Schedule" parent page using the "publishing_shedule" template. Set the publish_at and advert_id fields as required and save the page. You should now be able to find all ads published on a particular timestamp with a simple query like... $published_at = $pages->find("template=publishing_schedule, published_at=$timestamp"); foreach ($published_at as $published) { $advert = $published->advert_id; /** * Access your advert fields as needed. */ echo $advert->title; // etc } You could then benchmark which one worked better for you.

@kongondo, I like the thinking but you never know when an extra X will get added to a size; particularly medium. In other words, I suspect the table would need to accept changes in either dimension. How about simply concatenating the x and y variable to give a key that can then have a simple value stored against it? So you'd end up with a table that had an indexed product page id, an indexed "key" and an "amount" column. The function to make the key would just do something like... function makeKey($size, $variation) { $size = wire()->sanitizer->name($size); $variation = wire()->sanitizer->name($variation); $key = "$size/$variation"; return $key; }