Parent pages missing from breadcrumb after 6.0.1 update

I am running PHP7 on my testbed and 7.1 on my production server (for mtekk.us). I’m not seeing this issue on either of those sites. Just for clarification, did this worked correctly with 5.7.1 on the production site?

Yes, it worked as expected with the previous version. I can’t think of anything else that may have changed. Very strange.

Try exporting your settings (via the help tab), in the resulting XML document, look at what the value of bpost_page_hierarchy_display make sure it’s 1 and Spost_page_hierarchy_type is BCN_POST_PARENT.

Note that on my testbed this is the case, on my live site neither option is showing up, but things appear to be working.

OK, so on the live site, the “BCN_POST_PARENT” value is missing (the “Spost_page_hierarchy_type” setting is there, but value is blank). The “bpost_page_hierarchy_display” value is 1 on both.

Should I try editing the “BCN_POST_PARENT” value back in manually via phpAdmin (in the “bcn_options” row in the WordPress option table, I assume)? Or could that have unanticipated consequences?

You can try that, just note that things are stored in the database as a serilized string, so there will be some character counts to update. The other thing you can try doing is a settings reset on the live site (same form as the export).

I’m going to consider this a bug of sorts. Those two settings should either be missing, or known good values. Somehow, the one is corrupt on your live site (which is a problem). I’m tracking this under the following issue on GitHub: https://github.com/mtekk/Breadcrumb-NavXT/issues/182

• This reply was modified 6 years, 11 months ago by John Havlik.

I edited the option table value, and everything is back to normal on the live site. Thanks so much for your quick response and suggestions! For the record, what I did was edit the WordPress options table row “bcn_options”, and changed:

s:25:”Spost_page_hierarchy_type”;s:0:””;

to

s:25:”Spost_page_hierarchy_type”;s:15:”BCN_POST_PARENT”;

Thanks again!

I just experienced the exact same problem. So, is the solution to go in to the table via phpMyadmin and reset that value?

That seems to work. I’m going to change something in the plugin to hopefully fix this (in a 6.0.2 release). If you don’t mind, could you answer a couple of questions (I’m trying to figure out how it is losing the post_page_hierarchy_type setting, it should never be blank):

What version did you upgrade from?
Did you run the “migrate now” action for the settings?
Did it work before running “migrate now”?
Did you modify any of your settings and press “Save Changes” since updating?

My answers, if this also helps:

What version did you upgrade from?
5.7.1 (missed 6.0.0)

Did you run the “migrate now” action for the settings?
Yes.

Did it work before running “migrate now”?
Unfortunately, I didn’t check this. I went straight to the settings page after upgrading and clicked migrate, since I recall that was something that needed to be done in previous releases.

Did you modify any of your settings and press “Save Changes” since updating?
I think so, but not 100% sure. I was pretty sure that the “Breadcrumb Separator” value I had been using before was “»” (the html entity code for the double right bracket), but after migrating, it got changed to just show the native character “?” instead. I tried changing it back to the html entity, but that doesn’t seem to work anymore (it keeps getting changed back to “?”). Though oddly, all the other setting boxes I have edited on other tabs do retain the “raquo” code values. But that did involve a save operation. Also, I think I may have un-checked the “Post Hierarchy Display” box on the Post Types tab, but not sure on that.

Hope this helps.

• This reply was modified 6 years, 11 months ago by noibn.

Thanks for the additional information. The change for how » behaves in the separator box is likely due to moving to a new escaping function (adminKit, which handles the settings page had a major overhaul in this version). I did some testing of this in my testbed and the good news is the correct entity is used. Additionally, things like <img src="" alt="separator"> appear to still work. It doesn’t appear that the value breaks after repeated savings (the real danger here). However, I’m not sure I exactly like the behavior (just showing the “raw” HTML would be better as it would be less confusing.

I think the real solution here is to switch to the proper textarea rather than a text input for the separator, it will restore the “raw” HTML look and should clear up any confusion. This will make the next release (6.0.2). I’m tracking this in the following GitHub issue: https://github.com/mtekk/Breadcrumb-NavXT/issues/184