adrian

Hi everyone, Here's a quick little module that I hope you'll find useful. NB It requires PW 2.5.16 (or late 2.5.15 - this is the exact commit) It allows you can control display of the various Page Edit tabs by user permissions. So if you want to always hide the Settings tab for users of a particular role across all templates, this should come in handy. http://modules.processwire.com/modules/restrict-tab-view/ https://github.com/adrianbj/RestrictTabView You can approach this from two directions - hide from all users unless they have View permission, or show to all users unless they have Hide permission. It's up to you to create the permissions and assign them to roles. Let me know if you have any problems or suggestions for improvements. BTW - I am not sure how much use the Delete and View options really are in most situations, but they are there if you want them. PS Thanks to @LostKobrakai for the code in this post: https://processwire.com/talk/topic/8836-how-to-manage-delete-tab-for-user-groups/?p=85340.

Another possible solution on the slider front is ImageExtra http://www.kf-interactive.com/blog/adding-custom-fields-for-images-in-processwire/ It is very powerful and capable of much more than sliders, but will easily allow you to specify a link to internal page / external URL, an extra caption field, and anything else you might need.

I am not a formbuilder user, but I know that support for wireMail and hence the ability to use one of the SMTP modules you need the beta version of formbuilder. How do you know it's not using the SMTP module - is it just that the emails aren't being received? Have you used the test functionality in those modules to make sure they are working? Have you tried manually calling wireMail() in a script to test the sending and receiving?

So long as you have one of the SMTP modules installed all you need to do is replace instances of mail() with wireMail() and they will be sent via SMTP. So, look in your reset-pass template code and make that change.

Get is for returning a single page. You are looking to return a page array of more than one page, so try this: $entries = $pages->find("id=1049|1050");

If you don't have one of the smtp modules installed, then wireMail will still use php's mail function. I would try is to install one of the modules and see if it works. The other thing to try is run a php mail command in a php file outside of PW to make sure there are no issues with your server's mail function, but if you get SMTP running, then this isn't relevant, but might help to explain why things just stopped working. I would also try logging $emailTo, $subject, $message and $form to make sure they are still being populated as expected.

I see you are using mail() What version of PW are you running? If 2.5+ then you should be using WireMail() and I'd also recommend making use of one of the SMTP mail modules: http://modules.processwire.com/modules/wire-mail-smtp/ http://modules.processwire.com/modules/wire-mail-swift-mailer/ PHP's mail function is not awesome and you should use SMTP if possible it has a whole host of advantages, including reducing the likelihood that the email will be trapped as spam.

Good point - I often forget about that - that's a requirement for an "After" hook.

I honestly have no idea at this point. I am running a clean install (no other modules) of 2.5.23 (from yesterday's commits). You are having some interesting hook issues lately, which that code from your other post yesterday working when it seems it shouldn't have and now this Would you mind trying on a clean install?

Weird that my posted code doesn't work for you. How exactly are you using it? What's the rest of your module code? Is it extending WireData? You could also try it like this in your admin.php file. wire()->addHookBefore('InputfieldPage::render', function($event) { $inputfield = $event->object; $inputfield->addClass('myClassName'); $event->return = $inputfield; });

Just to confirm we are talking about the same thing - this screenshot shows what I am seeing: A page field with an Inputfield of type Select - in the console you can see the added class.

This works for me: public function init() { $this->addHookBefore('InputfieldPage::render', $this, 'hookAddCssClass'); } public function hookAddCssClass(HookEvent $event) { $inputfield = $event->object; $inputfield->addClass('myClassName'); $event->return = $inputfield; }

Just committed an update to this which means that it now works out of the box without needing to edit the search.php template file. You can still choose to add the output of the 404 page's body field, but this is not a requirement, and the functionality for loading search results on the 404 page is now completely automatic. It should be backwards compatible with your site, if you had it previously installed and were using the old required: if(isset($options['q'])) $input->get->q = $options['q']; line in your search.php, but please let me know if you have any problems.

soma - I have certainly used addHookProperty before, but it seems like an unnecessary use for it in this case, right? Don't you think it is cleaner and would have less overhead to simply get the property via the call to the field like in my example and your TextareaCounter? I assume your example for adding the property in this case is just an example of how it could be done, rather than a recommendation? I don't understand why @thetuningspoon's code is working as is either

You can also do: $field->addClass('myclass');

Understood, although I am not totally sure on the difference between what @thetuningspoon (the developer previously known as @everfreecreative) was doing and what I needed. I needed the following: $f->attr('checked', $this->fields->get($event->object->name)->allow_overwrite ? 'checked' : '' ); here: https://github.com/adrianbj/TableCsvImportExport/blob/master/TableCsvImportExport.module#L55 If I switch to simply $event->object->allow_overwrite, it doesn't work. What I have makes sense to me because it is the getting the allow_overwrite value for the field name that I am getting with $event->object->name, although I would have thought it would also work with just $event->object->allow_overwrite. What am I missing?

I am having trouble figuring out why this would happen. When I install the module the config setting are automatically populated to the modules DB table. If you have a minute would you mind uninstalling and reinstalling and see if the error shows up again, and also post the contents of the data field from the modules DB table. Thanks!

Nice - that does make more sense - I grabbed that line from an old module of mine - not sure why I thought that extended version was needed. EDIT: Actually, in my scenario, what I had is needed

What version of FieldtypePhone did you initially install? Was it before the update that I mention in post #25 above? Does saving the module's config settings fix the error?

What you are looking for is available in PW 2.5.22 https://processwire.com/blog/posts/processwire-core-and-profields-updates-2.5.22/#image-caption-support-in-the-rich-text-editor

Have you checked the value of $event->editable ? I am not sure in your situation, but you might try this. Of course my ternary approach is not relevant, but you might need to get the value of editable like this: $field->attr('checked', $this->fields->get($event->object->name)->editable ? 'checked' : '' );

That shouldn't be the case - like any Pagefield, you can define the selectable pages by template, selector, or even custom PHP. Is there a bug you have discovered in some situation?

I am loving Autocomplete and also Chosen Select (http://modules.processwire.com/modules/inputfield-chosen-select/) which uses http://harvesthq.github.io/chosen/ and is basically the same as Select2 Which one I use depends on the scenario. If you are using Autocomplete, take a look at integrating FieldtypeConcat for the Label field if you want fine control over what will appear in the entries - very cool!

What about: http://modules.processwire.com/modules/inputfield-page-autocomplete/

I am still seeing the "Base table or view not found" error. The field still works as expected because of course this fieldtype doesn't need a DB table, but the error should be dealt with. I'll post a Github issue.