ExtraFields - after update to 2.0.7 all fields are gone

wwdesign · July 1, 2025, 3:18pm

Hello,

First of all, a big thank you for developing the ExtraFields extra – it’s a fantastic tool that we really appreciate!

We recently ran into a small issue while updating to version 2.0.7. As we normally keep our extras up to date, we proceeded with the upgrade. However, after the update, all the custom fields disappeared, as shown in the screenshot below:

Interestingly, the tabs remained intact, which makes the issue even more puzzling.

Has anyone else experienced this problem?
Any advice would be greatly appreciated!

thanks guyz!

halftrainedharry · July 1, 2025, 8:22pm

When you open the developer tools in the browser, go to the “Network” tab and then click the “Refresh” button (↻) under the grid (shown in your screenshot), a new (AJAX) request should appear in the list.

Is this request successful (status = 200)?
If not, what is the response and the response status code of this request?

What versions of MODX and PHP are you using?

wwdesign · July 2, 2025, 9:46am

Thanks for replying to this.

Please see below:

It seems like that AJAX call is fine as it return 200 but the return is an empty array.

I’m using MODX * 3.1.2-pl.

thanks!

halftrainedharry · July 2, 2025, 10:59am

Does an error message get added to the MODX error log when you try to reload the data?

I get a

Unknown column 'efField.field_index' in 'field list'

message when testing. It seems a new field field_index got added to the class efField, that maybe didn’t get correctly added to the database table modx_ef_fields on upgrade.

If you get the same error message, can you check if the database table modx_ef_fields has the column field_index?

(There is also a field precision that seems to have been added recently to the class efField.)

wwdesign · July 2, 2025, 11:27am

Please see below list of errors:

These errors are from yesterday (development site) as i was testing this on development server and it did not work.
I have been updating and restoring this extra few times today and it work after third or fourth test - which is very weird… I was very positive, however i tried on live site and it didint worked.

Regarding database field:

on development site i have field_index & precision columns as per below. Not sure why out of the sudden after few attempts.

devdb1609×913 119 KB
on the live site there is a field_index but there is no precison table as per below:

livedb1572×894 200 KB

thanks

halftrainedharry · July 2, 2025, 12:06pm

There is a resolver in the ExtraFields package that should add the missing columns to the database table during an update:

github.com/Boshnik/ExtraFields

_build/resolvers/tables.php

fb842686e


      
          $c = $modx->prepare("SHOW COLUMNS IN {$modx->getTableName($class)}");
          $c->execute();
          while ($cl = $c->fetch(PDO::FETCH_ASSOC)) {
              $tableFields[$cl['Field']] = $cl['Field'];
          }
          foreach ($modx->getFields($class) as $field => $v) {
              if (in_array($field, $tableFields)) {
                  unset($tableFields[$field]);
                  $manager->alterField($class, $field);
              } else {
                  $manager->addField($class, $field);
              }
          }
          foreach ($tableFields as $field) {
              $manager->removeField($class, $field);
          }
          // 2. Operate with indexes
          $indexes = [];
          $c = $modx->prepare("SHOW INDEX FROM {$modx->getTableName($class)}");
          $c->execute();
          while ($row = $c->fetch(PDO::FETCH_ASSOC)) {

I can’t say precisely why this doesn’t seem to work reliably (at least on MODX 3), but it seems that the code still uses the outdated “efField” class (with the missing fields) when this resolver runs.

So you probably have to “Reinstall” the same package again to make it work, or alternatively add the columns manually to the database table using SQL (or a tool like phpMyAdmin).

wwdesign · July 2, 2025, 3:10pm

Thanks for sharing this.

I was able to resolve the issue by re-adding the precision column after the update. Interestingly, I had added the column before the update as well, but it was removed during the process — so I had to add it again afterward.

While doing so via phpMyAdmin, I received a warning indicating that precision is a reserved word in MySQL. I believe this may have been the underlying cause of the issue, and it appears that adding it manually was the only way to get it to work reliably.

Let me know your thoughts on this — curious to hear if you’ve encountered anything similar.

thanks!

halftrainedharry · July 2, 2025, 4:25pm

I don’t think the problem is that precision is a reserved keywork.
The column name should get safely enclosed by backticks (`) in the generated SQL command.

To me it looked more like the code was using the outdated field information for the class “efField” when the resolver was running.

Maybe you could open an issue on Github for this, so that the author of the extra is aware of the problem: