BoldMinded

Publisher does not support the Fluid field type. Please do not contact asking when support will be available.

If you purchased an add-on from expressionengine.com, be sure to visit boldminded.com/claim to add the license to your account here on boldminded.com.

Ticket: Some categories when checked are not saved to the DB

Status Resolved
Add-on / Version Publisher 3.1.1
Severity
EE Version 5.3.0

Bruce Sabalaskey

Jan 07, 2020

Just updated from 2.11.1 to 3.1.1 and notice this problem. I have three category groups assigned to an article, group 1 (Region) with 3 items, group 2 (Topics) with about 20 items, and group 3 (Edition) with only one item. All three of these groups are assigned to the channel, such as News. When I publish an article and click (enable) the only item for group 3, it never gets saved to the DB. When you retrieve the article it is not checked. I looked at the POST request and noticed that the cat_group_id was being incorrectly set to 1 when it should be 3. And the cat_group_id_3 still had the category posted, but not in array form, rather like an individual (vs array) input. The other two category groups seem to work properly, as I can properly update those with the combinations that I tried.

This is repeatable for any article update I have tried.

To view the front-end, access this URL first. https://dev.lifesitenews.com/server/get-server-permission
The backend can always be reached.

Regards,
Bruce

#1

Bruce Sabalaskey

An update. I did look in the database and the exp_category_posts plus the exp_publisher_category_posts table does get updated (category 41 for entry_id 206316). But the backend never shows that it is enabled in the categories tab.

#2

Bruce Sabalaskey

Further update. When saving the article with said category *unchecked”, it is not removed from the database. A Hotel California like effect. In all cases, the checkbox never shows active in the backend when viewing the article.

#3

BoldMinded (Brian)

Can you record a video of this process from beginning to end? It’s hard to follow the way you described it.

Did you upgrade EE? Nothing that I can recall changed in Publisher regarding category saving from v2 to v3.

#4

BoldMinded (Brian)

Also, was this happening in the default language or a non-default language? Were you viewing a Draft and saving as Published? This is why the video will help, there are multiple scenarios here and depending on several variables it will save data differently. I need to be able to replicate that.

#5

BoldMinded (Brian)

Does this happen only on existing entries that were assigned to categories? Does the same thing happen when creating a brand new entry?

I have lots of questions and need lots of details 😊

#6

BoldMinded (Brian)

I just did several tests and categories appear to be saving in my environment.

Next step, after you create the video, is to create a new EE install with only Publisher installed to try to replicate the issue.

#7

Bruce Sabalaskey

Brian, Some answers are this. It is in the default language, English, and that is the only language that we are using. We use your add-on for the draft features (editors and publishers roles). Our EE environment has been constant for a while, EE 5.3.0, which was in place for Pub 2.11.1 and now 3.1.1. If it makes a difference, our site is huge and had to migrate about 78000 entries in that upgrade process. I will attempt the new vs update article and let you know.

#8

Bruce Sabalaskey

An update: I have determined that Publisher has incorrectly assigned the category ID 41 to category group 1 instead of category group 3. I will send screen shots of the exp_categories table and the backend screen for said category groups, as compared to Publisher.

Question: is there any way to edit the category in Publisher so that it is in the right group?

#9

Bruce Sabalaskey

I tried to edit the ticket to submit screen shots, 5 of them. Yet that doesn’t save. How do I send you screen shots?

#10

BoldMinded (Brian)

I have determined that Publisher has incorrectly assigned the category ID 41 to category group 1 instead of category group 3

I’d be very surprised if this happened. Publisher doesn’t alter category group assignments.

Upload the screenhots to dropbox, droplr, or some other sharing service and link them in a comment.

#11

Bruce Sabalaskey

Please see these screen shots. https://www.dropbox.com/sh/zh73chk8rdq6tr5/AAAORPAZp2wDpjb37g-KF0wma?dl=0

#12

BoldMinded (Brian)

Bruce, is it just this one category or is it happening to others?

#13

Bruce Sabalaskey

It is only this particular category group (ID 3) which has the one category in it (ID 41). Very strange. I tried various permutations of the other category groups (1 and 2) and those all properly record the updates and show properly on the backend. Maybe because there is only one category in the group (for now)? The others have many.

#14

Bruce Sabalaskey

One other observation on this category group 3 field. I noticed in the XHR POST data (when saving an article) this setting: ee_fv_field: categories[cat_group_id_3][]. Not sure what that is for but the reference matches the problematic category group.

#15

Bruce Sabalaskey

Please see the new graphic file named “screenshot with cat 41 in wrong cat group 1.jpg” in the Dropbox folder https://www.dropbox.com/sh/zh73chk8rdq6tr5/AAAORPAZp2wDpjb37g-KF0wma?dl=0.

This was captured when saving an article which did not properly show the cat 41 in group 3. However, that ee_fv_field is set to “categories[cat_group_id_1][]” which has the wrong cat ID 41 in it.

You can see the category 41 wrongly assigned to cat_group_id_1 instead of cat_group_id_3. This smells like a JavaScript issue as it is an xhr JSON POST.

#16

BoldMinded (Brian)

I’m still unable to replicate any such issues. I created a new category group with only 1 category in it. Entries save fine in every combination I’ve tested.

This smells like a JavaScript issue as it is an xhr JSON POST

Can you capture that request so I can take a look at it? Saving entry does not save via ajax, only versions are saved automatically in the background and that shouldn’t be updating anything Publisher related.

#17

Bruce Sabalaskey

I will capture that somehow. In the mean time, why does Publisher incorrectly place category ID 41, which should be into cat group 3, instead into cat group 1? That shows up in Publisher backend.

#18

Bruce Sabalaskey

Please see the HAR file save-article.har in Dropbox https://www.dropbox.com/sh/zh73chk8rdq6tr5/AAAORPAZp2wDpjb37g-KF0wma?dl=0.

I did another experiment. I added a fourth category group (cat group ID 4) with just one category (cat ID 44), and that worked OK. The standard POST (non-xhr) for /cp/publish/edit/entry/206429 also had wrongly assigned category ID 41 to both ‘categories[cat_group_id_1]][]’ and ‘categories[cat_group_id_3]][]’.

#19

Bruce Sabalaskey

See also the picture ‘wrong assignment of cat ID 41.jpg’ in the dropbox folder highlighting the wrong assignment of cat ID 41 in the POST, to two category groups 1 and 3.

#20

Bruce Sabalaskey

If you want, I can send you SQL files of my category group and category tables. Let me know.

#21

BoldMinded (Brian)

I just spent another round trying to replicate this locally, and can’t. Since I can’t replicate it, and no one has reported similar issues, the only thing I can do at this point is chalk it up to a fluke. Try running the following query on your database. I suspect that the current group_id is set to 1 in exp_publisher_categories, but I can’t verify that b/c the CP login you provided doesn’t work.

update exp_publisher_categories set group_id = 3 where cat_id = 41;
#22

Bruce Sabalaskey

This must be some type of data sensitivity issue where category group 3 and category 41 are “cursed” when there are 3 category groups. My fix involved the following. I added a new category group (ID 4) with a new category in it (ID 42). Then I manually updated the DB (exp_category_posts) so that all articles with the old category ID 41 were updated to 42. Then I deleted in the backend the old category 41 and old category group 3. After I did that, the Publisher category translation page properly shows the right category in its group. And the article saving in the backend properly displays.

I did run that query but the Publisher table is empty. I also ran it on the exp_categories table just in case. That had no effect.

Basically I had to modify my data to work around the code.

#23

BoldMinded (Brian)

Yeah, that is super weird and unlike any bug I’ve had reported before. Glad you sorted out the issue though.

Login to reply