I can not confirm. Saving is no problem.

@no-matter-0 Beta 1 is not released yet, so the system information in the desciption above is wrong.

Have you used a 4.0 nightly build? If so, from when? Or have you used a git clone and the current 4.0-dev branch?

Both current 4.0-dev branch and the current nighlies built from it have as version 4.0-beta1-dev, mind the "-dev" at the end, it means "in development phase to that version", i.e. Beta-1 will be the next release.

yes 4.0 nightly build beta 1 from https://developer.joomla.org/nightly-builds.html

@no-matter-0 Have you made a new, clean installation using that nightly build? or have you updated from a previous nightly build or alpha version using the Joomla Update component or any other method (e.g. just replacing the files, which would be wrong)?

If updated: This is not really supported yet. Updates will be supported between released versions as soon as Beta 1 will be releases. So your installation might be broken. In this case try again with a new installation, i.e. the nightly full package unpacked into an empty folder and making a new installation using an empty database, then test again and report back the result.

If not updated, i.e. clean new install: Please report back the database type (MySQL or MariaDB or PostgreSQL or very unlikely MS SQL Server) and the version, and the PHP version you use.

P.S.: I've updated the system information for you in this issue description so it's clear you used a 4.0-beta1-dev nightly build.

yes it was an update

@no-matter-0 I you have the time and the possibility, please test again with a new installation as I suggested in my previous comment and report back the result here. Thanks in advance.

@no-matter-0 Do you have an update on the suggestion by @richard67 ?

Set to "closed" on behalf of @jwaisner by The JTracker Application at issues.joomla.org/joomla-cms/27913

Closing due to no response to information requested. Please feel free to reopen when information is able to be provided.

I have experinced the same error - but it happens after having installed and uninstalled a third party component? Does that change something in the com_content table ??

I have no installed 0 component, only akeeba backup
that bug does not happen all the time ,I could not find when and why

still the same problem upgrading to beta 5

Have anyone solved this issue?
I have the same issue on Joomla 4.1.2

@machadoug New install of 4.12? Or updated from previous versions? If the latter: Please tell us the update history, i.e. if all updates were made with the Joomla Update Component without problems or if there were problems in past which had to be fixed manually somehow, and which versions.

P.S. And more details about in which cases it happens.

@richard67 Installed an earlier Joomla! version on localhost. I don't remember which version exactly, but probably 4.1.0, because it's the one in my Download folder. There were no errors when I upgraded to the current version. I have just recovered a backup from localhost and it's working correctly, so it was not a problem with the upgrade. I can't use this backup because it's a very outdated version of the production site.

We have moved the site to the production server using Akeeba Backup and since then no new articles or categories were created until today. Not sure this is related to Akeeba Backup, maybe @nikosdion can help?

@machadoug Having moved a 6Gb Joomla 4.1.2 site (our live site) from dev to production yesterday using Akeeba Backup I can tell you that no, this is not an Akeeba Backup issue.

Re-opening due to newly reported occurrence. But I don't really have an idea what could cause that.

@Hackwar As it's something with a finder table: Do you have an idea?

@richard67 Without having debugged this and off the top of my head, the first thing I would look is check if that table (#__finder_taxonomy) has a root node with id 1.

During the site transfer the taxonomy table contents were not transferred at all. In this case Component, Smart Search, Index, Index should reset it. Definitely running the indexer from the command line, which is what I did on my Joomla 4 site every time I transferred it between servers.

If my hunch is right, you can possibly reproduce this by deleting all contents of all finder tables. If this is the case, I think the best solution would be to check for an empty table and create the root node automatically. Finder table contents shouldn't be required to be backed up and restored, their information must always be reproducible (the reason we have the Finder plugins after all) and Finder should work right if all tables are dead empty, like it did on Joomla 3.

If that's not possible I can create a simple workaround in Akeeba Backup to create a dummy root node upon site transfer. That said, it really makes no sense to me to have to do that if Finder can index the site when this table is dead empty.

Clicked on Component > Smart Search > Index and I get the same error, so I cleared the Index, Indexed again without errors and I was able to save the new article.

Thank you all

Clicked on Component > Smart Search > Index and I get the same error, so I cleared the Index, Indexed again without errors and I was able to save the new article.

This confirms what @nikosdion wrote.

Thank you all

@machadoug Am happy it works for you.

If my hunch is right, you can possibly reproduce this by deleting all contents of all finder tables. If this is the case, I think the best solution would be to check for an empty table and create the root node automatically. Finder table contents shouldn't be required to be backed up and restored, their information must always be reproducible (the reason we have the Finder plugins after all) and Finder should work right if all tables are dead empty, like it did on Joomla 3.

@Hackwar I think @nikosdion 's point is right and the finder should handle this. Do you agree, and if so, could work on it?

@machadoug Thanks! Now I can confirm that the problem is that the #__finder_taxonomy table is empty.

@richard67 I may be the one being wrong here.

The #__finder_taxonomy table is not one of the Finder tables which automatically toggles between InnoDB and Memory engines. I had made a wrong assumption, thinking that if it's a memory table Finder expects it to be fully empty. I will add a workaround to Akeeba Backup to create a dummy root node when restoring a site.

I also think it should be documented somewhere that if you get this kind of issues saving any content you should go to Component, Smart Search, Index and reset the index. It's a non-obvious fix but if it's documented at least we can point people to it.

And a final note as I am going through all the code in Akeeba Backup. Actually, I had fixed that problem since June 4th, 2020 in Akeeba Backup. I actually see in my Git log that it was part of the Joomla 4 fixes I was making at that time. It's been a long time, I had forgotten about it.

When you do take a backup and have enabled the option to exclude Finder data from the backup I do add a line of SQL code in the database dump to create the root node in the taxonomy table. This line is executed on restoration.

So... why did that table end up completely empty on these two sites? I don't know, assuming they were using a version of Akeeba Backup newer than 7.2.0 (the first version where this fix was included).

@nikosdion Thanks for the info.

@machadoug Have you maybe used an older version than 7.2.0 of Akeeba Backup?

@richard67 I've used pkg_akeebabackup-9.2.1-core.zip. However, I haven't enabled the option to exclude Finder data from the backup, unless it's enabled by default.

@machadoug It's enabled by default. Can you do a test restoration on a blank database and tell me if the #__finder_taxonomy table has a single root record after the restoration is complete?

@nikosdion Yes, it has a single root record after restoration.

@machadoug OK, that's identical to what Joomla creates when you reset the index (I double-checked). Can you create an article on that restored site?

@nikosdion Article saved without problems, so it most likely is not related to the website restoration. I'm still not sure what caused it. After restoration, I only installed Akeeba AdminTools and JCH Optimizer, but I don't think any of those two have anything to do with that error.

@machadoug Thank you for the confirmation, it tracks my own findings. It's always good to have external corroboration.

I guess something deleted the contents of the #__finder_taxonomy table or otherwise corrupted it. It wasn't Joomla, it wasn't my extension, I don't think it was JCH Optimiser (it does nothing of the sort)... Dunno. I will take a page of the BOFH's calendar and say "it must have been the solar flares".

So what remains to be done is maybe a 4.x FAQ doc at https://docs.joomla.org about fixing it with clearing and creating again the smart search index. Unfortunately I'm not really familiar with our docs wiki, and I don't know when I have time for that. But I'll see what I can do.

Closing as not a core issue.

I want to point out that it is actually NOT advised to exclude the finder tables from a backup. While finder can recreate the default data, which is in the index, it can't restore custom filters, deleted or hidden entries of the index, etc. So you would have to do all customisations each time again after restoring a backup. In the end, we are acting on autoincrement IDs here and reseting the index does not guarantee, that you get the same IDs again. Please also notice, that you can't just keep the taxonomy table, since the finder might run an optimisation step anywhere in the future, clearing out all taxonomies which have no associated entries in the link table.

If you want to do this safely, but downsize the size of the backup, you can keep out the #__finder_links_terms and #__finder_terms table and from the #__finder_links table you can drop the md5sum and object column. That will mean that you still have to click the index button in the backend after restoration, but all IDs would be preserved and since the MD5 hashes are gone and thus they would not be equal to the objects compiled on indexing, the object column, terms and the mapping would be restored correctly. That should save around 98% of the space necessary for finder in a backup. @nikosdion

Thank you @Hackwar for the insight. I will modify the backup code to work like that.

@Hackwar Can I ask a related, hopefully stupid question, please.

If the contents of #__finder_tokens and #__finder_tokens_aggregate are critical, why are these tables MEMORY tables until they read the memory_table_limit? This means that every time the database server restarts their contents are lost as per the MySQL documentation.

Also, I see that on my site I ended up with several dozens of thousands of tokens. Not excluding these tables does slow down the backup appreciably since MySQL's response time is dominated by the number of records we have to dump (and I say it's MySQL because you notice the same performance impact with mysqldump and phpMyAdmin, i.e. it's not a unique characteristic of my code).

Thank you in advance!

Oh never mind, my eyes are tired. I was looking at the terms tables, not the token tables.

I'm sorry, my last comment was not detailed enough. Indeed, the #__finder_tokens and #__finder_tokens_aggregate are not necessary. Those should be empty anyway as long as you aren't indexing right now. Those tables are kept as memory tables as long as they don't run the risk of running full. The idea is, that we are adding each and every word in the text to the finder_tokens table and then later calculate the weights of the terms by adding the single weights, etc. Then we look up which terms/tokens are already in our system and only add those we need. To make that faster, we are using Memory tables here. If the text is too big, we switch those tables to innodb to prevent failures. So this only happens when the text is very long.

The terms table can be restored, parts of the link table as well and the tokens and tokens_aggregate should be empty anyway.

Thanks! That's what I saw running a couple of test indexes, backups and restorations. Having this confirmed makes me more confident I am on the right track now :)

I'll make a new release towards the middle next week — this Sunday is the Orthodox Easter, I am taking five days off after nearly two and a half years of non-stop work.

I am taking five days off after nearly two and a half years of non-stop work.

Good decision. I need to do that, too. And a lot more often than once every 2.5 years.

Amen to that!