Does VersionX Optimize Storage work?

[rsdesign007]

When clicking on Optimize Storage in the VersionX Extra all the VersionX database table sizes get much larger, not smaller.

I've testing it on 2 different MODX websites with similar results.

Environments:
MODX Cloud, Nginx
MODX: 3.1.2-pl
VersionX: 3.2.1-pl
PHP Version: 8.3

and

MODX Cloud, Nginx
MODX: 3.0.4-pl
VersionX: 3.1.0-pl
PHP Version: 8.1

Step to reproduce:
Go to the Extras tab, then click on VersionX, then click on Optimize Storage.

Observed behavior:
All the versionX tables got larger. The modx_versionx_delta_field table in MODX 3.0.4 and VersionX 3.1.0 went from 585.6 MiB to 733.5 MiB.

Expected behavior:
Optimize Storage was expected to decrease storage space, not increase it.

I can't find any specific documentation to indicate if I am missing a step or setting.

Is Optimize Storage working in VersionX? If it does work, can anyone guide me to what step I am missing?

Thanks,

Chris
Rockstar Design

[muzzwood]

Huh.. It's certainly supposed to be working 😆
I wonder if there's an issue related to a recent change to one of the tables. It sounds like you're getting the new merged records but it's not removing the old ones.
Are you getting an relevant errors in the log?

[rsdesign007]

I checked the error log and did not see anything relevant.

I decided to update the MODX: 3.0.4-pl website to MODX: 3.1.2-pl, VersionX: 3.2.1-pl & PHP Version: 8.3 and tried the Optimize Storage button again. This time it did seem to work.

It lowered the modx_versionx_delta_field table from 733.5 MiB to 428.5 MiB this time after updating MODX, PHP and VersionX.

I can't explain why it did not work yesterday, but after updating it seems to work now.

Thank you for your help!

Chris

[rsdesign007]

I tried again today to OPTIMIZE STORAGE for VersionX on a different MODX Cloud website.

MODX Cloud, Nginx
MODX: 3.1.2-pl
VersionX: 3.2.1-pl
PHP Version: 8.3

The website is only 2.5 months old and created on Apr 05, 2025. Every Extra is updated to the latest.

I clicked the "Optimize Storage" button.

The modx_versionx_delta_field table started at 7.2 MiB before optimizing and went to 156 MiB after optimizing!?!

I did not see any errors referencing VersionX, or, any new errors at the time I clicked Optimize Storage.

• Does the "Optimize Storage" button work?
• Is there something not listed in the GitHub documentation that needs to be done?

Sorry, but I am trying to reduce and clean up the server DISK storage space used in MODX Cloud. The modx_versionx_delta_field database table became 20 times larger after optimizing.

I just want to understand the correct way to Optimize the database storage used by VersionX 3.2.1.

Thanks in advance for any help,

Chris

[muzzwood]

@rsdesign007 I haven't seen this happen before. Let me know if you are able to find any relevant errors in the logs that might serve as a clue.

The button is just a shortcut to the same methods the cron runs: https://github.com/modmore/VersionX/blob/3.x/core/components/versionx/cron.php

You could try running it from the command line.

[rsdesign007]

Hi muzzwood,

I tried to Optimize Storage again from clicking the Optimize Storage button in the VersionX Extra, but this time I cleared the error log first, so that I would know any errors were from Optimizing VersionX.

The error log immediately went from empty to 32.52 MiB. I needed to download the error log and open it in Notepad++.

I have a sample of the errors today below. I did not realize they may be from Optimizing VersionX yesterday.

HY000 appeared 124,420 times? Is that related to Optimizing VersionX?

Please let me know any advice on solving this.

[2025-06-26 13:15:57] (ERROR @ /www/core/vendor/xpdo/xpdo/src/xPDO/Om/xPDOObject.php : 1447) Error HY000 executing statement:
UPDATE modx_deprecated_call SET call_count = 5408409 WHERE id = 104
Array
(
[0] => HY000
[1] => 2014
[2] => Cannot execute queries while other unbuffered queries are active. Consider using PDOStatement::fetchAll(). Alternatively, if your code is only ever going to run against mysql, you may enable query buffering by setting the PDO::MYSQL_ATTR_USE_BUFFERED_QUERY attribute.
)

[2025-06-26 13:15:57] (ERROR @ /www/core/vendor/xpdo/xpdo/src/xPDO/Om/xPDOObject.php : 227) Error HY000 executing statement:
Array
(
[0] => HY000
[1] => 2014
[2] => Cannot execute queries while other unbuffered queries are active. Consider using PDOStatement::fetchAll(). Alternatively, if your code is only ever going to run against mysql, you may enable query buffering by setting the PDO::MYSQL_ATTR_USE_BUFFERED_QUERY attribute.
)

[2025-06-26 13:15:57] (ERROR @ /www/core/vendor/xpdo/xpdo/src/xPDO/Om/xPDOObject.php : 1447) Error HY000 executing statement:
INSERT INTO modx_session (id, access, data) VALUES ('hdh3437ktae5o5d6kcqro3g5q5', 1750943757, 'modx.user.0.resourceGroups|a:1:{s:3:"mgr";a:0:{}}modx.user.0.attributes|a:1:{s:3:"mgr";a:5:{s:32:"MODX\Revolution\modAccessContext";a:1:{s:3:"web";a:1:{i:0;a:3:{s:9:"principal";i:0;s:9:"authority";i:0;s:6:"policy";a:7:{s:4:"load";b:1;s:6:"formit";b:1;s:18:"formit_encryptions";b:0;s:8:"seosuite";b:1;s:17:"seosuite_tab_meta";b:1;s:16:"seosuite_tab_seo";b:1;s:19:"seosuite_tab_social";b:1;}}}}s:38:"MODX\Revolution\modAccessResourceGroup";a:0:{}s:33:"MODX\Revolution\modAccessCategory";a:0:{}s:44:"MODX\Revolution\Sources\modAccessMediaSource";a:0:{}s:34:"MODX\Revolution\modAccessNamespace";a:0:{}}}modx.user.contextTokens|a:1:{s:3:"mgr";i:1;}manager_language|s:2:"en";modx.mgr.user.token|s:52:"modx67f17bbc6d11e1.45452370_1685c560a701b33.31541852";modx.mgr.session.cookie.lifetime|i:0;modx.mgr.user.config|a:0:{}modx.user.1.userGroups|a:2:{i:0;i:1;i:1;i:2;}newResourceTokens|a:3:{i:0;s:23:"685c565a8b7cb6.86857999";i:1;s:23:"685c56dcea9461.68085733";i:2;s:23:"685d47c6cff521.19180504";}')
Array
(
[0] => HY000
[1] => 2014
[2] => Cannot execute queries while other unbuffered queries are active. Consider using PDOStatement::fetchAll(). Alternatively, if your code is only ever going to run against mysql, you may enable query buffering by setting the PDO::MYSQL_ATTR_USE_BUFFERED_QUERY attribute.
)

[2025-06-26 13:15:57] (ERROR @ Unknown0) PHP warning: session_write_close(): Failed to write session data using user defined save handler. (session.save_path: /tmp/sessions, handler: MODX\Revolution\modSessionHandler::updateTimestamp)

Thanks,

Chris

[muzzwood]

From those errors alone, it's hard to tell.
Sounds like that might be related to this: https://community.modx.com/t/site-error-log-grew-to-180-gb-related-to-xpdoobject-php/7737

Try setting the system setting log_deprecated to false.