Robin S

Hi @adrian, Apologies if this has already been asked and answered before. When using the "Editor Protocol Handler" feature, the linked error is often to a file in the file compiler cache, e.g. "...\assets\cache\FileCompiler\site\templates\home.php". But to correct the error you actually want to open "\site\templates\home.php" for editing. Would it be possible to rewrite links to compiled files so they point at the original uncompiled file instead?

Hi @horst - this module is great and I use it regularly. Only problem is that it causes a deprecated constructor notice in PHP7 (class "filo" has a method "filo" rather than "__construct"). Would you mind updating it? And maybe submit it to the modules directory too? I could update it for my own use but it would be cool to have an "official" version.

It's not so much that I'm intentionally using caching in a development environment. It's that I have many small (and small-budgeted) sites where it isn't economic, or really necessary, to maintain and sync independent dev/staging/production environments. So it's not unusual for me to make small template changes directly on the live site, where the issue is that changed CSS and JS files may be loaded before the corresponding HTML changes flush through the cache. Having said the above, I do take the point that it's probably not a situation that justifies any changes to Template Cache or ProCache. It might be possible to avoid a recursive modified time check by detecting changes with an inotify script (thanks to @netcarver for the reminder), and I'm going to explore that out of curiosity, but the simplest and best solution is just to remember to manually clear the cache after making template changes. This by itself does not clear the template cache - you would still need to clear the cache for any pages using templates you have modified. Otherwise when you set... $config->disableTemplateCache = false; ...after making template changes PW will serve the old cached pages that exist from before template cache was disabled.

@thetuningspoon, Ryan has suggested that an alternative is to hook InputfieldWrapper::renderInputfield See his GitHub comment.

When you see all the new features listed together and consider the short amount of time this has happened in it's really impressive. Thank you Ryan, and thanks also to the other contributors to the PW core.

@Fantomas, welcome to the PW forums! I found your post difficult to follow because of the page names you have used in your example. It would be easier to grasp what you're trying to do if you use demo names that can have some meaningful relation, e.g. "Cars", "Model", "Colour", etc. The thing you're asking about is not the basic inputfield dependency feature that this thread introduces, but is actually a feature of Page inputfields. The trouble is that the feature is not formally documented anywhere (grumble, grumble) - it just pops up in forum discussion - so it's difficult to know exactly what is and isn't possible in terms of this feature. As I understand it, the feature only works in the "Custom selector to find selectable pages" (not in "Custom PHP code to find selectable pages") and the reference can only be to another Page field that is in the page being edited. If you're wanting to reference the value of a Page field on a different page then you can do this with FieldtypeReference (and maybe RuntimeMarkup also, not sure).

Thanks @LMD - I guess what I was driving at is that ideally a cache will clear automatically whenever it becomes out-of-step with the state of the live site, without any manual intervention necessary. If we identify situations where the cache is not automatically cleared when it's desirable that it does clear (changing a template or a template file, maybe other situations too) then maybe new features to deal with those situations could be added to Template Cache / ProCache.

Not sure I understand. Do you mean when you add a new page, in the first step where you select a template for the page you are seeing the templates of repeaters included in the list? That shouldn't be happening because the repeater template (which is only visible if you choose to show system templates in Setup > Templates) should be set to "Can this template be used for new pages? No". Edit: I think I get what you're talking about - you can select a repeater template in a page's "Settings" tab. The answer to that is "just don't" . A repeater does create a (system) template to use for its repeater pages, but not multiple templates which is what I thought you were saying in your first post.

Just to confirm - you can use CKEditor in normal "Regular Editor" mode, and it's only if you change to "Inline Editor" mode that a problem occurs? I just tried CKEditor in inline mode in a fresh install of PW 3.0.35 and it worked normally so I think it must be something specific to your environment rather than a PW bug.

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"); }