New to the community? Start here

[Hummingbird Pro] Hummingbird Asset Propogation

Good day.
I am currently providing some optimization services for a client whom is hosted with WPMUDEV. I have been invited as a team member through the HUB 2.0 User/Role assignment.

I have been working with the Asset Optimization of Hummingbird which was initially working fine (yesterday), but now seems to be “stuck” on propagation of publishing compression and combines of the assets. This happened at some point while I was checking the effect of combining and moving the assets one by one as suggested in your optimization guide.

The site URL is https://aquaticsports.com/

Symptoms:
1. Upon publishing changes, only one css asset gets generated and placed in the Uploads/Hummingbird-Assets folder. The remainder of the the queued compression just show as spinning in the Advanced Mode asset window.
2. Clearing the cache using the button will delete the one asset file in the folder, but it will regenerate with the exact same file name and content that was there before the purge.
3. I have tried to reset the plugin and start over, but this makes no difference. When I re-check files the re-checker starts and 99% (as opposed to 0%) and then displays the same number of assets that were there previously, even when I disable a plugin with listed assets.

What I have tried:
1. I am running all visits to the homepage on propagation through an incognito window to avoid my log in nonce. I have also disabled page caching while I am working on the optimization to ensure this does not affect it.
2. Resetting the Asset Optimization settings.
3. Deactivating the Asset Optimization and reactivating.
4. Uninstalling Hummingbird and reinstalling.
5. Using SSH WP CACHE FLUSH AND WP REWRITE FLUSH (I’m not sure of the affect of these on the process if any, please confirm. When I’ve experienced similar issues of Hummingbird Asset propagation on my own site – when only one asset file is created – this seems to enable the remainder to be created).
6. Enabled error logging to help troubleshoot – I’ve attached the most recent log for your reference.

Can you please assist ? The WPMUDEV dashboard plugin is installed, but unfortunately there is no menu item that I can access to enable support access. It looks like its installed as a MU plugin. I know the web developer responsible for the site has recently experienced downtime due to maxing out resources I think, not sure if that has anything to do with it.

Much appreciated.
Lee

Sun, 12 Jul 2020 18:00:37
More Hummingbird Pro discussions
Hummingbird Pro
  • Patrick Freitas
    • FLS

    Hi Lee

    Hope you are doing well.

    I can see most of the troubleshooting tests were made.

    The Hummingbird will optimize the file when WordPress calls the script using the wp_enqueu_style or script.

    Some assets can take more time to be called from WordPress.

    For support access, you can ask your customer to give your user permission to access it from WPMU DEV dashboard > Settings > Permission.

    By default, it is only available for the user that enables it.

    You can also send the WordPress credentials instead of support access.

    Note: Please don’t share any sensitive information (i.e credentials) in the Support Forum.

    Instead, you can send us your details using our contact form https://wpmudev.com/contact/#i-have-a-different-question:

    Subject: “Attn: Patrick Freitas”

    – Site login URL:

    – WordPress admin username:
    – WordPress admin password:

    – Any other relevant URLs/info:

    Please, reply to the ticket once you have sent the information.
    Best Regards
    Patrick Freitas

  • Lee
    • Freelance WP Developer

    Hi Patrick. Support access has been granted.

    The Hummingbird will optimize the file when WordPress calls the script using the wp_enqueu_style or script.

    I understand this but this is really out of the norm – it has been acting this way for almost 24 hrs.

  • Kasia Swiderska
    • Support nomad

    Hello Lee ,

    I have been working with the Asset Optimization of Hummingbird which was initially working fine (yesterday), but now seems to be “stuck” on propagation of publishing compression and combines of the assets.

    1. I am running all visits to the homepage on propagation through an incognito window to avoid my log in nonce. I have also disabled page caching while I am working on the optimization to ensure this does not affect it.

    I’ve checked the site and it looks like this is the reason why the assets are still “spinning”. Some of the assets (like for example, tribe-events-custom-jquery-styles file) are not loaded on the home page, but on pages where those files are actually needed.
    So, in order to make the file propagate you need to visit the page where that file is loaded. So in the above example, file tribe-events-custom-jquery-styles was propagated only when I visited events-calendar page. I’ve checked several pages and more files in Asset Optimisation stopped spinning after it.

    However, we would still like to take a closer look at those other symptoms you mentioned, but since we would need to make some tests, is it possible you could push the live site to staging and also enable support access on staging?

    kind regards,
    Kasia

  • Lee
    • Freelance WP Developer

    Hi Kasia.

    I made some progress on my issues before you took a look. I was able to get by issue #3 by clearing the object cache through the HUB 2, so at least it went through the available asset indexing took place (although the number of listed available assets rarely seems to be the same).

    Regarding the queued compression you mentioned, I have visited all pages on the site to see impact on the process status and it made no difference for me. I would like you to take a look before I proceed too far. I will check with my client to ensure there is nothing waiting in staging that is in progress before we overwrite it.

    Question for you: the object cache purge located in the Hub at “domain”>hosting>tools>object cache . Is this is same flush that would be achieved using ssh “wp cache flush” command? I ran the ssh command many times and it had no impact on the status.

    I will confirm that staging is ready for you once I hear back from my client.

    Thank you and have a wonderful day.

    Lee

  • Kasia Swiderska
    • Support nomad

    Hello Lee ,

    Regarding the queued compression you mentioned, I have visited all pages on the site to see impact on the process status and it made no difference for me.

    That is strange. I was able to see an immediate change after checking just a few other pages on the site. That definitely needs a closer look on staging.

    Question for you: the object cache purge located in the Hub at “domain”>hosting>tools>object cache . Is this is same flush that would be achieved using ssh “wp cache flush” command? I ran the ssh command many times and it had no impact on the status.

    Yes, that is correct. wp cache flush command is for the Object cache on the server.

    Let me know about the staging site.

    kind regards,
    Kasia

  • Lee
    • Freelance WP Developer

    OK Kasia. The staging environment is all set. One small hiccup – I am not able to open a support portal as I’m not the one who installed the WPMUDEV Dashboard plugin. I sent you a separate email with my login credentials as per Patrick’s instructions above.

    P.S. LOVE the tattoo! :grinning:

  • Lee
    • Freelance WP Developer

    Hi Kasia.

    Did you get a chance to take a look into the staging environment? I was able to make some progress. Interesting thing – one way I was validating that the propagation was to view the hummingbird-assets folder in wp-content/uploads/ via SFTP client filezilla. I would wait a bit after publishing changes and then refresh the window and, typically, the new asset files would appear. Somewhere along the way, this stopped working (ie new files were not showing.) I would clear the asset cache and only files that were previously there would show again.

    However, on a hunch I used ssh to browse the folder and low and behold, the files were there in my command line window, but NOT showing by SFTP client window. Very peculiar behavior. Any insight into that issue?

    Also, while I was making progress in the staging environment, I re-checked my asset files available to optimize by running the check-files, and all of a sudden, I had zero assets to optimize. I tried to refresh the cache and rewrite rules but it made no difference. My hunch is that this has something to do with the password protection on the staging environment. Would that be correct? If so, how can that be bypassed so that I can optimize in the staging environment and then push to production? It seems counter-intuitive to development workflow that I would need to copy production to staging, optimize in staging, then manually make the changes back in production. I hope I’m incorrect on my assumption on this.

    Please let me know how you make out.

    Appreciate your assistance.

    Lee

  • Patrick Freitas
    • FLS

    Hi Lee

    Thank you for the credentials.

    I was able to see the issue, and the files are not being minified on the staging indeed.

    On the staging website, we don’t have object cache so it shouldn’t be the issue there.

    Could you run a plugin and theme conflict to check if any theme or plugin is preventing the Hummingbird to minify the files?

    You can find the guide for this test on the sections E & F:
    https://wpmudev.com/docs/getting-started/getting-support/#initial-troubleshooting

    Let us know the result you got on this.
    Best Regards
    Patrick Freitas

  • Patrick Freitas
    • FLS

    Hi gotsowell

    Sorry to hear this.

    We suggest always running the tests on staging, once it won’t affect the live website.

    You can use the Hosting HUB > Staging > File Manager, navigate to wp-content > plugins and rename the defender folder to _wp-defender to disable the plugin.

    It will let you login into the WordPress dashboard to run the plugin conflict test as we don’t run this on a live website.

    Let us know if you were able to run the plugin conflict test now and the result you got.
    Best Regards
    Patrick Freitas