I started looking at what the users page queries, and I spot some things that are definitely going to be inefficient at scale, specifically this query as shown in the debugger:

SELECT DISTINCT u.* FROM users AS u LEFT JOIN groups_users_link AS m ON m.uid = u.uid WHERE ((`level` >= '0')) ORDER BY user_regdate DESC LIMIT 0, 20

I do not have a running XOOPS 2.5.4 system handy to check, but I will just assume it is similar. It has a guaranteed table scan, with a join, and a sort on a non-indexed column -- that's going to be problematic at scale. I'll look at this issue, but I'll be working from our newest code. I'm not sure at all how anything will backport at this point.

Thinking strictly on the MySQL side, when things make sudden jumps in resource usage, there is often a factor in how things are laid out on the disk volume, or some corruptions. I would try exporting the table, dropping and importing it. (On your scale, import is probably best done from mysql on the command line, not through phpMyAdmin.) That might smooth out a few things.

If that didn't do it, I might also try an index on the user_regdate column. That and the limit clause might be enough to reduce the physical i/o to manageable levels.

Another thing to consider, since your user delete was done outside of XOOPS, the groups_users_link table now contains entries where the uid no longer exists in the users table. The saving grace is the table row is very small, but it should have around 200000 dead rows.

NB - always make a backup, and work on an expendable copy NOT on your production data.

Quote:

I suspect that {X_NAME} was not included because it can be blank, so it can lead to confusing messages.

If we add it, I would suggest that we set it the same as {X_UNAME} if the name is empty. That would make it more dependable for normal use.

If that sounds useful, just open an issue for it on GitHub.

Please seehttps://github.com/XOOPS/XoopsCore25/pull/841

It enables manual editing of the option text from a link at the bottom of the admin field edit form.

Thank you for the more complete problem description. Wow, that sucks. I'll look deeper.

After "profile" is installed, the definitive title and description source is no longer the language files, it is the database. You can edit all of that in the admin area -- much easier than saving tables and reinstalling since there are only 24 fields that could be affected.

I agree that the profile module's language support is limiting, but that is largely due to the ability to fully customize and extend the user definition. Needs improvement, but that it isn't likely to happen in the 2.5 series.

I just want to make sure what you are asking for.

As I read this, it sounds to me that you want to intercept a URL
XOOPS_URL/?page=23
and have that instead result in an HTTP error, such as 404.

Is that correct?

Here are a few general observations.

While the link that is causing the issue is wrong, it is not technically an error. The custom error pages don't get called, as there is no HTTP error triggered. (The front page is found, and passed a query string it ignores.)

Something is creating the links that google follows. Until you find a correct that, there will still be a problem somewhere. Has anything been updated recently? As an example, I saw a module before with a XoopsPageNav error that generated links that looked a lot like this.

Goffy's suggestion about the search console sounded worthwhile.

Seeing the referrer for one of these problem URLs would pinpoint the actual source of the problem.

As a temporary solution, you could patch the XOOPS_ROOT_PATH/index.php

Adding this code on the next line after the opening "<?php" tag will cause any query string parameters to result in an error, and log the referrer if specified:

Where are you running the install code? On your local computer or on webcindario.com?

In the fourms athttps://soporte.miarroba.com/ there are a number of problems reported because
mysql.webcindario.com does not accept external connections. The PHP code must be running on a webcindario.com server.

Think about that in the other direction.

You have a your git clone of XOOPS-monxoops-Traduction-FR.
You also have your wamp accessible XoopsCore25.

Make a script (*.bat file) that will copy the htdoc directory from XOOPS-monxoops-Traduction-FR to the htdoc directory in XoopsCore25 (i.e. using robocopy). Add another line in the script to copy the upgrade directory, too. (You want to make sure you don't copy the ".git" folder as that would be bad.)

Now, adjust your workflow to edit your translation in your XOOPS-monxoops-Traduction-FR repository, then run the copy script to test everything in wamp.

If you automate this with a script, and always edit in the XOOPS-monxoops-Traduction-FR repository clone, you always have all the updates that need commited in the right place.

A couple of apologies:

Sorry that the language folders are so awkward to work with. Making the translations much easier to work with and install is a high priority in the next generation XoopsCore.

Also sorry to be vauge about the Windows commands -- last time I rebooted into Windows, I had to wait more that two hours for updates and I don't have that much time right now.

Quote: The string is defined in single quotes, so the \n and \r each are treated as 2 characters, not the control character you expect.https://www.php.net/manual/en/language.types.string.php#language.types.string.syntax.single

I had not realized the new module code was doing this. Cool feature.

I've got a few thoughts.

Looks like we should be checking the CURLINFO_RESPONSE_CODE with curl_getinfo() to make sure the return is a 200. A lot of other codes can be returned with a valid json body that are totally different than the releases body. An example is the 403 response code for a rate limit exceded error -https://developer.github.com/v3/#rate-limiting

We might also consider a more precise end point, like this:
https://api.github.com/repos/XoopsModules25x/publisher/releases/latest

To be good github citizens, we should cache the results for some period of time so we don't generate hundreds of checks while doing publisher setup activities. The period could easily be an hour or more. Xmf\Module\Helper\Cache::cacheRead() could make that easy.

One last observation not directly related to this issue, since publisher can be cloned, it looks like this check will not get any data, or wrong data from another module.