adrian

Thanks @bernhard - should be fixed in the latest version. It looks like at some point PW starting deleting the fieldgroup along with the template automatically, hence the new error.

It is weird to me seeing all those paths like "ProcessWire\UserPage.php" in amongst the other full correct paths. They are clearly not valid and will trigger errors for any open_basedir restrictions. So it does seem like a question for Ryan from what I can see.

Hi @bernhard - I am not sure why PW is trying to an is_file() on ProcessWire\BasicPagePage.php because that's obviously not a valid path. Perhaps you could assist by checking back through the stack trace to see where it is coming from. The referenced line in the RequestInfo panel is a $p->child() call, so not sure how that alone could be triggering this error.

@nexuspolaris - the screenshot you posted is not for the settings tab of that page. Please enter those field pairing in the BCE settings on the Settings tab.

@artfulrobot - sorry, I really don't know. I haven't ever seen this or had anyone else mention it. Is it specific to one server / machine, or can you reproduce on others?

Thanks @Laegnur - I have committed those changes to the repo.

The field pairings is only available from the Settings tab of those pages selected under Configurable pages. Does that help?

Thanks - that has taken care of things. I actually think there are lots of modules that get loaded via CLI scripts even though they aren't needed. I kinda think PW should have a module autoload option for this to make it easier / more obvious to the developer to disable via CLI unless needed.

That would make sense, except I have been running 8.2 on that server for many months and the error started appearing immediately after updating Jumplinks from 1.5.61 to 1.5.63. Yep, that should work just fine. Just a little FYI about something I have noticed in the past - sometimes $_SERVER['REQUEST_URI'] returns false rather than the URL or NULL (https://github.com/nette/tracy/issues/351) which means checks need to consider that. Obviously not relevant given your CLI check. PS - thanks so much for continuing to support your modules even though you're no longer using PW - very generous indeed.

@Mike Rockett - sorry, I should have come with more details - looks like it's happening from a cron executed PHP script that bootstraps PW. That would explain why it's null. I'm not sure why it's a new error though - on a quick scan I can't see anything from your most recent commit that would cause this change.

Hi @Mike Rockett - brand new issue with the latest version: PHP Deprecated: ltrim(): Passing null to parameter #1 ($string) of type string is deprecated in ProcessJumplinks.module.php:206 EDIT: I see that line hasn't changed recently, but I've never seen the error before on the same server with no recent PHP upgrades. Regardless, it still needs a fix please and thanks.

Have you tried a hard reload in the browser? I know it sounds strange, but I have seen PW return cached results before. Please let me know if that works.

Actually, something to consider - what about on Windows - wouldn't that need the extra slash because instead of the filepath starting with a slash it would start with a drive letter.

Yeah, I know about this and not sure there is an easy way around it, but it fixes itself after a modules refresh.

Hey @bernhard - you can change this in the module settings in the "Editor Links" section. Just change: vscode://file/%file:%line to: vscode://file%file:%line I'll change the default value and note in the next version.

At a quick glance, it feels like you are missing a level when getting the video. You need to get the video_field from the select_video, but instead you are getting video_field from $item. Does that sound right?

I always have https://processwire.com/modules/module-settings-import-export/ installed on all my sites, so no need from my end for it to be built into your module.

Actually, the only other suggestion is to make it a real initial value for the textarea rather than a placeholder, because I actually had to go and open mysqldump.unix.sh to get a starting script I could then edit.

Thanks @flydev The only issue I noticed is that the supplied mysqldump.unix.sh looks like this: #!/bin/sh # (1) Set up all the mysqldump variables FILE=%%FILE%% DBSERVER=%%SERVER%% DATABASE=%%DATABASE%% USER=%%USER%% PASS=%%PASS%% CACHEPATH=%%CACHEPATH%% # Fix trailing slash in cache path CACHEPATH="${CACHEPATH%/}/" OUTPUT="${CACHEPATH}${FILE}" # (2) In case you run this more than once a day, remove the previous version of the file # unalias rm 2> /dev/null # rm ${FILE} 2> /dev/null # rm ${FILE}.zip 2> /dev/null # (3) Do the mysql database backup (dump) # - to log errors of the dump process to a file, add --log-error=mysqldump_dup_error.log # (a) Use this command for a remote database. Add other options if need be. # mysqldump --opt --protocol=TCP --user=${USER} --password=${PASS} --host=${DBSERVER} --port=${PORT} ${DATABASE} ${DATABASE} > ${OUTPUT} # (b) Use this command for a database server on localhost. Add other options if need be. mysqldump --routines --triggers --single-transaction --user=${USER} --password=${PASS} --databases ${DATABASE} > ${OUTPUT} Note the missing PORT from the variables in #1 and also the duplication of ${DATABASE} in #3a Once I fixed those two things, it work great! Thanks again for making this configurable - a really nice improvement!

Hey @Robin S - good question. I have played around a little without any success. I feel like I am missing something obvious like output buffering getting involved, but perhaps it is just down to the way I instantiate a PW template and render it via AJAX https://github.com/adrianbj/TracyDebugger/blob/ec79b76bf0443118a6c402c9ffe2a9c491a8b5cc/includes/CodeProcessor.php#L197-L203 I'll keep mulling it over, but not sure what the solution might be at the moment.

Thanks - looks like it goes deeper than php-saml to one of it's dependencies (https://github.com/robrichards/xmlseclibs) - https://github.com/SAML-Toolkits/php-saml/issues/79 php-saml branch without mcrypt: https://github.com/SAML-Toolkits/php-saml/tree/remove_mcrypt but this was created in 2017, so who knows when it will make it into the master branch. And it looks like mcrypt has been removed from https://github.com/robrichards/xmlseclibs - https://github.com/robrichards/xmlseclibs/pull/101 I don't know - looks like some of these relied upon packages aren't really being maintained anymore, so hopefully php-saml will merge those changes to master sometime :)

@BitPoet - thanks so much for your hard work on this and sharing it with everyone. Just curious though about the need for the PHP-mcrypt library. I thought it was considered important to instead use sodium these days. I'd love your thoughts on this because it seems like you are pretty in-tune with these types of things.

Thanks @ryan - this is fantastic update. My initial testing shows that OR selectors are now working for the WireCache $expire selector (https://github.com/processwire/processwire-issues/issues/1828) which really opens up the ability for some huge performance benefits. Thanks again!

Yeah, PW page objects are pretty huge. I wonder if you might also benefit from removing the Full Object tab from the dump and just going with the Debug Info tab? Personally I wouldn't because there are times I do want to look through the full object, but perhaps you might find it a better option?

That is the reason that d() is the standard method for dumping rather than db (dumpBig). d() uses those defaults, but db() overrides them.