Jump to content

Robin S

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Robin S

  1. The way that I find easiest is to get the Field object that is associated with the Inputfield via hasField and check its name, because the Inputfield object's name changes inside a Repeater but the Field object's name doesn't. So something like this: $wire->addHookAfter('InputfieldDatetime::processInput', function(HookEvent $event) { $inputfield = $event->object; $field = $inputfield->hasField; if(!$field || $field->name !== 'your_field_name') return; // ... });
  2. Yes. Some possible solutions, in order from easiest to hardest or least recommended: 1. Use FieldsetGroup instead of FieldsetPage if you have ProFields. 2. Use a normal Fieldset instead of FieldsetPage, and just bite the bullet if you have to spend some time setting up the fields in multiple templates. 3. Write some custom JS for the admin that adds/removes the HTML required attribute to the adjacent field depending on the state of the checkbox. 4. Use a hook to a processInput method to do custom validation for the required fields. So if your required field is a text field then you would hook InputfieldText::processInput. Here is an example for a text field named "text_1" that is required if a field named "checkbox_1" is checked inside the same Repeater item (or FieldsetPage item): $wire->addHookBefore('InputfieldText::processInput', function(HookEvent $event) { /* @var InputfieldText $inputfield */ $inputfield = $event->object; // Get field $field = $inputfield->hasField; // Only for field "text_1" if(!$field || $field->name !== 'text_1') return; // Get page $page = $inputfield->hasPage; // Only for fields in a Repeater page if(!$page instanceof RepeaterPage) return; // Repeater suffix $r_suffix = '_repeater' . $page->id; // Get checkbox field $wrapper = $inputfield->parent; $checkbox = $wrapper->getChildByName('checkbox_1' . $r_suffix); if(!$checkbox) return; // If checkbox is checked then field is required if($checkbox->value) { $inputfield->required = 1; } else { $inputfield->required = 0; } }); If you have multiple required fields you'll need to adjust this to suit. 5. I posted some suggested changes to the core to support required-if inside Repeaters here: https://github.com/processwire/processwire-requests/issues/262 But making custom changes to the core is not recommended because they will be lost when you upgrade.
  3. If you have the Version Control module installed it might be the issue linked to below, which has been fixed in an update to the module:
  4. Hey @adrian, What do you think about the idea of adding a link to the "Restore" page somewhere within the main interface? I know it's accessible via the flyout menu but it's easy (for me at least) to overlook or forget this and there have been a few times where I've started to worry that I don't have the ability to restore a backup when an action fails due to an error or I've navigated away from the success screen which includes the restore link. Then after a moment I remember where the link is and breathe a sigh of relief. 😅
  5. Loaded pages are cached: https://github.com/processwire/processwire/blob/master/wire/core/PagesLoaderCache.php Try calling $pages->uncacheAll() between renders of the same page.
  6. Inputfield Selector Select ID Uses the Page List Select inputfield for user-friendly input of page IDs into Inputfield Selector. Overview This module adds a feature to Inputfield Selector, which is most commonly seen in Lister (Find) and Lister Pro. When adding a filter row for "Parent", "Has parent/ancestor" or "ID" the user is expected to enter a page ID to match against. But this is not as user-friendly as it could be because the user may be able to identify the desired page by its title or location in the tree but not know its ID. This is particularly the case for site editors who may not even understand the concept of a page ID. So this module adds a thunderbolt icon to relevant rows in Inputfield Selector. When the icon is clicked a Page List Select inputfield opens in a modal window, allowing the user to visually select a page from the tree. When the modal is closed with "OK" the ID of the selected page is inserted into the filter row. Tip After a page selection has been made in the modal window the "OK" button will automatically receive focus so if you prefer you can close the modal by hitting the Enter key rather than mousing to the OK button. Installation Install the Inputfield Selector Select ID module. https://github.com/Toutouwai/InputfieldSelectorSelectID https://modules.processwire.com/modules/inputfield-selector-select-id/
  7. You need to create a database and a user for the database before you complete that part of the PW installation process. Then you will know the database name, user name, and password for the user. I'm not a XAMPP user but I'm pretty sure that it comes bundled with phpMyAdmin. So you open phpMyAdmin in your browser (probably at http://localhost/phpmyadmin) and then the quickest way is to create the user and database in one step at User accounts > Add user account After you have created the user/database then you will know the user name, database name (which will be the same as the user name) and the password so you can complete the PW installation process.
  8. Thanks for the report. PHP 7.3 apparently makes some changes to the regex engine and so an update to the bundled Simple HTML Dom Parser was needed. Done now in v0.1.6 of this module.
  9. Very helpful, thanks! I see the module gives a warning if a tag is created that has the same name as an existing template. Tags added to a template via the core way on the Advanced tab don't give this warning. Is there a catch to watch out for if a tag name is also a template name? Also, it's only a small thing but maybe this module only needs to autoload in the PW admin ("autoload" => "template=admin") rather than for the front-end also.
  10. Hi @bernhard, I gave this module a try to see if it might be a good way to get data for a CSV download (on the front-end). But I'm having trouble getting off the ground. I installed the module, put some demo code in my template file... $rf = new RockFinder2(); $rf->find("id>2, limit=5"); $rf->addColumns([ 'title', 'modified', ]); ...and I get this error: Call to a member function __invoke() on null The same code seems to execute in the Tracy Console in the back-end without an error. Is this module only for use in the PW admin? I had trouble understanding the GitHub readme - are those just notes to yourself? It wasn't clear to me how the SQL examples at the top of the readme relate to the module, and several of the code examples use "new RockFinder()" when this module class is RockFinder2. Update: fixed as per post below
  11. @adrian, there is already a config option for that:
  12. @Jens Martsch - dotnetic, @rjgamer, @teppo, @szabesz, @erikvanberkum, @dragan, @Lutz, @eydun, @psy, @horst, @cstevensjr, @tpr Just tagging in those who have reacted/responded to this topic in order to bring your attention to the notice above. Please don't uninstall but update to v0.2.1 or greater ASAP. Again, my apologies for the error. The intention was to have the module clean up after itself on uninstall but it's just too risky.
  13. IMPORTANT NOTICE TO ALL USERS OF THIS MODULE! I just discovered that the uninstall routine in v0.2.0 can inadvertently delete directories that it shouldn't depending on the module configuration. If you have v0.2.0 installed please DO NOT UNINSTALL but instead update the module to the recently released v0.2.1 as soon as possible. The module can be safely uninstalled from v0.2.1 or higher. To update the module, visit the module config page, expand the Module Information section and click "check for updates". I apologise for this error.
  14. This maybe? if(!isset($options['findAll'])) $options['findAll'] = true; https://processwire.com/api/ref/pages/find/ findAll (boolean): Find all pages with no exclusions, same as "include=all" option (default=false).
  15. Not really. Could you explain why you want to do this? Rather than modifying asmSelect.js and needing to make changes to the Connect Page Fields module I think it might be better to adapt to how PW handles the sorting of newly added pages by default and reverse the sort order of the Page Reference field when you get it via the API. Example:
  16. There's nothing in the core dependent selects feature that dictates how you organise your pages. A parent/child relationship to define categories and subcategories is just one that suits many scenarios, and if I understand right it's the way that was specified in the original question. The thing that determines how it works is this: So you can use "page.page_reference_field_name" in the selector string setting for the dependent field in any way that suits you. You could have all your subcategories under one parent and connect them with one or more categories using a "category" page reference field in the subcategory template. Then the selector string for the subcategory field could include "category=page.category" to limit the subcategories according to what is selected in the category field on the currently edited page. AsmSelect works with the core dependent selects, but it certainly would be nice if the range of compatible inputfield types could be expanded.
  17. I just tested this by creating a new template named "_test" and the stub file was created normally. I can't think of any reason why a template name starting with an underscore would behave differently with this module. It's common to create a file named "_main.php" that is auto-appended to template files if you are using a delayed output strategy, but in that case the file does not correspond to any PW template. Maybe that's the case for you. Are you sure you actually have a template named "_main" in Setup > Templates?
  18. It does, it's just not documented unfortunately. I linked to information about it in my earlier post above. Here is a demo... Page structure: Field settings for subcategory field: "page.category" will be replaced with the ID of the page selected in the Category inputfield in Page Edit, whenever that field changes. The "has_parent" part is just to avoid unwanted pages appearing in the Subcategory inputfield if the Category inputfield is changed to empty (no page selected). Result:
  19. Yeah, makes me wonder if it would have been better if the Pages::trashed method was called immediately before saving the trashed page rather than after. Maybe Ryan has a good reason for doing it that way. I still think it's better to hook after Pages::trashed if you want to know for sure which pages are trashed because when hooking Pages::trash there are still instances where the trashing can fail. For example, there might be another Pages::trash hook in a module that deliberately prevents trashing of particular pages. If you hook Pages::trashed you can parse the parent page ID (and some other info) from the name of the page in the trash: $pages->addHookAfter('trashed', function(HookEvent $event) { $page = $event->arguments(0); $pages = $event->object; /* @var PagesTrash $trasher */ $trasher = $pages->trasher(); $name_info = $trasher->parseTrashPageName($page->name); if(!empty($name_info['parent_id'])) { $parent = $pages($name_info['parent_id']); // ... } });
  20. An alternative is to use $files->render($filename). See the documentation about where the file is allowed to be. $emailBody = $files->render('/path/to/emailbody.inc');
  21. For anyone wanting to trace how it is that Pages::trash is called twice... Pages::trash (first call) calls PagesTrash::trash, and when the "save" argument is true (as it is when trashing via the admin) then Pages:save is called, which calls PagesEditor::save. And if that saved page is in the trash then Pages::trash is called (second call) with the "save" argument false. As to whether this second Pages::trash call is necessary and correct, I don't know. Best thing is to hook Pages::trashed as suggested above - this method only fires if the page is successfully trashed, which is probably what is wanted in most cases.
  22. You might want to also validate the date when the page is saved as @BitPoet suggests, but it is possible to limit the datepicker to only future dates with some custom admin JS. The relevant option is minDate. The core sets the datepicker options on focus, so to ensure the custom option doesn't get overwritten I've found that the most reliable way to apply it is by using a beforeShow function. For a Datetime field named "crondate": $(function() { $('#Inputfield_crondate').on('focus', function() { $(this).datepicker('option', 'beforeShow', function() { return { minDate: 0 }; }); }); }); Edit: just noticed you want a minimum time also. Try this: $(function() { $('#Inputfield_crondate').on('focus', function() { $(this).datepicker('option', 'beforeShow', function() { return { minDate: 0, minDateTime: new Date(new Date().getTime() + 30 * 60000) }; }); }); });
  23. You can hook Session::redirect and check the redirect URL and the current process. Not perfect, but as far as I can see the deletePage() method uses a redirect URL that is unique in ProcessPageEdit and is therefore identifiable as coming from that method. $wire->addHookBefore('Session::redirect', function(HookEvent $event) { $url = $event->arguments(0); if($this->process == 'ProcessPageEdit') { $admin_url = $event->wire('config')->urls->admin; if(strpos($url, $admin_url . 'page/?open=') === 0) { $event->arguments(0, '/your/custom/url/'); } } });
  24. @matjazp, that's strange. The link is to the Single version of ProMailer, which I can see in the store: Maybe that option is only visible to purchasers of ProDevTools, because when ProMailer launched Ryan said that he would provide a Single version of ProMailer to ProDevTools users on request (perhaps he sends a coupon code?) But it might instead be an access glitch so I suggest that anyone interested in purchasing the single version contact Ryan to ask about it.
  • Create New...