Beiträge von Visvanath Ratnaweera

Nutzerbild von Particularly helpful Moodlers Nutzerbild von Translators

I did input this into the config.php and that worked. Uninstall button showed up next to essential plugin.

That is the clean method.

However, after deleting it and updating the database, essential theme was still there. Deleting Essential directory manually also gave the same response.

Yes, as you discovered telling Moodle that the theme is no more needed and removing the theme from the code tree are two separate steps. They need to be executed in that order, resp. after step 1 Moodle will tell you when to do step 2.

It seemed that the essential theme was being deleted and after updating the database, the theme was back. 

Do you say, Moodle "remembers" the code of the plug-in and dump it back?

What settings must I change  so that this theme does not come back? 

No "settings". It is the procedure described above.

Nutzerbild von Particularly helpful Moodlers Nutzerbild von Translators
I think you pointed to the cause:

> The mdl_events table has 443971 records, I think there is some event wrongly registered and hence the problems when activating those blocks in the dashboard,

So out of the three earlier:
>> whether your site has some special kind of (very intensive) calendar events or
>> there is something wrote wring with (your) Moodle - like a missing index or
>> the database is corrupted or there's a regression that was introduced in a version upgrade.
 
it is the first one. Right?
 
> I do not know how to find it
You expect us to find it? In your Moodle?
Nutzerbild von Particularly helpful Moodlers Nutzerbild von Translators

There are at least three things in the post, making it difficult to start.

  1. Service compromised (successful hacker attack)
  2. Fastcgi vs php-fpm
  3. Allowed memory exhausted

On 1. Security is a topic of its own, with a dedicated forum. My layman's approach is, take the compromised server immediately out of the network and start analyzing at the console.

To be sure that I understood you: A bad actor owned the Moodle login of a user who has the site administrator role AND also got his shell account and password to the Moodle machine and logged in?

On 2. For Moodle whether Fastcgi or php-fpm is transparent (from my experience) as long as they behave the way Moodle expect from LAMP.

On 3. Could be related to 2 or a new one. See for example 1 'Fatal error: Allowed memory size of ... bytes exhausted...'

I know, none of the above is specific. To be specific you need to provide more specific information. The starting point is Before you post.. read this.. Also get an overview of the various Moodle versions and their dependencies from this chart http://www.syndrega.ch/blog/#php-and-dbms-compatibility-of-major-moodle-releases. (Each version is linked to its Release notes, where you'll find the official notes.)

Nutzerbild von Particularly helpful Moodlers Nutzerbild von Translators
It also made me wondering what "the MySQL installation remains in the main partition and the files can be moved the new one" means.
 
Do you mean:
a) not to touch the MySQL data, which are typically in /var/lib? and
b) move the moodledata, say currently in /var/www, to a new partition?

The answer to a) is No! Not doing something doesn't make a change.
 
The answer to b) is possibly, if the new partition is faster than the current eg. /var/www. But by how much one can't say. moodledata is not one thing, it has subdirectories for all sorts of different purposes. Some have direct impact on the performance, others not.
Nutzerbild von Particularly helpful Moodlers Nutzerbild von Translators
Moodle:
$version  = 2022112813.00;
$release  = '4.1.13 (Build: 20240902)';
$branch   = '401';
$maturity = MATURITY_STABLE;

Before the upgrade:
$plugin->version = 2024013101;
$plugin->requires = 2021051700;
$plugin->component = 'filter_multilang2';
$plugin->release = '2.0.1';
$plugin->maturity = MATURITY_STABLE;

After the upgrade:
$plugin->version = 2024101201;
$plugin->requires = 2021051700;
$plugin->component = 'filter_multilang2';
$plugin->release = '2.0.3';
$plugin->maturity = MATURITY_STABLE;
 
But that upgrade blocked the whole site with the error in subject. So I moved the filter/multilang2 away and the site recovered. Happened yesterday. Another person reported it today. (The discussion linked in the OP.)