Robin S

A hook for anyone still wanting a solution for this: // Prevent the trashing of pages referenced by other pages $pages->addHookBefore('trash', function(HookEvent $event) { $page = $event->arguments(0); // Find non-system Page Reference fields $pr_fields = $this->fields->find("type=FieldtypePage, flags=0"); // Implode for selector string $pr_fields_str = $pr_fields->implode('|', 'name'); // Find any referencing pages $referenced_on = $this->pages->find("$pr_fields_str=$page->id, include=all"); if($referenced_on->count) { // Replace the trash method $event->replace = true; // Link markup for referencing pages $referenced_on_str = $referenced_on->implode(', ', "<a href='{editUrl}'>{name}</a>"); $plural = $referenced_on->count > 1 ? 's' : ''; // Trigger an error message (using $session in case a superuser is trashing from ProcessPageList) $this->session->error("You cannot trash page $page->name because it is referenced in a Page Reference field on page$plural $referenced_on_str.", Notice::allowMarkup); // Don't allow the trashing of this page $event->return = false; } }); When attempting to trash a referenced page from ProcessPageList the page will at first appear to be trashed but in fact it is not, and on the next admin page load a notice will be displayed explaining the situation. I don't think this detail matters much because it only affects superusers.

Yep, that's the only way I know of to customise the comments module.

Hi @ryan, The new field tag features are cool, thanks! It's not quite the same, but in some ways being able to use a different name (tag) to refer to a field in a selector is similar to a request I raised a while ago about an idea for field aliases. So for example if I have a field with a generic name like text_1, when it is in my employee template I can use it in my template file and selectors as first_name. That would help a lot with code readability and encourage more efficient field re-use. Could the new field tag features be leveraged in some way to add support for field aliases? Probably as a separate thing to tags, but perhaps building on some of the same code you added this week?

Hi @adrian, I'm still experiencing the issue below in the latest Tracy: I can fix it with the CSS I mentioned earlier... ...but it would be handy to have that as an option built into the module so no custom CSS is needed. Thanks!

Batcher is actually @Wanze's module - I just forked it to fix a couple of PW3 compatibility issues. Glad to hear that it's working for you now.

@OviS, I just tested the module in PW 3.0.104 and it is working fine. I think perhaps you have something configured wrong - double check that you are using the format virtual_parent_template=virtual_child_template in the module config and that both your virtual parent page and your virtual child pages are at the same level in the tree when the module is disabled. Virtual Parents disabled: Virtual Parents enabled: Or else perhaps another module or custom hook is interfering with the Virtual Parents module? You could test the module on a clean PW installation and see if you still have the same issue.

You could try out the idea for "Dynamic parent and/or template for pages created from the inputfield" outlined in this post:

You already have part of the logic for this - now you just need the else. I would tend to flip the logic around the other way though... if($p->id) { // $p is an existing page, so prepare it for saving new field values $p->of(false); } else { // No existing page so create one $p = new Page(); // ... } // Now set the field values of $p Keep track of the job ids in the RSS feed using an array. Then find any pages with job ids that are not in the array and delete them. $job_ids = []; foreach($rss as $item) { $job_ids[] = $item->id; // The rest of your code... } // Implode for use in selector string $job_ids = implode('|', $job_ids); // Find pages for deletion $delete_pages = $pages->find("job_id!=$job_ids"); foreach($delete_pages as $delete_page) { $delete_page->delete(); }

Thanks for adding this feature! It might be good (just to avoid any confusion) to exclude the skip trash option on the delete tab of ProcessUser because the deletion there is permanent by default.

You can do it without having to save the page using the (undocumented) core dependent selects feature. There are some requirements for it to work. More info:

The core inputfield dependencies feature doesn't support this. It works via Javascript and can only read field values that exist in Page Edit - the published status is not one of those field values. But the Custom Inputfield Dependencies module can help you out here.

Works for me.

Yes, it can be done. The documentation for the Repeater fieldtype shows API code for adding repeater items. The general approach is that for every row you will look for a "group" repeater item by title and if no item matches that group name you create one. And for every row you create a "photo" repeater item inside the relevant group item. Not tested but it should work once you have changed $page and any field names to suit your setup: // Parse the CSV data $handle = fopen('/path/to/your/file.csv', 'r'); while(($row = fgetcsv($handle)) !== false) { // Columns (maybe there are actually more of these) list($group_name, $image_name, $price) = $row; // Get the group item for this $group_name /* @var RepeaterPage $group_item */ $group_item = $page->groups->get("title=$group_name"); // If no such item exists, create one if(!$group_item->id) { $group_item = $page->groups->getNew(); $group_item->title = $group_name; $group_item->save(); $page->groups->add($group_item); $page->save(); } // Create a photo item for this row /* @var RepeaterPage $photo_item */ $photo_item = $group_item->photos->getNew(); $photo_item->title = $image_name; $photo_item->price = $price; // If there are more columns deal with them here $photo_item->save(); $group_item->photos->add($photo_item); $group_item->save(); // Perhaps not needed, but save the page for good luck $page->save(); }

I agree. Please create an issue for it on GitHub: https://github.com/processwire/processwire-issues/issues

The InputfieldImage::getAdminThumb() method with the "remove legacy thumbnail file" argument is what you want to use. You'd loop over all the images in your site and call that method on each one. I think this will do the job... $if_image = $this->modules->InputfieldImage; foreach($fields->find('type=FieldtypeImage') as $field) { foreach($pages->find("{$field->name}.count>0") as $p) { foreach($p->getUnformatted($field->name) as $image) $if_image->getAdminThumb($image, false, true); } }

Speaking of deleting pages, what do you think about the idea I raised a while back... Sometimes when testing you want to permanently delete a page after you have created or edited it, so it would be handy to be able to do that from the Delete tab rather than going back to the tree. Instead of another checkbox inside the "Move to Trash" inputfield like I showed in my earlier suggestion (I don't think it's even possible to do that with the forms API) it would be better to have a separate "Delete permanently" inputfield added to the Delete tab.

I think the Connect Page Fields module will be suitable for this. You would create two new Page Reference fields for your Skyscraper template: interior_photos and exterior_photos. The visibility of these fields could be set to hidden if you don't want to see them in Page Edit. Then you would connect those fields to the corresponding fields on the Photo template. In terms of matching skyscrapers with or without interior or exterior photos you would then match against the count of the Page Reference field rather than a boolean.

Hi Ryan, With the addition of the new profile, in terms of file size nearly 60% of the core is now made up of site profiles. For new users these profiles are no doubt very handy, but I think for a lot of existing users the profiles (apart from "blank") are not needed. Speaking for myself I don't have a need for the bundled profiles and so delete them each time after downloading a new version from GitHub. Doing that isn't a big deal, but it would be nice to keep things as lean as possible for users who don't need the profiles. And I'm not sure but are the profiles downloaded and discarded each time PW is upgraded via admin? What do you think about starting to make use of the Releases feature of GitHub? Each time when a new version is ready there could be a new release created, containing two zips: "processwire" and "processwire-no-profiles", or whatever naming scheme you think best. Using releases would have some other benefits too. For dev branch users it would be easier to know exactly what version of PW you are running, as opposed to the current scenario where changes to the latest version get pushed out over the week so someone who installs 3.0.105 on Saturday may have different files to someone who installs 3.0.105 on Thursday. When someone raises a problem in the forum they could say exactly what version they are running (could be an older release) and people who want to help could more easily download that exact release to try and replicate the problem. Another benefit to using releases is that you can collect metadata about downloads. That would be a great way to track the growing interest in PW over time. https://help.github.com/articles/getting-the-download-count-for-your-releases/

You could approach it that way, but I think I would be inclined to keep adding inputfield types to the array that are known to be compatible rather than risk affecting an inputfield that is not compatible. Because the consequences of excluding a inputfield that does work are minimal (user sees a notice after the form is submitted rather than before) but the consequences of including an inputfield that doesn't work are more severe (user cannot submit the form and does not see any notice explaining why). The HTML required attribute will not work for any inputfield that hides the actual input that holds the value, e.g. CKEditor, AsmSelect, File, Image, PageListSelect, etc. If you take the "extends" option then you need to start excluding inputfields as well as including them - e.g. you might include Textarea and Select because those inputfields will work with HTML required, but you would have to exclude some inputfields that extend those types such as CKEditor or AsmSelect.

The HTML required attribute seems like it would be a handy thing to use on all inputfields that play nicely with it, whenever that inputfield is required. Might as well give the user a notice before the form is submitted rather than after. The hook below does this, but as per the core option for InputfieldText it does not cover "required if" conditions: $wire->addHookBefore('Inputfield::render', function(HookEvent $event) { $inputfield = $event->object; $type = substr($inputfield->className, 10); // Only for inputfield types that play nicely with the HTML required attribute if(!in_array($type, ['Text', 'Email', 'Datetime', 'Textarea', 'Integer', 'Checkbox'])) return; // Only if the field is required and has no requiredIf condition if($inputfield->required && !$inputfield->requiredIf) $inputfield->attr('required', true); });

@chcs, as you probably know the ProcessWireUpgrade module doesn't keep modules up-to-date by itself. You still have to log into each site, visit the Upgrades process page, look to see which modules need updating, and then perform the upgrade for each module that has an update available. So it isn't really any faster than updating a module via "Add Module From URL", which you can do for a private repo as per the thread below: That is for GitLab repos but I'm sure there's something similar possible for private GitHub repos. For a single private module it doesn't seem like it would be worth the trouble to create another website to provide the custom updates feed.

Use a hidden inputfield: $field = $modules->get("InputfieldHidden");

I haven't heard of this issue occurring before. Suggestions... 1. If you have added any hooks in /site/ready.php or /site/init.php then temporarily remove those while you are investigating the issue. 2. Concentrate on granting edit access to the home template first. That template is a good place to start because it isn't affected by access inheritance. 3. Check the edit access settings at Access > Roles > your_role... ...and at Setup > Templates > your_template... 4. Install the Access Overview module as another way to view and verify edit access.

Right. I don't think that's possible. By design (for security) PW generates one of the salts randomly when the password is saved so you cannot recreate a hash later that will match without having the salt that is stored along with the hash in the password field table. But typically you would have some other data available to get the relevant row from the password table. So you match to the page using some identifier like a username, then look up the row using the page ID (assuming you are doing it with SQL rather than using PW methods). So in the OP's example there is "user=abc" so that should be used first to match the relevant page rather than looping over all user pages.

This works for me (using the core "pass" field in the user template)... $u = $pages->get("template=user, pass=$hash"); Alternatively there's nothing wrong with using a SQL query to match data from the password field table directly if that suits you better.