Robin S

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.

If you only want to output the timestamp comment if the page has template cache enabled you could do a conditional like this: if($page->template->cache_time > 0) { // Output your timestamp comment } There are some other cache-related properties present in Template objects that you can explore with Tracy Debugger in case they are useful to your goal. bd($page->template);

The Page Field Edit Links module supports this.

Put quote marks around your search string so PW can distinguish between the selector string and the search string, e.g. $selector[] = "(repeaterField.fieldX|repeaterField.fieldZ%='{$search}')"; That is a more advanced usage than what is covered in the blog post. You'll need to use the "verbose" version of a selector array. Ryan gives an example of a verbose selector array this in this GitHub comment. And for more details and the specifics of OR-groups in a selector array see the comments in Selectors.php here and here. TBH you might find it easier to stick with selector strings for such things until we have proper documentation for selector arrays.

I haven't used template cache because I use ProCache instead, but wouldn't it simply be a matter of including the current date/time inside an HTML comment in your template files (or _main.php if using delayed output)? When a cached version is served you will see the time that was current when the markup was generated.

@alexmercenary, when I test it using the function proposed in the blog post that introduced $config->sessionAllow... $config->sessionAllow = function($session) { // if there is a session cookie, chances are user is logged in if($session->hasCookie()) { return true; } // if requested URL is an admin URL, allow session if(strpos($_SERVER['REQUEST_URI'], '/processwire/') === 0) { return true; } // otherwise disallow session return false; }; ...then it works as advertised. That is, when I am not logged into the back-end there is no cookie set. Are you deleting any old cookies before you check for the cookie when not logged in?

No, I don't think it does, because it extends InputfieldMarkup and it seems that InputfieldMarkup does not support multiple languages. As a workaround maybe you can add one MarkupCKEditor field per language and then hide the ones not needed using CSS or a FormBuilder hook. If you have questions about how to hide fields like this then the FormBuilder sub-forum would be the place to ask.

Welcome @Beetrootman! Seems you found a bug. I have opened an issue at GitHub: https://github.com/processwire/processwire-issues/issues/603 P.S. LICEcap is a nice tool for doing screen captures in a forum-friendly embeddable GIF format, so users don't have to download a video file.

When you use a single "." at the start of a URL it means "the current path". Your Javascript executes from "/admin/myprocess/option1/", so when you define the AJAX URL as "./option1-list/" the resulting URL will be "/admin/myprocess/option1/option1-list/". There is no execute method for that URL. Generally you would expect a 404 error, but because URL segments are enabled for Process modules the URL segments are parsed and the valid segment "option1/" is found, and the "option1-list/" doesn't resolve to anything so is effectively ignored. So that is why executeOption1() is executing and you are getting that data back in the AJAX response. For your own clarity I suggest assigning an absolute URL to a variable in Javascript and using that as your AJAX URL. That way you can log the URL to debug and be sure it is what you are expecting. var url = ProcessWire.config.urls.admin + 'myprocess/option1-list/'; console.log("url: " + url); // ...