First, try this:

https://elgg.org/discussion/view/3028891/suddenly-unable-to-login-to-elgg-account-nobody-is-able-to-login

https://elgg.org/discussion/view/3052941/cannot-login-fresh-install

wp-login.php is most likely from a Wordpress installation. So, have you also installed Wordpress on your server? If yes, what might you have recently changed in Wordpress? Maybe a .htaccess file of Wordpress (main domain as opposed to Elgg in subfolder or subdomain) redirects to the Wordpress login but then fails. Or are you using some plugin that combines Wordpress and Elgg accounts / authentification? Maybe that no longer works for some reason.

Thank you Nikolai and  iionly.

The problem is with one plugin that is under development recently.

I believe I'll fix it soon.

Thanks a lot. 

In my case the symlink is not broken. Before I click "Flush the caches" I see the content of views_simplecache there. When I flush the caches the content of views_simplecache is cleared and  the symlink folder (cache) is cleared as well. No folder is removed or created.

The problem is that after flushing, all the web design (css) disappears and the system does not rebuild it as usual.

Does the cached files (CSS etc.) gets recreated if you visit other pages of your site after you flushed the cache? It might be that the admin dashboard page is not correctly fully rebuild after you flush the cache (might be an Elgg 2.x issue already fixed in newer versions of Elgg).

The other reason might be what I already mentioned in my last post. The webserver does not run as the same user you are usually logged in on your server (I'm not taking here about the Elgg site user but the user account you use to administrate your webspace). The user account name of the webserver might be "www" or "apache" or something different depending on the webhoster, the OS used etc.. Now the webserver might be configured to follow symbolic links only if the links themselves are owned by the user account the webserver runs as (or the webserver might read files but not write anything at the target location of the link). That why I linked to the docs in the previous posting. There's the commands

cd /path/to/wwwroot/
chown -h wwwrun:www cache

posted there. The "chown -h" command would make the webserver the owner of the symbolic link. For the command to work you would have to be logged in as root or you probably can't change the owner. Before useing the command you need to find out the user name and group name the webserver runs under. You should be able to find this out if you make a "ls -l" on some newly created file in the data directory that has been created by the webserver (on your new server).

Yes, it was the ownership issue. Now it works fine.

Thank you iionly for your detailed response... and for your patience :)

BTW, the permissions of /private was 0751 (rwxr-x--x). It should be good enough - I think?

Use 0750  as the docs recommends:

chmod -R 750 /private

I disabled the caches -> Flush the caches -> enabled the caches.

Now it works fine. Why? I do not know :)

Thank you

I think Jerome might have mixed up the history of changes of the Elgg log and Logrotate plugin. The option to delete archived log tables via cron was indeeed added before Elgg 3 already. But I think it never worked on Elgg 2. On Elgg 3 the Logrotate plugin was merged with the formerly Elgg core functionality of the Elgg log stuff into the new bundled System_log plugin. If I remember correctly, the deletion of archived tables still didn't work at the beginning but was then fixed at some point in some Elgg 3.x version. As Elgg 2 was already in LTS mode at that time it wasn't fixed in Elgg 2 anymore though (as Elgg 2 would now get only security related fixes).

As Jerome mentioned, you can simply delete the archived log tables from the database (e.g. with PhpMyAdmin). Just do NOT delete the Elgg log table as Elgg needs this table to be present to work!

You might have asked yourself for what you would need the Elgg log entries at all. If your answer is the same as mine (I NEVER needed the Elgg log table entries in more than 10 years even once!), you could consider using the No Logging plugin (https://elgg.org/plugins/1441338).

The No logging plugin stops new entries being added to the log table. After the log rotate cronjob had been run twice (or once if you select a shorter interval at the right time) the log table will contain 0 entries and no new entries are added. If this is the case, you can deactivate the Logrotate plugin as it has no purpose anymore, delete any archived log tables from the database and there won't be any new archived tables created as long as you have the Logrotate plugin disabled (which you wouldn't need when the No Logging plugin keeps new Elgg log entries from being added to the database).

As I said, do NOT delete the log table even then as Elgg would still stumble about the table missing even with no new entries being added to that table.

The Garbagecollector plugin is something different and has nothing to do with the logs. The garbagecollector cronjob added by the Garbagecollector plugin optimizes the tables of the database and removes certain entries no longer in use to keep the database smaller.

Thank you iionly.

I'll follow your detailed and clear explanation and let the the archive tables disappear.

Thank you iionly.

I'll follow your detailed and clear explanation and let the the archive tables disappear.