System Info:
- Theme: X Theme (Validated)
- PHP Version: 8.3.33
- Memory Limit: 512M
Issue Description: I am trying to update the bundled Essential Grid plugin from version 3.1.12 to 3.2.0 via the standard WordPress updates dashboard. The update process completes without any critical errors and says it was successful, but the plugin immediately reappears in the pending updates list, still showing as version 3.1.12.
Troubleshooting already done:
- Cleared all WordPress transients and object caches.
- Theme validation is active and functioning.
- Crucial Finding: I checked the plugin files via FTP immediately after running the update. The modification dates on all Essential Grid files update to the exact timestamp of the update attempt.
This confirms my server is successfully downloading, unpacking, and overwriting the files from your API. It strongly suggests that the .zip file currently being served by Themeco for this update is either still packing the 3.1.12 code, or the header in essential-grid.php was not bumped to 3.2.0 before packaging.
Additional Note (Logs): During the update attempts, the server logs the following PHP Warning. I am aware this is likely unrelated to the update loop itself, but I am sharing it as it points to a PHP 8.3 strictness issue with Cornerstone during the update-core.php process:
PHP Warning: Unable to check if classic mode is enabled this early in /var/www/vhosts/anitamanezphotography.es/webos/wp-content/plugins/cornerstone/includes/classes/Services/ThemeManagement.php on line 85
Could you please verify the Essential Grid 3.2.0 package currently deployed on your update servers?
PS: I understand asking to disable plugins is standard troubleshooting protocol. However, I can confidently rule out a plugin conflict in this specific scenario.
As I mentioned before, the file modification dates for the Essential Grid files on my server update exactly to the second when I run the update. If a plugin conflict were interfering with update-core.php , the process would fail, time out, or throw a fatal error before the files could be written.
Since the server is successfully downloading, extracting, and overwriting the plugin files without interruption, the mechanism is working perfectly. The only reason it still shows version 3.1.12 after a successful overwrite is because the payload itself—the .zip file being delivered by the Themeco API—either contains the old code or has an outdated version header.
Could you please escalate this to the development or deployment team so they can inspect the actual .zip package currently assigned to the 3.2.0 update on your servers?
Thank you.
