spinhead

mea culpa

it appears the culprit was the PHP version in bashrc on both accounts. mind you, other accounts have the same PHP version in bashrc and work fine, but changing it on these seems to have resolved the existing issue.

thank you for your patience and pointers.

Ah. I misunderstood.

The debug option should have been obvious. Since I’ve already updated the plugin manually I suspect the debug info won’t be meaningful, but I will modify my script to include it and gather the info next time there’s an update.

Mistake on my part: TWO of my sites are affected. Added the address of the other to the original post in an edit.

Core is always updated before plugins. No errors.

“lead me to suspect that it is isolated to that one specific environment.”

That’s what I stated in my post. Not looking for someone to reproduce the error since it is isolated to this specific environment. As posted, asking for suggestions to troubleshoot and isolate what it is about this specific environment that is creating a conflict between wp-cli and the plugin.

Using identify -verbose /Users/joel/reharmonization1.jpg

There is nothing in the exif information that includes the word ‘Screenshot’

EDIT
MacOS Monterey 12.7.5
WP 6.6.1

• This reply was modified 2 months, 3 weeks ago by spinhead. Reason: add OS and WP version info

sigh. simple obvious solution. it was a plugin. all is working as expected now. thanks.

It is returning the first 60 lines of the source code of the referenced site. Just the WordPress code for the site you’d see if you ‘view source’ when you’re at the site.

First place I went. Like much of the wp-cli documentation, it is superficial, merely stating the obvious.

What creates these cache files? What will recreate them and when will they be recreated, should I choose to delete them?

Can we drop the commentary on hosting? It’s not helpful.

• This reply was modified 1 year ago by spinhead.

The answer, if I am reading your response correctly, is that it won’t break anything, but won’t solve the “wp cli is using 1/4 of our hosting space” problem because it will grow back when I run client updates tonight.

To the hosting space point: most hosting providers provide nothing BUT space, no actual support of any kind. The small family owned hosting company I use provides the very best technical and customer service I have experienced in my 50 years of working with computers, even on these $52/year accounts. So moving to some all-you-can-eat buffet of cheapness, or spending 5x as much for some specialty house, is not the solution. I may, however, pay the $15/year/client to upgrade all my clients’ hosting so I’m paying for wp-cli instead of them.

I have finally found an old old thread which, even then, refers to these files as “ancient but for backward compatibility.”

The tool should either flag them as unnecessary or not flag them at all. If all the updates over the past 10+ years haven’t removed them, the tool should take that into account and, perhaps, flag them as “deprecated, can be safely deleted.”

Off to 1) delete them from my installs and 2) create a pull request for said change.

For me, the false positives are the entire issue. Is the tool at fault? Is it my configuration or use of the tool?

Automation means never having to chase false positives, eh?

Continued persistent searching led me to this answer:

https://danielbachhuber.com/tip/customize-doctor-config/

makes sense, yes. thanks!

D’oh. It certainly does. Thank you.

(I plead 40+ doctor’s visits and multiple ER and hospital visits in the past year impinging upon my cognitive abilities.)