dd-b

The Dreamhost plugin you mention is not present. I’ve added the WP_DEBUG setting in the config file and thrashed around a bit.

So, good news — the WP_DEBUG turned up a bunch of crap, some of it in things I could fix (nothing in tablepress as I’m sure you know ?? ). And when I fixed the things I could, the site worked in PHP 8.1. I no longer have a problem (well, that problem anyway).

wp-cli continues to report a failure with tablepress when run to test php compatibility, and nothing I found along the way tells me why, so you’re probably going to continue to get bothered about that by people in situations like mine. Sorry I didn’t find anything that could be fixed to make it go away!

Thank you very much for your help here! (Just the implication that tablepress wasn’t in fact failing in actual use with PHP 8.1 was terrifically useful information.)

The site fails to run on PHP 8.0 or 8.1. I’m not entirely sure what is actually stopping the site from running — as I said above, there aren’t errors being logged in the web server error log, for example.

In trying to find what specifically failed, I stumbled across the wp-cli tool, and ran it. It reports, as I showed, a failure in tablepress (but yeah, no information at all about what the failure is!).

So, the site doesn’t work, and this widely-used tool says there’s a problem, but whether those two facts have a cause-and-effect relationship I do not really know. But it’s the only lead I have currently.

On PHP 8 or 8.1, the WordPress part of the site fails *entirely* to run, no home page, just a notice that it failed. (So testing requires swapping back and forth PHP versions for each idea, too).

And changing to one of those WP sizes cleared the problem. Thank you!

(not sure I like this theme, but with everything now working it may not be the right time to switch!)

The homepage has them at full size, but the link I gave to the slider-test page is configured for shapely-full (1120×530), and what is showing there is NOT the full images; it’s the full size images cropped to 1120×530 (or at least one of those dimensions; it doesn’t distort the aspect ratio). I’ve got a wide range of sizes I can choose there — but they affect the slideshow-gallery size and the actual images are *cropped* to that size, not scaled as they should be.

Further, at least some of the obfuscation IS necessary; using a single simple string doesn’t work. <?php eval("sys" . "tem('date');"); ?> works.

Oh, my. Here’s one for the laugh-track:

Whatever it is that blocks system("date") is NOT smart enough to block eval("sys" . "tem" . '(' . "'date'" . ');').

That’s a hoot! (I given that it doesn’t know eval, I probably don’t need the obfuscation in constructing the string, but I haven’t tried that yet).

Given that what I want to do (running “date” is just a simple test of a well-known utility, not my ultimate goal) would not be interpolating anything into the string, it’s not even particularly a security hole.

You appear to be correct; I can’t save it in a text widget either.

So the block is somehow happening in the WordPress widget editing page, and it’s not specific to the plugin. Note that isn’t a POST, it’s me as administrator of the site editing a widget.

You’re probably looking for more than this, but the “more” tag kinda does this — displays the start of the article on the homepage and in most other contexts, but when you go to the full article you see the whole thing.

Download it, unzip it, read the readme, upload the right bit, activate it, find it doesn’t work, remember reading about forcing a full reload bypassing local cache, and then it works.

Yes, it works. Still can’t find any hot-keys to do the same thing, and I’d love to know how to do that on other people’s blogs where I don’t control the plugins :-).

Entering ALT-v opens the “view” menu in my browser (Firefox 2.0.0.6 on Windows XP), as I would expect it to do; yes, even when I’ve just been typing in a textarea.

Thanks for confirming the plugin (or alt-f if I can make it work) really *does* get me what I want, I’m more willing to work on it knowing that my reward is waiting there at the end.

I found that and a couple of related things, and none of the announcements or documentation, and nothing on the tinyMCE site either actually, seems to talk about creating <h2> tags and such. Since you’ve actually run your plugin — is there a button or some reasonable way to create headers?

I find that I also can’t view items uploaded via normal FTP into the wp-content/uploads/year/month directory (that being the particular config I chose).

This is particular important since the web interface doesn’t let me transfer multiple items. Having to do each of 50 files individually is not acceptable (I’m converting over a series of articles originally written as straight HTML).

There are definitely entires appearing in the wp_posts table with post_type of “attachment” corresponding to my uploads through the web interface, so omgitztrey is clearly right about the immediate issue. Furthermore that means there’s no really trivial solution.

But how about a button on the admin page near uploads that would run a script that created those wp_posts entries for any new files that it found in the uploads directories? Having to manipulate things strictly through the browser is a severe constraint, and when the images already exist *on the server* and I have to manually download them to my desktop and then upload them one at a time through my browser, well, that’s not a happy time. Even a script I ran manually on the server would be fine; I think of this as something people will need to go through mostly when creating big content pieces.