SuiteCRM 8.9.1 corrupted?

rsp · 4 December 2025 15:25

Do you have any custom code or add-on?

pgr · 4 December 2025 15:26

Search that string with a “find in files” or grep -irn

You will likely find it in more than one place, one that is the input of a Quick Repair and Rebuild, the other is the output. You need to change the input.

mrak · 4 December 2025 16:52

So, I moved everything to a completely new machine and I have some interesting conclusions:

I made clean install on completely new computer instance, this version worked correctly
I restored database to new database and basically just replaced the database in confing files - this also works correctly with a caveat that configuration of my subpanels was not transfered and labels of my custom fields did not exist (so I could see “default” data, but not my customizations)
I have then tried to decide which files from my old custom folder I need to copy to the new instance. I do not understand custom folder fully to have a smart decision on what to copy or not so in the end I copied whole custom folder and when I did that my whole instance broke in exactly the same way like my old machine
so now we know that whatever happened, happened in my custom folder

Thankfully, if I remove custom folder and rebuild cache, it starts working again (although not all custom files are there).

Is there any documentation about the anatomy of custom folder and what is safe to copy/remove or not?

(I am interested to learn where are located custom modules, where is kept information about custom fields and subpanel/screen cofiguration - most of my custom work was done within Contacts module).

rsp · 4 December 2025 16:58

That’s interesting. Same custom files were working in 8.8.1 for you.

What if you move all folder from custom except the modules one? If that work, then we know it is an issue with modules folder.

pgr · 4 December 2025 22:13

What is not safe to copy or remove in custom folder?

The reference to media_objects that is causing a Fatal error - fix that and all your systems (old and new) should be operational again.

mrak · 5 December 2025 08:07

Yes, I removed modules directory from customs and everything appears to work.

The trick is that all of my studio customizations are there. So now I have to add module by module back to see which one breaks the install. Interesting.

pgr · 5 December 2025 12:46

I don’t think you need to do all that guesswork… you can follow the specific clues you have

What do you get when you run this from the SuiteCRM directory?

grep -irn media_objects .

mrak · 5 December 2025 13:27

ZERO

but, media_objects are mentioned in plenty of other places:

./public/legacy/include/portability/Schedulers/PruneDatabaseService.php:46: ‘archived_documents_media_objects’ => ‘ArchivedDocumentMediaObject’,
./public/legacy/include/portability/Schedulers/PruneDatabaseService.php:47: ‘private_documents_media_objects’ => ‘PrivateDocumentMediaObject’,
./public/legacy/include/portability/Schedulers/PruneDatabaseService.php:48: ‘private_images_media_objects’ => ‘PrivateImageMediaObject’,
./public/legacy/include/portability/Schedulers/PruneDatabaseService.php:49: ‘public_documents_media_objects’ => ‘PublicDocumentMediaObject’,
./public/legacy/include/portability/Schedulers/PruneDatabaseService.php:50: ‘public_images_media_objects’ => ‘PublicImageMediaObject’,
./public/legacy/include/portability/Schedulers/PruneDatabaseService.php:51: ‘media_objects’ => ‘MediaObject’,
./public/legacy/cache/Relationships/relationships.cache.php:15004: ‘rhs_table’ => ‘public_images_media_objects’,
./public/legacy/cache/Relationships/relationships.cache.php:15015: ‘rhs_table’ => ‘public_images_media_objects’,
./public/legacy/cache/Relationships/relationships.cache.php:15026: ‘rhs_table’ => ‘public_images_media_objects’,
./public/legacy/cache/Relationships/relationships.cache.php:15037: ‘rhs_table’ => ‘public_images_media_objects’,
./public/legacy/cache/modules/Relationships/relationships.cache.php:771: ‘rhs_table’ => ‘archived_documents_media_objects’,
./public/legacy/cache/modules/Relationships/relationships.cache.php:3678: ‘rhs_table’ => ‘archived_documents_media_objects’,
./public/legacy/cache/modules/Relationships/relationships.cache.php:5863: ‘rhs_table’ => ‘archived_documents_media_objects’,
./public/legacy/cache/modules/Relationships/relationships.cache.php:7364: ‘rhs_table’ => ‘archived_documents_media_objects’,
./public/legacy/cache/modules/MediaObjects/ArchivedDocumentMediaObjectvardefs.php:3: ‘table’ => ‘archived_documents_media_objects’,
./public/legacy/cache/modules/MediaObjects/ArchivedDocumentMediaObjectvardefs.php:284: ‘rhs_table’ => ‘archived_documents_media_objects’,
./public/legacy/cache/modules/MediaObjects/ArchivedDocumentMediaObjectvardefs.php:294: ‘rhs_table’ => ‘archived_documents_media_objects’,
./public/legacy/cache/modules/MediaObjects/ArchivedDocumentMediaObjectvardefs.php:304: ‘rhs_table’ => ‘archived_documents_media_objects’,
./public/legacy/cache/modules/MediaObjects/ArchivedDocumentMediaObjectvardefs.php:314: ‘rhs_table’ => ‘archived_documents_media_objects’,
./public/legacy/cache/modules/MediaObjects/PrivateDocumentMediaObjectvardefs.php:3: ‘table’ => ‘private_documents_media_objects’,
./public/legacy/cache/modules/MediaObjects/PrivateDocumentMediaObjectvardefs.php:284: ‘rhs_table’ => ‘private_documents_media_objects’,
./public/legacy/cache/modules/MediaObjects/PrivateDocumentMediaObjectvardefs.php:294: ‘rhs_table’ => ‘private_documents_media_objects’,
./public/legacy/cache/modules/MediaObjects/PrivateDocumentMediaObjectvardefs.php:304: ‘rhs_table’ => ‘private_documents_media_objects’,
./public/legacy/cache/modules/MediaObjects/PrivateDocumentMediaObjectvardefs.php:314: ‘rhs_table’ => ‘private_documents_media_objects’,
./public/legacy/cache/modules/MediaObjects/PrivateImageMediaObjectvardefs.php:3: ‘table’ => ‘private_images_media_objects’,
./public/legacy/cache/modules/MediaObjects/PrivateImageMediaObjectvardefs.php:284: ‘rhs_table’ => ‘private_images_media_objects’,
./public/legacy/cache/modules/MediaObjects/PrivateImageMediaObjectvardefs.php:294: ‘rhs_table’ => ‘private_images_media_objects’,
./public/legacy/cache/modules/MediaObjects/PrivateImageMediaObjectvardefs.php:304: ‘rhs_table’ => ‘private_images_media_objects’,
./public/legacy/cache/modules/MediaObjects/PrivateImageMediaObjectvardefs.php:314: ‘rhs_table’ => ‘private_images_media_objects’,
./public/legacy/cache/modules/MediaObjects/PublicDocumentMediaObjectvardefs.php:3: ‘table’ => ‘public_documents_media_objects’,
./public/legacy/cache/modules/MediaObjects/PublicDocumentMediaObjectvardefs.php:284: ‘rhs_table’ => ‘public_documents_media_objects’,
./public/legacy/cache/modules/MediaObjects/PublicDocumentMediaObjectvardefs.php:294: ‘rhs_table’ => ‘public_documents_media_objects’,
./public/legacy/cache/modules/MediaObjects/PublicDocumentMediaObjectvardefs.php:304: ‘rhs_table’ => ‘public_documents_media_objects’,
./public/legacy/cache/modules/MediaObjects/PublicDocumentMediaObjectvardefs.php:314: ‘rhs_table’ => ‘public_documents_media_objects’,
./public/legacy/cache/modules/MediaObjects/PublicImageMediaObjectvardefs.php:3: ‘table’ => ‘public_images_media_objects’,
./public/legacy/cache/modules/MediaObjects/PublicImageMediaObjectvardefs.php:284: ‘rhs_table’ => ‘public_images_media_objects’,
./public/legacy/cache/modules/MediaObjects/PublicImageMediaObjectvardefs.php:294: ‘rhs_table’ => ‘public_images_media_objects’,
./public/legacy/cache/modules/MediaObjects/PublicImageMediaObjectvardefs.php:304: ‘rhs_table’ => ‘public_images_media_objects’,
./public/legacy/cache/modules/MediaObjects/PublicImageMediaObjectvardefs.php:314: ‘rhs_table’ => ‘public_images_media_objects’,
./public/legacy/modules/MediaObjects/vardefs.php:79: ‘table’ => ‘archived_documents_media_objects’,
./public/legacy/modules/MediaObjects/vardefs.php:94: ‘table’ => ‘private_documents_media_objects’,
./public/legacy/modules/MediaObjects/vardefs.php:109: ‘table’ => ‘private_images_media_objects’,
./public/legacy/modules/MediaObjects/vardefs.php:124: ‘table’ => ‘public_documents_media_objects’,
./public/legacy/modules/MediaObjects/vardefs.php:139: ‘table’ => ‘public_images_media_objects’,
./public/legacy/modules/MediaObjects/PublicImageMediaObject.php:35: public $table_name = ‘public_images_media_objects’;
./public/legacy/modules/MediaObjects/PrivateDocumentMediaObject.php:35: public $table_name = ‘private_documents_media_objects’;
./public/legacy/modules/MediaObjects/ArchivedDocumentMediaObject.php:35: public $table_name = ‘archived_documents_media_objects’;
./public/legacy/modules/MediaObjects/MediaObject.php:34: public $table_name = ‘media_objects’;
./public/legacy/modules/MediaObjects/PublicDocumentMediaObject.php:35: public $table_name = ‘public_documents_media_objects’;
./public/legacy/modules/MediaObjects/PrivateImageMediaObject.php:35: public $table_name = ‘private_images_media_objects’;
./core/backend/Schedulers/Service/Scheduler/Jobs/CleanUpTemporaryFilesScheduler.php:63: ‘archived-documents’ => ‘archived_documents_media_objects’,
./core/backend/Schedulers/Service/Scheduler/Jobs/CleanUpTemporaryFilesScheduler.php:64: ‘private-documents’ => ‘private_documents_media_objects’,
./core/backend/Schedulers/Service/Scheduler/Jobs/CleanUpTemporaryFilesScheduler.php:65: ‘private-images’ => ‘private_images_media_objects’,
./core/backend/Schedulers/Service/Scheduler/Jobs/CleanUpTemporaryFilesScheduler.php:66: ‘public-documents’ => ‘public_documents_media_objects’,
./core/backend/Schedulers/Service/Scheduler/Jobs/CleanUpTemporaryFilesScheduler.php:67: ‘public-images’ => ‘public_images_media_objects’
./core/backend/MediaObjects/Entity/PublicImageMediaObject.php:48:#[ORM\Table(name: ‘public_images_media_objects’)]
./core/backend/MediaObjects/Entity/PrivateDocumentMediaObject.php:48:#[ORM\Table(name: ‘private_documents_media_objects’)]
./core/backend/MediaObjects/Entity/ArchivedDocumentMediaObject.php:47:#[ORM\Table(name: ‘archived_documents_media_objects’)]
./core/backend/MediaObjects/Entity/PublicDocumentMediaObject.php:48:#[ORM\Table(name: ‘public_documents_media_objects’)]
./core/backend/MediaObjects/Entity/PrivateImageMediaObject.php:48:#[ORM\Table(name: ‘private_images_media_objects’)]
./cache/prod/doctrine/orm/default_metadata.php:334: ‘name’ => ‘archived_documents_media_objects’,
./cache/prod/doctrine/orm/default_metadata.php:691: ‘name’ => ‘private_documents_media_objects’,
./cache/prod/doctrine/orm/default_metadata.php:1048: ‘name’ => ‘private_images_media_objects’,
./cache/prod/doctrine/orm/default_metadata.php:1405: ‘name’ => ‘public_documents_media_objects’,
./cache/prod/doctrine/orm/default_metadata.php:1762: ‘name’ => ‘public_images_media_objects’,
./logs/legacy/suitecrm.log:6:Wed Dec 3 2025 at 10:17:10 [56818][1][FATAL] createRelationshipMeta: Metadata for table media_objects does not exist
./logs/legacy/suitecrm.log:7:Wed Dec 3 2025 at 10:32:04 [56818][1][FATAL] createRelationshipMeta: Metadata for table media_objects does not exist
./logs/legacy/suitecrm.log:8:Wed Dec 3 2025 at 10:32:08 [102911][1][FATAL] createRelationshipMeta: Metadata for table media_objects does not exist
./logs/legacy/suitecrm.log:9:Wed Dec 3 2025 at 10:32:12 [102937][1][FATAL] createRelationshipMeta: Metadata for table media_objects does not exist
./logs/legacy/suitecrm.log:7765:Thu Dec 4 2025 at 16:45:17 [311497][1][FATAL] createRelationshipMeta: Metadata for table media_objects does not exist
./logs/legacy/suitecrm.log:7780:Thu Dec 4 2025 at 16:49:31 [311488][1][FATAL] createRelationshipMeta: Metadata for table media_objects does not exist
./logs/legacy/suitecrm.log:8274:Fri Dec 5 2025 at 08:05:21 [316131][1][FATAL] createRelationshipMeta: Metadata for table media_objects does not exist
./logs/install.log:558:[2025-12-336 14:16:57] install.FATAL: create_tables: Metadata for table media_objects does not exist
./logs/install.log:559:[2025-12-336 14:16:57] install.FATAL: createRelationshipMeta: Metadata for table media_objects does not exist
./logs/install.log:563:[2025-12-336 14:17:08] install.FATAL: createRelationshipMeta: Metadata for table media_objects does not exist
./logs/install.log:874:[2025-12-02 14:17:09] install.INFO: processing table media_objects
./logs/install.log:875:[2025-12-02 14:17:09] install.INFO: creating table media_objects
./logs/install.log:877:[2025-12-02 14:17:09] install.INFO: processing table archived_documents_media_objects
./logs/install.log:878:[2025-12-02 14:17:09] install.INFO: creating table archived_documents_media_objects
./logs/install.log:880:[2025-12-02 14:17:09] install.INFO: processing table private_documents_media_objects
./logs/install.log:881:[2025-12-02 14:17:09] install.INFO: creating table private_documents_media_objects
./logs/install.log:883:[2025-12-02 14:17:09] install.INFO: processing table private_images_media_objects
./logs/install.log:884:[2025-12-02 14:17:09] install.INFO: creating table private_images_media_objects
./logs/install.log:886:[2025-12-02 14:17:09] install.INFO: processing table public_documents_media_objects
./logs/install.log:887:[2025-12-02 14:17:09] install.INFO: creating table public_documents_media_objects
./logs/install.log:889:[2025-12-02 14:17:09] install.INFO: processing table public_images_media_objects
./logs/install.log:890:[2025-12-02 14:17:09] install.INFO: creating table public_images_media_objects

If I understand everything right, all of this was introduced with 8.9?

But, this also means that my case is unrelated to this.

rsp · 5 December 2025 14:28

Yeah, it is part of v8.9.1

Use correct quotes (make sure you’re using correct curly quotes)

‘media_objects’ => ‘MediaObject’

Delete these folders:

rm -rf public/legacy/cache/*
rm -rf cache/*

Then run:

php bin/console cache:clear

run Quick Repair & Rebuild

What is you create that table manually?

creating table media_objects

CREATE TABLE `media_objects` (
  `id` char(36) NOT NULL,
  `name` varchar(255) DEFAULT NULL,
  `file_ext` varchar(10) DEFAULT NULL,
  `mime_type` varchar(100) DEFAULT NULL,
  `filename` varchar(255) DEFAULT NULL,
  `created_at` datetime DEFAULT NULL,
  `updated_at` datetime DEFAULT NULL,
  `deleted` tinyint(1) NOT NULL DEFAULT 0,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

pgr · 5 December 2025 15:42

Ok, so it’s a new addition to core SuiteCRM.

The Quick Repair and Rebuild typically detects inconsisitencies between vardefs and DB, and if you scroll down, at the bottom it offers a button to fix this (run SQL like the one @rsp provided). Have you seen/tried that?

mrak · 5 December 2025 17:09

quick repair did not detect this or did not report it

All of this fixes did not solve my issue at all, so what I did do is that I have started moving directory by directory from my backup to legacy/custom/modules

I have moved about half of my modules and will try to the same with the rest tomorrow.

(it is slow because I need to reset chmod and chown + cache every time I do something)

Interestingly, when I break my suitecrm instance, the moment I remove custom modules it returns to default suitecrm state (no cache purge needed, menues return with first refresh)

pgr · 5 December 2025 17:27

The custom stuff is not just in /custom directory.

Stuff coming from Module builder goes in /modules (I wish it didn’t! The proper place would be /custom/modules)

If you still see a FATAL error in your logs when it breaks, you could try getting a proper stack trace of it; that, and a bit extra logging, would take you directly to the offending file.

mrak · 8 December 2025 12:57

I have (finally) figured out WHERE this corruption is happening.

It happens in:

/var/www/suitecrm/public/legacy/custom/modules/Emails

As soon as I remove Emails directory, my navigation returns immediately (but this custom/module directory gets recreated quite soon).

It took me some time to this figure out (waaay too much time). Once we determined that something there is creating an issue I tried removing all content and adding parts of the code one by one and I thought everything is fine but after some time user interface would fail again (and I can not say that this is related to cache issues, I have reset everything I know including my browser cache; made whole script just to reset everything properly after any change).

In the end, I found problematic module by looking at time stamps of the files (and the latest changes were in Emails module).

Now, the thing is that I haven’t changed anything in Emails, and whatever happened there was automaticaly generated. I don’t have a clue why or how it happened.

As a precaution I have deleted outbound email accounts and recreated them from zero. I will monitor everything closely to see if everything continues to work ok.

p.s. now I know: if I go to studio and try to change something in views of Emails module (for example width of columns in list view) and try to Save&Deploy, it will create file in folder: /var/www/suitecrm/public/legacy/custom/modules/Emails/metadata/listviewdefs.php and this will break the suitecrm

rsp · 8 December 2025 14:38

You should have same files in the Email folder.

Do you need to edit email module from studio?

mrak · 8 December 2025 15:03

What I wanted to do is to adjust widths of columns in my list view, and for this I needed studio.

By default all columns are set to be 32% (total of about 170%) and in my case even short email subject ends up being three lines and then whole list is cumbersome to navigate. I really do not care for this module (at this time), but it looked like a simple thing to do and it crashed whole instance.

rsp · 8 December 2025 15:29

You’re correct. I changed the width for subject in list view of Email module from the Studio and it broke the system.

public/legacy/custom/modules/Emails/metadata

  'SUBJECT' =>
  array (
    'width' => '44%',
    'label' => 'LBL_LIST_SUBJECT',
    'default' => true,
    'link' => false,
    'customCode' => '',
    'sortable' => false,
  ),

I reset permissions and clear symfony cache and it did not fix it.

How can I fix my instance?

mrak · 8 December 2025 15:32

remove this file:

/var/www/suitecrm/public/legacy/custom/modules/Emails/metadata/listviewdefs.php

(this is path on my server, yours might be different)

rsp · 8 December 2025 15:34

Yes! I removed metadata folder and it is working now.

Could you please raise an issue on GitHub?

Thank you!

github.com/SuiteCRM/SuiteCRM-Core

Editing field properties in list view of Emails module (from Studio) results in fully crashed SuiteCRM instance

opened 03:54PM - 08 Dec 25 UTC

markorakar

Type: Bug

### Issue If you decide to reset or manually change widths of individual fields… within Emails module (and you do that from Studio), it will crash your instance. Crash is manifested in total loss of navigation menus (blanked out) as well as missing labels on forms and views. This bug can be easily reproduced (and was reproduced on separate and unrelated installs). **It appears that it is only related to Emails module.** **Special problem is that suitecrm does not report or record error in any of the logs**, which makes it extremly difficult to track and find and resolve (took me 8 days to figure it out). ### Possible Fix Manual fix is to delete **/var/www/suitecrm/public/legacy/custom/modules/Emails/metadata/listviewdefs.php** (this is location of listviewdefs.php on my instance, yours might be different). Long term fix is to find what exactly goes wrong in listviewdefs.php file and fix the logic that generates this file. ### Steps to Reproduce the Issue ```bash 1. go to SuiteCRM Studio 2. go to Email module 3. select "Layouts" and then "List View" 4. Change width of any field (or simply select "Restore Default") 5. Press "Save&Deploy" and your suiteCRM instance crashes (in the sense that ALL navigation is gone, as well as field lables through the instance in the case you know how to manually navigate) ``` ### Context I was trying to adjust widths of fields in Emails list view, so that my Subject filed will not be broken down in couple of lines. If you add up all percentages of all of the possible fields, it sums up to about 170%. ### Version 8.9.1 ### What browser are you currently using? Firefox ### Browser Version _No response_ ### Environment Information MariaDB (same problem with ver 10 and ver 11) ### Operating System and Version Debian 12 and Ubuntu 24.04