Mandi

Wow, that was fast. Tried it out and all is working great. Thanks for the quick fix for this. ??

Sorry to chime in, but I have same issue. It looks like they forgot to change the version number in the main file. It still says this:

* Version: 1.7.14

Welcome, and good to hear. Thanks for all the work on the plugin btw. Really makes a huge difference. ??

You’re welcome. Also thanks again for all the hard work putting Youzify together. ??

No problem.

The problem is solved on my end, but there is a definite bug with the 1.2.9 update in the above reference to that code change at line 615 on youzify/includes/public/core/class-youzify-account.php

Others will have the issue too until its updated adding in echo after the esc_attr (without echo the div classes are blank)

I think I found the change that causes the div class to no longer appear. Something to do with this part of the changes, from 1.2.8 to 1.2.9

Index: youzify/trunk/includes/public/core/class-youzify-account.php
===================================================================
--- a/youzify/trunk/includes/public/core/class-youzify-account.php
+++ b/youzify/trunk/includes/public/core/class-youzify-account.php
@@ -613,5 +613,5 @@
                 <div class="youzify-head-buttons-inner">
                 <?php foreach ( $header_buttons as $key => $button ) :?>
-                    <div class="youzify-button-item youzify-<?php echo $key; ?>-button" style="width: <?php echo 100 / $count; ?>%;"><a href="<?php echo $button['url'] ?>" data-youzify-tooltip="<?php echo $button['title']; ?>" ><i class="<?php echo $button['icon'] ?>"></i></a></div>
+                    <div class="<?php esc_attr( 'youzify-button-item youzify-' . $key .'-button' ); ?>" style="width: <?php echo 100 / $count; ?>%;"><a href="<?php echo esc_url( $button['url'] ); ?>" data-youzify-tooltip="<?php echo esc_attr( $button['title'] ); ?>" ><i class="<?php echo esc_attr( $button['icon'] ); ?>"></i></a></div>
                 <?php endforeach;?>
                 </div>

I added echo in front of esc_attr and that makes it work again as it was before. Like this:

<div class="<?php echo esc_attr( 'youzify-button-item youzify-' . $key .'-button' ); ?>" style="width: <?php echo 100 / $count; ?>%;"><a href="<?php echo esc_url( $button['url'] ); ?>" data-youzify-tooltip="<?php echo esc_attr( $button['title'] ); ?>" ><i class="<?php echo esc_attr( $button['icon'] ); ?>"></i></a></div>

With my temporary css fix, it makes it look like this. Buttons no longer colorful, but at least the align up correctly and use the Youzify scheme color.

The div claases for those buttons went missing on version 1.2.9, all other versions that area appeared normal. This is the after

I can and will do that. I do have another that is still on version 1.2.5, so I am going to download the other versions and update it one by one and see which one causes the change.

This is the before, with red arrow showing what does change (the buttons on profile settings page)

Will post the after, when I get to the version that takes the buttons div classes out for reference to when that happened. This is on latest WP 6.6.1 and latest version of Buddypress.

The 125.05M figure came from the CloudLinux manager, which is in the WHM panel. For that it is kind of unclear what all it actually monitors. This is what I found out:

Memory usage: CloudLinux monitors your account’s virtual and physical memory usage.

plus this extra info: To determine your account’s current memory usage, log in to cPanel. On the cPanel home screen, under Stats, locate Virtual Memory Usage and Physical Memory Usage. Please note that the Physical Memory Usage value also includes disk cache usage, so the actual amount of physical memory usage is not entirely accurate. If the actual amount of available physical memory ever runs low, however, CloudLinux automatically frees the disk cache memory.

For query monitor on my test site refreshing a station page (its got a backup of the radio plugin that was on here last year) the results were:

WP 6.6

Page Generation Time

0.2893s
0.2% of 180s limit
Peak Memory Usage

23,997,736 bytes (22.9 MB)
1.1% of 2,048 MB server limit
Database Queries

0.1822s

74 queries

WP 6.5.5

Page Generation Time

0.2958s
0.2% of 180s limit
Peak Memory Usage

23,839,904 bytes (22.7 MB)
1.1% of 2,048 MB server limit
Database Queries

0.1692s

75 queries

Front end (query monitor) looks good for both, just that back end (what CloudLinux manager says) that increased a lot. This is the section of it I monitor for that usage:

https://docs.cloudlinux.com/shared/lve_manager/#current-usage-tab

That must be similar to Query Monitor plugin? I was trying that plugin out to see the front end memory use, and that looks good. Around 23 to 24MB use all over my test site. It’s the back end use that increased. Server side after a few refreshes it says 125.05M, on that site it would have been approx 75M prior to the update. I’ll have to roll back the test site to 6.5.5 and do a few refreshes and observe the front end use, and also the sql query count. Is there more cache in the updated version perhaps? That would be a possible explanation of the increase in the back end server side memory use.

Guess to reproduce the issue is to install fresh WP 6.5.5, then go into your WHM and then go to the CloudLinux Manager, there is where it says the current memory and cpu usage for the sites running on the server, refreshed on a 10 second interval. Alternatively through Cpanel use the Resource Usage feature. Have it on for a while, then update to 6.6. For most of the sites doing that alone caused a memory increase to nearly double.

I did try default theme and there was no change in excessive use.

Themes in use on the sites are Sydney, Tentered, Obelisk, PopularFX (all experiencing the major increase of memory use)

All required modules are installed for php 8.0. All databases are the current InnoDB format.

Only thing I found so far is commenting out that html5-named-character-references.php file and refreshing server OPCache and Redis makes it use 25MB less memory. Not sure why that file uses so much for just one file, and if anything else is associated with it causing the increase.

Hi again. Looked at all that and have some optimizations in place for speed and resource reductions already. The page loading speeds are fine. What isn’t is the increase of memory usage on the server side. One of mine, for example, was only using a bit less than 80MB memory with WP 6.5.5. After the WP 6.6 update memory usage increased to 150MB plus, with no way of getting that reduced.

I did see some issues with the html5-named-character-references.php file, so I commented that out in wp-settings, then forced cache refresh on the server and that got it down to 125MB use. Still its not close to where it was before. Its a significant increase when you have a few WP’s on the server, the difference between doing well, and the possibility of having to get another to offset the memory use increase (will likely be going back to 6.5.5 until the memory leaks – inefficiencies are fixed up)

Hi again. Sorry for the delay. Got busy with other things, life, ect.

I was referring to the Youzify profile page actually. But on that site I deleted the BP Classic plugin as its no longer needed with the current Youzify. I did get that re-installed to see what it did, and it made the Learnpress – Buddypress integration work again with all the other pages shown within the Youzify profile page, with tabs to link the different sections. However BP Classic messes with the current version of Youzify.

Seems that the LP – BP integration plugin needs to be updated to work without BP Classic. Which is not any issue with Youzify. Topic here is resolved. ??

Update, only solution I could find was to do backup of the css changes, do a complete uninstall of the plugin and reinstall it then add back in the extra css. Its working great again. Looking forward to the new PM feature. Nice extra feature to have. ??