Posted by greenstick on Fri, Oct 09, 2020 - 8:39am

At some point today seeming randomly, a couple (literally) of integer fields on a custom content type seem to have disappeared.   They no longer show in the edit/add content form, nor does the field show up anymore on those content pages or views that referenced them.  

I can however still see references to the fields in the database, and browsing shows the data that was in there. i.e.

field_data_field_price_dkk
field_data_field_price_euro

field_revision_field_price_dkk
field_revision_field_price_euro

The only thing that's different about these fields in case it's relevant, is a few days ago I deleted both of them (which were at the time Number Decimal fields) and re-created them both with the same field names (as integers.)   Yes this deleted the existing data, but it was all re-added afterwards on the new fields and seemed to be working fine until they vanished from the site today.

Anyone have a clue about how to fix this or of there's something to check for in the database?  There's not a ton of information on the site yet so I could always re-create the fields again I suppose, but I don't want to run into the same problem again if I do.

 

Most helpful answers

No problem.  Wish I could pay

No problem.  Wish I could pay it forward more on the forums, but I still have a lot to learn.

1) This is a fresh build on Backdrop.  (It's been updated version wise while in the works, but wasn't ported.)

2) I'm actually working on 3 concurrently - but this is the first one that's gone 'live' - the other two are still works in progress just residing on my local machine and using WAMP.

3) That's a tough one to answer, again I haven't tried to make a direct port over from D7 so I can't really comment on what the documentation currently says, nor did I read an awful lot about the differences between the two as far as how things are kept file-wise (past template differences at least.)

Coming from D7 I suppose I just got accustomed to being able to overwrite a DB with one from a different environment (i.e. WAMP to host) and changes to content types and whatnot being taken care of.  I'm not saying it's not well documented that isn't the case, it may well be (I just wasn't aware, and I'm more of a trial by error guy than a read the whole book twice person.)

I suppose in my particular case, were there some further indication that there was a discrepancy between the database fields for said content type and the missing JSON files it would have been pretty easy to sort out, i.e. "warning: you have database entries for the field 'price' but there are no configuration files for this field available in config_@$@#$ so it will not show"

At the same time I can understand that might neglect part of the point of the way things are set up having to check the DB if the JSON files are supposed to come first.

Perhaps some kind of comparison could be made alongside update checks?  Most of this back-end stuff is very much out of my league so I have no idea what's practical, but perhaps some kind of config files to DB comparison that only ran periodically wouldn't add too much overhead?

Ok!  I haven't sorted it out

Ok!  I haven't sorted it out but I think you fould the culprit - thank you ever so much!  There were definitely missing json files for the particular fields, I had also forgot to mention that I had to add a couple things on my local server and re-upload the database (and had no idea that Backdrop stored things as such.)

I tried uploading what I thought was missing, still not showing - I'll just try the entire config_234203470870..... folder in a moment.

Is sendmeabeer still a thing?  Owe you one.

 

 

Comments

Fri, Oct 09, 2020 - 1:06pm by stpaultim

I recommend looking at your configuration files as a possible source of the problem. 

If you are managing your code in GIT and have the active config directory committed to git, it is possible that you overwrote some of your config files while updating GIT. I've done this before.

Remember, that Backdrop stores content type and field configuration in code. 

https://api.backdropcms.org/documentation/working-configuration

Fri, Oct 09, 2020 - 1:22pm by greenstick

Thanks for the reply - but no, not using git whatsoever.   Out of curiosity after looking at the link you provided however, where would one find the JSON file that manages the configuration for content types?  Perhaps I can compare that to a local copy running on WAMP in which the fields are still working fine.

Fri, Oct 09, 2020 - 1:27pm by stpaultim

The default location for configuration files is at:

files/config_{long-random-number}/active/

Look for files such as:

  • node.type.post.json
  • field.field.body.json
  • field.instance.node.page.body.json

Even if your not using git, it's possible that your config files are part of the problem. 

 

 

Fri, Oct 09, 2020 - 1:48pm by greenstick

Ok!  I haven't sorted it out but I think you fould the culprit - thank you ever so much!  There were definitely missing json files for the particular fields, I had also forgot to mention that I had to add a couple things on my local server and re-upload the database (and had no idea that Backdrop stored things as such.)

I tried uploading what I thought was missing, still not showing - I'll just try the entire config_234203470870..... folder in a moment.

Is sendmeabeer still a thing?  Owe you one.

 

 

Fri, Oct 09, 2020 - 1:54pm by greenstick

And that worked!  Thank you so much, would have never figured that out coming from D7.

Fri, Oct 09, 2020 - 2:00pm by stpaultim

Great. The beer offer was nice, but what would be really helpful is just to answer a couple of (hopefully) quick questions that might help us make this easier for others in the future. 

1) Did you build this site fresh in Backdrop CMS or did you upgrade it?

2) Is this your first Backdrop CMS site or have you worked on others?

3) From your perspective, is there something that Backdrop could do to make this change to config files (change from Drupal 7) more obvious and/or easier to understand? This could be a change in the user interface for Backdrop CMS or it could be better documentation. We'd like to have any feedback from you on what might have made this problem easier for you to resolve on your own.

Fri, Oct 09, 2020 - 2:40pm by greenstick

No problem.  Wish I could pay it forward more on the forums, but I still have a lot to learn.

1) This is a fresh build on Backdrop.  (It's been updated version wise while in the works, but wasn't ported.)

2) I'm actually working on 3 concurrently - but this is the first one that's gone 'live' - the other two are still works in progress just residing on my local machine and using WAMP.

3) That's a tough one to answer, again I haven't tried to make a direct port over from D7 so I can't really comment on what the documentation currently says, nor did I read an awful lot about the differences between the two as far as how things are kept file-wise (past template differences at least.)

Coming from D7 I suppose I just got accustomed to being able to overwrite a DB with one from a different environment (i.e. WAMP to host) and changes to content types and whatnot being taken care of.  I'm not saying it's not well documented that isn't the case, it may well be (I just wasn't aware, and I'm more of a trial by error guy than a read the whole book twice person.)

I suppose in my particular case, were there some further indication that there was a discrepancy between the database fields for said content type and the missing JSON files it would have been pretty easy to sort out, i.e. "warning: you have database entries for the field 'price' but there are no configuration files for this field available in config_@$@#$ so it will not show"

At the same time I can understand that might neglect part of the point of the way things are set up having to check the DB if the JSON files are supposed to come first.

Perhaps some kind of comparison could be made alongside update checks?  Most of this back-end stuff is very much out of my league so I have no idea what's practical, but perhaps some kind of config files to DB comparison that only ran periodically wouldn't add too much overhead?

Fri, Oct 09, 2020 - 1:29pm by greenstick

I forgot to mention this since it no longer shows and didn't seem relevant, but at one point a couple of days ago the site displayed the following message pertaining to these particular fields:

Inactive fields are not shown unless their providing modules are enabled. The following fields are not enabled:

    Price (DKK) (field_price_dkk) field requires the Text field widget provided by number module
    Price (Euro) (field_price_euro) field requires the Text field widget provided by number module

I had thought this was because of the temporarily deleted fields still being referenced in views, templates etc, and the message no longer showed after re-adding the fields with their new type (and still don't.)

However, maybe there's something to that?  Could they be 'flagged' somewhere still to be inactive?  If so, where?  (Again, they were working after the change so I don't see why that would happen arbitrarily afterwards.)