Eric

No errors appear through the entire workflow now. Thank you for your diligence and timeliness in getting these resolved!

The previous errors are not appearing anymore, only this one. I followed the same procedure and received the following:

Uncaught TypeError: $ is not a function
    PPCS_RecaptionOnDisplay https://wordpress.local/wp-content/plugins/publishpress-statuses/common/js/custom-status-block.js?ver=1.0.6.7-rc:7
    ppPostSavingDone https://wordpress.local/wp-content/plugins/publishpress-statuses/common/js/post-block-edit.js?ver=1.0.6.7-rc:22
    setTimeout handler*ppPostSavingDone/< https://wordpress.local/wp-content/plugins/publishpress-statuses/common/js/post-block-edit.js?ver=1.0.6.7-rc:22
    setTimeout handler*ppPostSavingDone https://wordpress.local/wp-content/plugins/publishpress-statuses/common/js/post-block-edit.js?ver=1.0.6.7-rc:22
    redirectCheckSaveDoneInterval https://wordpress.local/wp-content/plugins/publishpress-statuses/common/js/post-block-edit.js?ver=1.0.6.7-rc:26
    setInterval handler*ppPostSaveCheck https://wordpress.local/wp-content/plugins/publishpress-statuses/common/js/post-block-edit.js?ver=1.0.6.7-rc:26
    redirectCheckSaveInterval https://wordpress.local/wp-content/plugins/publishpress-statuses/common/js/post-block-edit.js?ver=1.0.6.7-rc:27
    setInterval handler* https://wordpress.local/wp-content/plugins/publishpress-statuses/common/js/post-block-edit.js?ver=1.0.6.7-rc:27
    jQuery 13
custom-status-block.js:7:48

An error no longer appears when editing or creating a new page until the Update or Workflow > Pitch(Next Status) button is clicked in which case the following errors occur:

Appears 1 time:

Uncaught TypeError: $ is not a function
    ppEnablePostUpdate https://wordpress.local/wp-content/plugins/publishpress-statuses/common/js/custom-status-block.js?ver=1.0.6.6-rc2:30
    ppPostSavingDone https://wordpress.local/wp-content/plugins/publishpress-statuses/common/js/post-block-edit.js?ver=1.0.6.6-rc2:21
    redirectCheckSaveDoneInterval https://wordpress.local/wp-content/plugins/publishpress-statuses/common/js/post-block-edit.js?ver=1.0.6.6-rc2:26
    setInterval handler*ppPostSaveCheck https://wordpress.local/wp-content/plugins/publishpress-statuses/common/js/post-block-edit.js?ver=1.0.6.6-rc2:26
    <anonymous> https://wordpress.local/wp-content/plugins/publishpress-statuses/common/js/post-block-edit.js?ver=1.0.6.6-rc2:27
    jQuery 10
    <anonymous> https://wordpress.local/wp-content/plugins/events-calendar-pro/src/resources/js/admin-widget.min.js?ver=6.3.1:11
    <anonymous> https://wordpress.local/wp-content/plugins/events-calendar-pro/src/resources/js/admin-widget.min.js?ver=6.3.1:11
custom-status-block.js:30:604

Repeats multiple times:

Uncaught TypeError: $ is not a function
    intRestoreToggle https://wordpress.local/wp-content/plugins/publishpress-statuses/common/js/custom-status-block.js?ver=1.0.6.6-rc2:30
    setInterval handler*ppEnablePostUpdate https://wordpress.local/wp-content/plugins/publishpress-statuses/common/js/custom-status-block.js?ver=1.0.6.6-rc2:30
    ppPostSavingDone https://wordpress.local/wp-content/plugins/publishpress-statuses/common/js/post-block-edit.js?ver=1.0.6.6-rc2:21
    redirectCheckSaveDoneInterval https://wordpress.local/wp-content/plugins/publishpress-statuses/common/js/post-block-edit.js?ver=1.0.6.6-rc2:26
    setInterval handler*ppPostSaveCheck https://wordpress.local/wp-content/plugins/publishpress-statuses/common/js/post-block-edit.js?ver=1.0.6.6-rc2:26
    <anonymous> https://wordpress.local/wp-content/plugins/publishpress-statuses/common/js/post-block-edit.js?ver=1.0.6.6-rc2:27
    jQuery 10
    <anonymous> https://wordpress.local/wp-content/plugins/events-calendar-pro/src/resources/js/admin-widget.min.js?ver=6.3.1:11
    <anonymous> https://wordpress.local/wp-content/plugins/events-calendar-pro/src/resources/js/admin-widget.min.js?ver=6.3.1:11
393 custom-status-block.js:30:104

The result is different though there is still an error reported.

Uncaught TypeError: $ is not a function
    querySelectableStatuses https://wordpress.local/wp-content/plugins/publishpress-statuses/common/js/custom-status-block.js?ver=1.0.6.6-rc:2
    jQuery 9
    querySelectableStatuses https://wordpress.local/wp-content/plugins/publishpress-statuses/common/js/custom-status-block.js?ver=1.0.6.6-rc:2
    refreshSelectableStatuses https://wordpress.local/wp-content/plugins/publishpress-statuses/common/js/custom-status-block.js?ver=1.0.6.6-rc:5
    sideEffectL10nManipulation https://wordpress.local/wp-content/plugins/publishpress-statuses/common/js/custom-status-block.js?ver=1.0.6.6-rc:11
    jQuery 10
    sideEffectL10nManipulation https://wordpress.local/wp-content/plugins/publishpress-statuses/common/js/custom-status-block.js?ver=1.0.6.6-rc:9
    <anonymous> https://wordpress.local/wp-content/plugins/publishpress-statuses/common/js/custom-status-block.js?ver=1.0.6.6-rc:12
    setInterval handler* https://wordpress.local/wp-content/plugins/publishpress-statuses/common/js/custom-status-block.js?ver=1.0.6.6-rc:12
    jQuery 13
custom-status-block.js:2:1594

Sure thing. I updated to Statuses 1.0.6.5 and unfortunately the problem remains. The console error repeats roughly 2 to 3 times per second.

Uncaught TypeError: $ is not a function
    sideEffectL10nManipulation https://wordpress.local/wp-content/plugins/publishpress-statuses/common/js/custom-status-block.js?ver=1.0.6.5:10
    <anonymous> https://wordpress.local/wp-content/plugins/publishpress-statuses/common/js/custom-status-block.js?ver=1.0.6.5:12
35 custom-status-block.js:10:50

There are only 24 items in the purged URLs array and appears that the purge cache succeeds based on the message “DEBUG:purgeCacheByRevelantURLs succeeded”.

However, the menu never finishes saving and a 502 error is generated. The 502 error is caused by the host stopping the script from exceeding a threshold of time, so technically the problem is not caused by the CloudFlare plugin, but the environment it is in.

Most likely it is on the edit_post action since each menu item is a post and updating the menu item causes each to be updated as well. Here are the relevant functions associated with a menu update.

wp_nav_menu_update_menu_items()
wp_update_nav_menu_item()
update_post_meta()
wp_update_post()
wp_insert_post()

The last, wp_insert_post, executes the edit_post action. So it would seem that’s where the inefficiency may be. Granted, I have not delved into the CloudFlare plugin code so I could be mistaken as to the cause.

https://github.com/cloudflare/Cloudflare-WordPress/blob/master/cloudflare.loader.php#L84

There are no errors, just the timeout.

The menu in question has 600 items. Without ACM active, it saves in under 12 seconds, but with ACM, it exceeds the time allowed for script execution on the server.

As an alternative to disabling ACM all the time, we can just disable it during menu edits. I hope this information helps.

Great to hear. You are quite welcome.

Sure. In order to do that though, you would need to setup a child theme or utilize hooks within the active theme to override the template output.

Setting up a child theme is documented in the codex. Once the child theme is setup and activated, you would need to identify the template part responsible for generating the footer within the active theme, copy it to your child theme and make necessary modifications. Child theme templates override their parent theme counterparts.

Hooks can be found by searching the source code for apply_filters or do_action then leveraged by using add_filter and add_action function calls respectively.

Hope this helps.

It appears the stylesheet override is not loading. It doesn’t appear you are using a child theme it could mean the custom CSS plugin or method you are using is not functioning as expected.

I suggest using the Jetpack plugin’s Custom CSS module. Instructions for using the module are located at jetpack.me.

Sure. At the moment it seems the site is not loading properly so I cannot analyze the issue properly. However, you could try adding the “!important” directive to the CSS like so:

.copyright > .free-credit { display: none !important; }

Let me know if that doesn’t work and I’ll have a look at the code when the site is available.

Sure thing. The widget panels do not seem to transform their size and position gracefully since at some point they end up overlapping one another. After looking at the code a while, I think it might be best to lock the width of the page to 920px until it reaches the point at which the grid of panels stack. Give this a try.

@media screen and (min-width:681px) {
    .siteorigin-panels section.entry {
        min-width: 920px !important;
    }
}

Let me know if that works out for you.

PS – The author of the SiteOrigin Widgets Bundle may have some additional insights into the issue as well.

It seems you would need to set the left and right margin of the div in question to auto and unset the float. The “!important” directive may not be necessary, but I included it just in case.

@media screen and (max-width:680px) {
    .so-widget-sow-editor > .textwidget > div {
        margin: 0 auto !important;
        float: none !important;
    }
}

The following CSS should do the trick:

.copyright > .free-credit { display: none; }

Typically when you see this type of issue it means an element somewhere on the page is set to have a minimum or fixed width. In this particular case, the Accreditation5.jpg image is set to be 1034px wide and 100px tall and will not scale.

<img style="border: 1px solid black; margin: 10px;" src="https://new.kingcoffeemug.com/wp-content/uploads/2016/03/Accreditation5.jpg" alt="" usemap="#Map" height="100" border="0" width="1034">

You would need to manipulate the image tag directly or setup CSS to override the width and height.

HTML:

<img style="border: 1px solid black; margin: 10px;" src="https://new.kingcoffeemug.com/wp-content/uploads/2016/03/Accreditation5.jpg" alt="" usemap="#Map" border="0" width="100%">

CSS:

img[src*="Accreditation5"] {
    width:100% !important;
    height: auto !important;
}