faglork

never mind

Passt! Danke für die schnelle Reaktion!

Servus, Alex

Same problem here. Clearing caches doesn’t help.

Hi! I am using hueman / hueman pro with php 8 / 8.1 without a problem.

But when I updated to 8/8.1, nearly all sites went down either due to an incompatible php code in the child theme’s function.php OR a plugin which did not support php 8/8.1

Hope that helps,
Alex

Thanks for your input!

“Default user and group for Apache process usually are not the same in a different distribution. Ubuntu, for example, sets the default user and group to www-data, while on CentOS, it’s apache”

As I said: all sites reside on the same server, use the same environment, same php vesion, and are all clones of 1 wordpress installation.

——————————-

“Check the information in your Apache vhost as described in the link above. ”

As I already said: I did, and they are identical:

“I then checked the complete phpinfo() for both sites. I saved the output and ran it through UltraCompare. Result: identical, only diff is the server directory …”

httpdconfig is identical as well (besides domain an directory etc.)

Cheers,
Alex

Thanks!

I managed to install the Health Check plugin MANUALLY by uploading the .ZIP, which worked but installed it with the owner “apache” (installing directly from the wordpress plugin list fails because missing permissions …). Anyway, the plugin works.

Now:

I checked Tools > Health Status > Info > Button “PHP-Information” on one site (A) that works (updating/installing as “www123”) and one (B) that works not (updating/installing as “apache” and failing).

Turns out: In both cases the user is “apache”.

Yet when I install a plugin on site (A) the owner of the files is “www123” (as it should be), and everything is fine.

On site (B) it tries to install the plugin under the owner “apache” and fails.

“The user with whom you write WordPress files depends on the web server service you use. This is not something that WordPress as software can determine or set on a system. […] There, under “Environment”, you can see the user with whom the web server is working.”

As I said, in both cases – according to phpinfo – the user is “apache”.

So it must be something else.

I then checked the complete phpinfo() for both sites. I saved the output and ran it through UltraCompare. Result: identical, only diff is the server directory …

When the user under which WP is operation is “apache”, then in case of website (A) (and all other websites) there MUST be a piece of code somewhere to determine that all files/directories should be written with “www123” as user. I checked the FTP-Information in wp-config.php: they are correct in both cases, giving the credentials for their respecctive ftp user.

So I am still at a loss. Why does website (B) use “apache”?

Cheers,
Alex

I installed again, this time via FTP.
Cannot activate because:

`Fatal error: Uncaught Error: Undefined constant “DBVERSION”
in /www/1234/htdocs/wb/wp-content/plugins/iq-block-country_/libs/blockcountry-logging.php on line 56

Aufrufstapel

iqblockcountry_update_db_check()
wp-content/plugins/iq-block-country_/iq-block-country.php:151
iqblockcountry_upgrade()
wp-content/plugins/iq-block-country_/iq-block-country.php:208
include_once()
wp-admin/includes/plugin.php:2313
plugin_sandbox_scrape()
wp-admin/plugins.php:192

• This reply was modified 2 years, 4 months ago by faglork.

Just installed the latest version form www.ads-software.com.

readme.txt says “Stable tag: 1.2.17”

Plugin overview still says “there is a new version available” 1.2.17

So something still does not work …

I am on php 8

This box is already checked, but oviously does not work.

I will mail your soupport.

Alex

It is a bit embarassing ??

I use WPFTS Pro and I accidentally activated the option that the posts shold not be sorted by time, but by “time last modified”. So every time I made the post “unsticky” I “modified” it and it stayed on position 1 – because sorted by “last time modified”. And even when I deleted it and made the same post but dated back, it would still appear on first position …

Had I immediately posted a bunch of new articles, I would have noticed that the ex-sticky post would have wandered down the timeline. But I did not, because I was so perplexed and was preoccupied with looking for an error/bug.

Over night, my team collegues added more posts, and in the morning the “ex-sticky” post wasn’t on the frontpage anymore. So I wrote it off as a one-time quirk – until it happened with the next sticky post.

But then I modified some real old files, and they showed up on front page … which brought me on the right track.

Took me a while to figure that out, though. Since I chose the option “sort by time last modified” accidentally – it is a dropdown and I must have selected the wrong option – I could not remember it, I thought I had chosen “sort by time published”. But after the re-appearing of old posts I remembered that there WAS such an option, so I checked and saw that indeed I had activated the wrong one …

Alex

• This reply was modified 2 years, 7 months ago by faglork.

Nevermind. I got it. An idiotic configuration problem.

Does anybody actually read my posts?

I have now told THREE times that this problem is theme-independend: Changing themes does not change anything. I tested with 2020 and 2022. No change.

Alex

It went briefly away, but now the problem is back :-((

I double-checked:

– post is made sticky, stays on frontpage, appears in “sticky posts” list

– post is made unsticky, still stays on frontpage, but disappears in “sticky posts” list

– post is duplicated, original post is deleted

– duplicate post is saved under different filename, differnet ID, different date (2 days back). post is not sticky, and not in “sticky posts” list

-> the post is still sticky on frontpage, carrying the new ID and filename!!

Cache plugin w3tc is disabled.
Changing themes has no effect.

I am completely at loss.

Alex

“The entry you mentioned in the options table is usually quite sufficient.”
That is why I am at a loss …

“If no caching plugin is in the way”
Cache plugin is deactivated – cache cleared – browser cache cleared – no change.

“it could be only a special treatment by the used theme.”
As I wrote: “Changing themes does not help.” I tried 2020 and 2022. No change.

The problem is not theme-specific.

cheers,
Alex

I have exactly the same problem.

I have the Advanced access manager installed, and when I deactivate the AAM then the problem vanishes.

So it seems you are right with your assumption that “plugins that modify capabilities” are involved.

I don’t know since when this is the case or what triggers it, last week all was well.