Robin S

I can confirm the behaviour in PW3. I think it's a bug - will you raise a GitHub issue for this?

I don't experience this problem with this module - for me only email addresses are obfuscated, not twitter handles. name@testing.com <- this would be obfuscated @testing <- this is untouched

Not a proper answer to your issue, but have you had a look at MarkupSimpleNavigation? It will take care of your current/parent classes, plus a lot more (if you want it).

$my_options_field->inputfieldClass = 'InputfieldCheckboxes';

Besides the hidden admin page approach, you could use a module config page to return the AJAX data. You would need to have an additional module because an inputfield module doesn't autoload. So your module folder consists of: TestAjax.module InputfieldTestAjax.module InputfieldTestAjax.js TestAjax.module <?php class TestAjax extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'TestAjax', 'version' => '1', 'summary' => 'Installs and is used by InputfieldTestAjax.', 'installs' => 'InputfieldTestAjax', 'autoload' => "template=admin", ); } public function init() { $this->config->js('admin_url', $this->config->urls->admin); $this->config->js('module_name', $this->className()); $this->addHookBefore('ProcessModule::executeEdit', $this, 'ajaxResponse'); } public function ajaxResponse($event) { if(!$this->config->ajax || $this->input->get->name !== $this->className()) return; $event->replace = true; $data = '{}'; if($this->input->post->test_ajax) { $test_ajax = $this->input->post->test_ajax; // populate $data } $event->return = $data; } } InputfieldTestAjax.js $(function() { var test_data = { test_ajax: 'my string' }; var url = config.admin_url + 'module/edit?name=' + config.module_name; $.ajax({ url: url, data: test_data, type: 'post', success: function(data) { alert(data); }, error: function(jqXHR, textStatus, errorThrown) { console.log(textStatus, errorThrown); } }); }); InputfieldTestAjax.module ...whatever you need for the inputfield.

I get the same issue as the OP when doing a new PW install with a profile saved by the ProcessExportProfile module - often I'll see module errors or warnings until I refresh the module cache. Doesn't really bother me as it just becomes part of my routine when doing a new installation, but it would be nice to cut out this step.

@LMD, could you explain the situations when the template cache is not automatically clearing on your dev site when you would want it to? I'm just curious because I have never really used the template cache options and have always used ProCache instead. It would be good to know what things to be aware of if using template cache. Thinking about situations when one would want the template cache to clear automatically... 1. Page save: cache can be automatically cleared for the saved page and any other pages using options in the template settings. 2. Changing page sort order: cache is not automatically cleared (according to this thread). 3. GET or POST variables present: cache can be automatically cleared using options in the template settings. 4. Adding/removing/changing fields in the template: not sure, is the cache cleared automatically? 5. Making changes to a template file: not sure, is the cache cleared automatically? Any other situations when the cache should clear?

Have you already translated the string then? Because the core Page inputfield renders "Create New" by default, not "New": https://github.com/processwire/processwire/blob/master/wire/modules/Inputfield/InputfieldPage/InputfieldPage.module#L621

Looks like Soma's code and the code in this thread's first post (which I guess is based on Soma's example) aren't using $input correctly. I think... $this->input->InputfieldMyAjaxBomb ...should be... $this->input->get('InputfieldMyAjaxBomb'); ...or... $this->input->post('InputfieldMyAjaxBomb'); ...depending on if you are using GET or POST.

You could use a replace hook on renderAddable(). But, based on your screenshot above... You are not using a core Page inputfield. Looks like the InputfieldChosenSelect module, which has it's own method for adding new pages and does not render the core "Create New" link. And I believe your "New" button is not core either, but actually rendered by the AdminPageFieldEditLinks module. These details do matter.

Repeaters don't create multiple templates (unless it's a Repeater Matrix field). I think you might be referring to the "Ready-To-Edit New Repeater Items" setting in PW <2.8. The setting is on the details tab: If you upgrade to PW 3 or 2.8 this isn't an issue as new repeater items load one at a time via AJAX.

Really stoked about the new module! For the OP's issue, the below won't work as expected across the year boundary. Like, if this runs on 28th of December. Hence the need for switching between two find queries...

There's no such setting is there? I think you mean "Blank and 0 have different meanings", which doesn't promise anything about blank and null being treated differently. I guess PW treats these as equivalent, which explains issue 2 also.

Hi Daniel, welcome to the forums You could use the approach described here:

Also. these gists by @Soma are good demonstrations: https://gist.github.com/somatonic/5011926 https://gist.github.com/somatonic/5236008 https://gist.github.com/somatonic/5233338

I think this should work: $today = strtotime('today'); $date_end = strtotime('+7 days', $today); $pages->find("template=user, birthdate>=$today, birthdate<$date_end"); Ha, of course that won't work because you have the birth date, which could be from any year. New idea... I think in order to find birthdays in a $pages->find() selector you'll need to store the birthdate day of the year in a separate field in your user template. You could create an integer field "day_of_year" and then populate it from the birthdate field with a save hook: $this->pages->addHookBefore('saveReady', function($event) { $page = $event->arguments('page'); if($page->template != 'user') return; if($page->birthdate) { $page->day_of_year = date('z', $page->birthdate); } }); And to find birthdays: $day = date('z'); $day_end = date('z', strtotime('+7 days')); if($day_end < 7) { $results = $pages->find("template=user, (day_of_year>=$day), (day_of_year<$day_end)"); } else { $results = $pages->find("template=user, day_of_year>=$day, day_of_year<$day_end"); }

I tend to agree, and use include() over wireRenderFile() myself. I suppose one reason some prefer wireRenderFile() is the scope of variables is limited so you don't run the risk of overwriting a variable of the same name in your template file. As for using a view file separate to the the template file, it depends how strictly necessary you consider "separation of concerns" to be. Definitely good if you are part of a team and want to hand the view file on to a front-end person who shouldn't be dealing with business logic. Or if you have a lot of logic that you don't like cluttering up the view. As a solo designer-developer, I like to have my business logic in my template so I can see what is going into variables, but I guess a lot of people would frown on that.

Never say die, where there's a will, there's a way! public function renderPageTable(HookEvent $event){ $page_id = $this->input->get('id'); $page = $this->pages->get($page_id); // use $page... }

Can the "HP" field value be less than zero? I'm not sure what this field holds in your case, but perhaps you just want to stop when the field is empty? $streak = $lastEvent->nextUntil("task.HP=''")->count(); Incidentally, I don't think there's anything wrong with a simple foreach() over 10 page objects or less - no cause for concern over performance there. Several ways you can skin the cat, but one alternative is to use "break" to end the loop when your condition is not met. foreach($lastEvents as $e) { if($e->task->HP >= 0) { $streak++; } else { break; } }

A good way would be to use a checkbox in conjunction with the normal form submit button. Then look for my_checkbox=1 in the post data. Have a look at how the PageimageRemoveVariations module by @horst does it.

Welcome to the forums @mciccone I haven't purchased ProDrafts so I can't give a definitive answer on whether the module has a schedule feature, but it wouldn't be too difficult to code your own solution using the API method for publishing draft pages: $page->publishDraft(); You would take a similar approach to the Schedule Pages module. That is, add a "publish_from" date field to your page template, and use a Lazy Cron hook to find unpublished draft pages with a publish_from date < now and publish them.

Hmmm, works properly for me. You should get a warning message after changing the sort order by drag.

@choppingblock, this does seem to be a bug. I opened a GitHub issue for it. You can successfully sort a page array according to the sort order of an Options field... $my_page_array->sort("my_options_field.sort"); ...but that perhaps won't help you as I see you want to apply a limit/pagination and maybe don't want to load all the pages into memory. Maybe you could switch from an Options field to a Page field?

If you don't want the "optional" HTML tags removed there is a setting in ProCache to disable this behaviour.