Forum Replies Created

Viewing 15 replies - 1 through 15 (of 27 total)
  • We’re seeing this to (at least on one site so far) where the site is slowing down and my client just sent a screenshot with this exact same message.

    Thread Starter Justin Korn

    (@themonko)

    Actually, I see it happening on another site I’ve implemented: https://fermentationwineblog.com/ — the post titled “This is Why Alcohol Self-Distribution is the Next Big Thing” shows 0 comments on the homepage (https://screencast.com/t/gdyGTVCP80ci), however, if you visit the post: https://fermentationwineblog.com/2020/03/this-is-why-alcohol-self-distribution-is-the-next-big-thing/ you can see it clearly has 4 comments (as of this note): https://screencast.com/t/VdsMeusqszS1.

    • This reply was modified 6 years, 2 months ago by Justin Korn.

    Within Multisite, can this be activated network wide? Just tried locally and it didn’t seem to disable /wp-json/wp/v2/users on any of the sites.

    Thread Starter Justin Korn

    (@themonko)

    Yep, using 1.3.2.

    Thread Starter Justin Korn

    (@themonko)

    Hmm…it is possible I ran the test before updating, copied the log, realized I wasn’t up-to-date and then ran again but still saw issues. Unfortunately, I can’t remember which of my client’s installs had this plugin to double check.

    I’ll run through a few to see if I can find it and if I do, I’ll run the test again and double check the logs.

    Thanks!

    Thread Starter Justin Korn

    (@themonko)

    No worries, @pepe, thanks for the response.

    Yes, latest version of the wp-Typography plugin and we’re using WP Engine’s checker: https://ww.wp.xz.cn/plugins/php-compatibility-checker/

    In case it wasn’t obvious, the log I posted shows you the file and line in which the error is being reported. All errors are in the /wp-typography/php-typography/class-php-typography.php file and the first column is the line, i.e. 2131, 2152 etc.

    Thanks again!

    Thread Starter Justin Korn

    (@themonko)

    Thanks, Deblyn! Been awhile, but better late than never 🙂 Appreciate the update! I’ll have to give it a test again sometime.

    Thread Starter Justin Korn

    (@themonko)

    Thanks for the quick replies, Edward. Unfortunately, neither of those work.

    When using $data->new_post(); the name field (aka the slug) seems to be the slug from the parent page not the child page.

    When using $data->new_post('ID'); the I’m just getting 0 returned.

    But, that did lead me to find $data->broadcast_data->get_linked_child_on_this_blog() which is what I needed. Let me know if there is anything wrong with this, otherwise, thanks for the help!

    Thread Starter Justin Korn

    (@themonko)

    Seems like $data->modified_post isn’t available yet. Where would I get the child post id from?

    Thread Starter Justin Korn

    (@themonko)

    Just found broadcasting_data->new_child_created. Seems to be the ticket.

    Thread Starter Justin Korn

    (@themonko)

    Hey Edward,

    I’ve done a few more test to see if I could figure out a work around:

    1) I tried hooking into post_updated to see where/when it is triggered and it seems it is triggered after after_switch_to_blog and before modify_post. Which is interesting that the child post would be ‘updated’ BEFORE the modify_post action. In any case, I tried capturing my data in after_switch_to_blog and then updating the post with the new data in post_updated but it seems your plugin overwrites that data again afterwards. So that didn’t work.

    2) I tried collecting all data in after_switch_to_blog (at this point, collecting the data I want to save isn’t the issue) and then waiting until your plugin hooks into broadcasting_finished. I’d only assume, at that point, everything is done. Nope, If I loop through the saved data and try to update the appropriate post in the appropriate blog (via switch_to_blog), the same thing happens as before where the child post (being broadcast too) doesn’t get the broadcasted data at all and the fields I tried to save and add are then doubled.

    So, I’m convinced, something in your plugin is happening after the fact that isn’t documented that isn’t allowing me to update the child post and allow the plugin to function as expected.

    Any further guidance would be greatly appreciated. I’m happy to share code, screen shares, etc with you however you’d like to try to get to the bottom of this.

    Thanks again.

    Thread Starter Justin Korn

    (@themonko)

    Hey Edward,

    The main issue and what I want to do is preserve fields within an ACF repeater field that have been added to a child (being broadcasted to) that do not exist on the parent (the broadcaster).

    Let’s say the parent has topic_0_topic_name, topic_0_topic_details, topic_1_topic_name, topic_1_topic_details.

    And the child has topic_0_topic_name, topic_0_topic_details, topic_1_topic_name, topic_1_topic_details, topic_2_topic_name, topic_2_topic_details.

    When the broadcast happens, I want to make sure the child doesn’t lose topic_2_topic_name, topic_2_topic_details since those don’t exist on the parent.

    While I could potentially save all of the meta and re-add it as you suggest, this would cause a ton of more calls to the server and seems redundant to part of what the plugin is supposed to be doing.

    Ideally, there should be a way to only have to re-add the differences. And, as it seems, there is no way to do that. During modify, the changes don’t stick. During before_restore, it is as if the changes never happened (any of them). It seems as if something is happening between modify and before_restore that checks the data and if they don’t match nothing happens or something along those lines causing things not to work properly.

    I hope that helps clarify what I’m trying to accomplish and why it isn’t working as is.

    I look forward to any further thoughts.

    Thanks,
    Justin

    Thread Starter Justin Korn

    (@themonko)

    Thanks for the quick replies, Edward. Unfortunately, something is still up…

    I did as you suggested. I saved child fields to be added back in during the modify_post action. Then, during before_restore_current_blog, I loop through and update the fields on the post with the fields I saved using update_field (http://www.advancedcustomfields.com/resources/update_field/)

    Two things happened:
    1) The child post didn’t get the updated fields from the parent (the ones that should be updated)
    2) The child now has 2 of the child fields I saved.

    So, it is clear for whatever reason, the child isn’t being updated at all in this scenario.

    Thoughts?

    Thread Starter Justin Korn

    (@themonko)

    Hey Edward,

    Nope, broadcasting_before_restore_current_blog is called AFTER the post is modified, so at that point, the child post already has the new fields and the ones I need to keep have already been overwritten.

    Any other thoughts?

    Thread Starter Justin Korn

    (@themonko)

    Hello Support,

    Thanks for the replay, but that is only helpful if I was inserting the code myself. However, I’m using the ShareThis plugin for ease of management for my client and, per my original post, the admin section of the plugin is completely unusable when run over SSL and the front-end does not display.

    It seems to be there is an issue with your plugin and in it’s current state, is completely unusable (when using SSL). You need to update your plugin so that ALL instances of the url are updated when the client is using SSL using is_ssl().

    If I’m missing something, please let me know, but from what I can tell, your solution isn’t answering my issue.

Viewing 15 replies - 1 through 15 (of 27 total)