Robin S

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); // ...

Hi rick, I think you need a trailing slash for AJAX URLs in PW. Try "./some-thing/"

Thanks horst. I did some searching and thought it might be useful to compile a list of the issues, which are mostly (or perhaps all) resolved now. Solved: The issue mentioned above where some images were lost when multiple large images were uploaded simultaneously. https://github.com/ryancramerdesign/ProcessWire/issues/1871 https://processwire.com/talk/topic/13522-problem-with-ajax-images-upload-and-sessionhandlerdb/ Solved: Session times recorded incorrectly when MySQL timezone does not match local time. https://github.com/ryancramerdesign/ProcessWire/issues/1838 https://processwire.com/talk/topic/13307-session-handler-database-times-out-by-two-hours/ Solved: Truncated session data when Tracy Debugger installed. https://processwire.com/talk/topic/15784-what-will-trigger-a-csrf-error/ Solvable: Old sessions not deleted on some Ubuntu servers. I have struck this one myself and @horst's suggestion in the post below solved it. https://processwire.com/talk/topic/5796-session-handler-database-do-not-delete-old-sessions/?do=findComment&comment=56596 Fatal error thrown on Windows server using IPv6. https://github.com/ryancramerdesign/ProcessWire/issues/1596 https://processwire.com/talk/topic/12935-issues-moving-from-iis-localhost-machine-into-windows-server-production/ Slow performance with large number of sessions. https://processwire.com/talk/topic/18718-session-handler-db-issue/ But with huge amounts of traffic performance may be affected without SessionHandlerDB installed too. Login problems after website migration. Might be solvable by clearing caches. https://processwire.com/talk/topic/5317-cant-log-in-this-request-was-aborted-because-it-appears-to-be-forged/?do=findComment&comment=142160 https://processwire.com/talk/topic/13781-problems-after-installing-remote-copy-to-local/

Great, that will be really useful on sites with premium (paid) memberships where you want to prevent multiple users being sneaky and sharing a single account. Thanks @kixe and Ryan. I've avoided SessionHandlerDB apart from when I really need it because I've heard of strange issues that have eventually been traced back to this module. Unfortunately I can't remember what those issues were. For regular users of SessionHandlerDB: are there any issues or incompatibilities with other modules to be aware of? Nice! I only wish the announcement had come a couple of weeks earlier. ? I spent some time recently modifying ProcessForgotPassword for just this purpose. Excellent, I have closed an old request relating to this.

I think of the API reference as the official docs rather than the cheatsheet. The cheatsheet hasn't had a comprehensive update for a long time and there are loads of things in the API reference that aren't in the cheatsheet. The loadOptions / joinFields options are covered in the API reference: https://processwire.com/api/ref/pages/find/ loadOptions (array): Optional associative array of options to pass to getById() load options. https://processwire.com/api/ref/pages/get-by-id/ joinFields (array): Autojoin the field names specified in this array, regardless of field settings (requires autojoin=true). (default=empty)

Welcome @Shoekrates, FormBuilder is a Pro module so you can get support from Ryan in the dedicated FormBuilder sub-forum.

In AdminThemeUikit (might be dev branch only at the moment) you can choose from a few colour options for inputfields: But it would be more flexible to use your browser dev tools to inspect the markup in Page Edit, find what class is unique to the inputfield you want to change, then use AdminOnSteroids or AdminCustomFiles to add a custom CSS file to change the background colour.

The module does not support this, but you could edit the module file, adding the following line here: $embedCode = str_replace('youtube.com', 'youtube-nocookie.com', $embedCode); If you later update the module the change would be overwritten and you would have to redo it.

It would pay to think about how it will work if a user has permission to edit a child page but not its parent. Hiding non-editable pages means hiding any branches under those pages.

You can't add a Field object to a form, but rather an Inputfield object. Field::getInputfield() would come in handy here.