Forum Replies Created

Viewing 6 replies - 1 through 6 (of 6 total)
  • Thread Starter andreabrundo

    (@andreabrundo)

    It came back again!
    Here’s the screen cap of the console showing the JS error:
    Yoast-error-console

    Thread Starter andreabrundo

    (@andreabrundo)

    @amboutwe, something strange happened when I followed your hints O.o

    Loading the page with the console active, an error was actually signaled.
    Instead of copying the error (my mistake), I tried to load a working page from another subsite of the network and check the differences. As expected, everything worked fine.
    Then I went back to the subsite/page which generated the error and…

    It was fixed.

    Everything I did I had already done many other times, the only difference was activating the console.
    I waited some time and rechecked loading the page with the error, but it really seems fixed.

    Now, I’m glad I solved my issue, but I’m sorry I cannot provide further details on what the issue was and what fixed it.
    All I remember is that the error cited some “Yoast something” which was not set.

    Thanks for your support!

    Thread Starter andreabrundo

    (@andreabrundo)

    @suascat_wp, unfortunately that’s not the case… As I said, I already checked both the user- and site- level activation of the feature and they are ok.
    So, it’s something else which is not working, and I have no idea what it is 🙁

    Thread Starter andreabrundo

    (@andreabrundo)

    Thank you Pcosta88, I will follow github thread.

    However, I would like to stress the following: as well as Yoast, I also have Jetpack produce a sitemap for google. As a result, jetpack’s sitemap is visible into Google Search Console robots.txt tester for each of the single sites in the network.

    So. Maybe Jetpack has developed the feature “by itself”. But are we sure there is no way to use their solution?

    Thread Starter andreabrundo

    (@andreabrundo)

    I finally solved it!

    First, thank you Pavel for pointing me in the right direction. I was lost in a rid of possibilities, with your reply I was able to ignore everything but the option database corruption.

    That said, let me point out that I might be damned for quite a few years in the hell of coders for some hazardous practice I dwelved into.

    But let’s get to the point.

    First, I already checked the thread https://wordpress.stackexchange.com/questions/11725/why-are-my-roles-not-visible-in-a-multi-site-network pointed out by Pavel, and a few others. However, the option_name errors (wp_user_roles instead of wp_<em>blogid</em>_user_roles, or missing wp_<em>blogid</em>_user_roles) were not involved.

    I had the feeling that the error was int the corrisponding option_value string. But I wanted to be sure, so…
    I indulged in the capital sin of mangling with DB production data.
    Here follow the details of my crime. But there is more going on, and the rest is really safe: I misbehaved only for the “analysis”, not for the correction, which as you will see is quite polite.
    – I renamed the option_name from wp_##_user_roles to wp_##_user_roles_ (with a trailing underscore
    – I copied this renamed record to a new record, resetting the option_name to the correct value
    – I then copied the option_value from the wp_##_user_roles of a different site (different ##) into the option_value of the newly created wp_##_user_roles
    – I checked the site and – BANG – the roles were back

    Now, I got the culprit, I knew I was able to put the site back to work… But I had to clean things up.

    The option_value of a wp_##_user_roles record in a wp_##_options table is formatted as a php-serialised array. It contains data specific to each plugin, so I couldn’t let the data from a different site to populate the record: the “good” site (the one I took the working array from) didn’t have the same plugin as the site which originated the role issue. So, whenever a plugin would have queried the db for the data in the option_value an error would have occurred – maybe even an harmful one.

    So, in order to clean up things, here’s what I did:
    – First, I copied the data in the option_value field of the wp_##_user_roles and from the wp_##_user_roles_ (with the trailing underscore) records in two different text files
    – I checked each string, with tools like https://www.functions-online.com/unserialize.html or http://blog.tanist.co.uk/files/unserialize/
    – I confirmed that the option_value string fromt the site which originated the issue was actually corrupt, whil the other was correct.
    – I fixed the string with https://github.com/Blogestudio/Fix-Serialization
    – I pasted the corrected data in the option_value field of the wp_##_user_roles_ (with the trailing underscore) record of the wp_##_options table of the site with issues.
    – I finally deleted the wp_##_user_roles record and renamed the wp_##_user_roles_ to normal

    Now everything is working fine.

    Thread Starter andreabrundo

    (@andreabrundo)

    Ugh, no replies…

    Too-newbb-a-question, or maybe I did some mistake (like wrong thread, wrong categorising something,…)?

    Please help 🙂
    Thanks

Viewing 6 replies - 1 through 6 (of 6 total)