psuba

Nope. Logged this issue a few months back on the GIT for the code, got some way to debugging it but no solution by anyone so far.

https://github.com/bamadesigner/cpt-onomies/issues/26

Bump – wondering if you will get a chance to have a fix?

I am living with a Debug mode for now but it is far from elegant…

Hi Mark,

just bumping this as we have now gone live with the website so I am hoping I can move to a final fixed version, without the non-minified debug JS in which I did the workaround.

Peter

Hi Mark,

So I kinda got pressured into debugging it myself as we have a deadline looming.

I found the root cause and applied a workaround that makes it work for me for now. However, it would be good if you could apply a fix because that would enable me to use your minified script and move this to production mode.

The root cause of the issue is that you apply a set width property to the original element in javascript, but you use a jquery to get the original width. The problem with this is that in my case the width is not a round number in pixels but jquery returns a rounded-down number. This is explained here for example:
https://stackoverflow.com/questions/3603065/how-to-make-jquery-to-not-round-value-returned-by-width

This causes the width of my menu to be a fraction of a pixel smaller than needed and the last item moves into the next line.

I have initially tried fiddle from line 150:

         widthSticky = $('.sticky-element-original').css('width');
          if(widthSticky == '0px') {
            widthSticky = ($('.sticky-element-original')[0].getBoundingClientRect().width);
          }

by commenting out the if clause so in all cases the width it taken by using getBoundingClientRect, but the problem is that because your script is called repeatedly, then the width gets added to repeatedly and over the next couple of seconds the bar grows to the right and out of the viewport (and I can see in the inspector window it just keeps growing all the time).

So I resorted right now to simply remove the part where you are setting the width to the original element, so instead of this:
$('.sticky-element-original').removeClass('sticky-element-active').css('position','fixed').css('left',leftOrgElement+'px').css('top',stickyTop+'px').css('width',widthSticky).css('margin-left',0).css('padding',paddingSticky).css('margin-top',stickyTopMargin).css('z-index',stickyZindex);
I just have this:
$('.sticky-element-original').removeClass('sticky-element-active').css('position','fixed').css('left',leftOrgElement+'px').css('top',stickyTop+'px').css('margin-left',0).css('padding',paddingSticky).css('margin-top',stickyTopMargin).css('z-index',stickyZindex);

I am sure you would have a good reason setting the width which probably is not applicable in my situation so for me this produces a working result, so I now have this as a workaround in place. You may need to consider whether this is universally acceptable or an alternative approach need to be made – one idea I was toying with is comparing $(‘.sticky-element-original’).css(‘width’) with $(‘.sticky-element-original’)[0].getBoundingClientRect().width and adjusting for the difference (i.e. the fraction that .css(‘width’) rounds down), but that may or may not work in all circumstances, so in the end I just thought I will let you work this out.

Hi Mark,

Sorry not trying to hurry you just checking if you got anywhere and expecting to. I may need to start looking at alternatives if this does not work, don’t want you to be in the middle of it and be surprised if I switch. Equally, I would need to allow for learning any new plugin so it would be good to be able to predict what is likely to happen.

Hi,

I wonder if you need any more information to progress – happy to help with the troubleshooting if that helps.

Peter

Hi, Debug mode enabled.

I should note that this happens under IE11 and Chrome 55.0.2883.87, but does not happen under Firefox 50.1

Also, I have tried changing some of the menu text to see if this was just pure bad luck with the combination of text content producing an odd length, but I got the same behaviour even after changing some of the menu text.

Hi,

Indeed this is in the debug.log when the debug option is switched on (it is a warning).
On reflection, I think you may be right and this may be coming from the CPT-onomies plugin probably, as I know there are other issues with caching terms that this plugin utilises after the 4.7 release. I suspect this warning is a side-effect of your plugin pulling the post info even if it is not displaying anything that I am using CPT-onomies for.

I wonder if it is possible to limit the impact of other plugins with Post in Sidebar when only displaying certain information, but I am not claiming to be an expert in WordPress architecture and have a suspicion that it would not be possible given how WordPress objects and hooks are constructed.

Jeffrey,

just to note that I have scanned my site for plugin compatibility and it flagged Widget Options with the following incompatibility. Probably nothing big, but may be worth looking into…

FILE: /home/public_html/wp-content/plugins/widget-options/includes/widgets/option-tabs/visibility.php
————————————————————————————————————–
FOUND 1 ERROR AFFECTING 1 LINE
————————————————————————————————————–
65 | ERROR | Global with variable variables is not allowed since PHP 7.0
————————————————————————————————————–

Same here…

Hi Harry,

After upgrading to 1.53, I no longer get unexpected output message, nor the PHP notice. So I think you have fixed these issues now.

Thanks for the good work!

Note that I noticed there are no version notes for the last few versions of the plugin when I am looking at the WordPress admin panel (only up to an earlier version), so you may want to add these for others.

Peter

Hi Harry,

Thanks – I think it is getting there. I no longer get all of those error messages, and things seem to display OK on the site.

There are still some notices though which you may be interested:
– I still got a warning when activating the new version of the plugin that it generated unexpected output
– I have a PHP notice in the debug log as follows (I suspect this was the unexpected output because I could not immediately see notices on the displayed pages):
PHP Notice: Undefined variable: avatar_size in /[basedir]/public_html/wp-content/plugins/harrys-gravatar-cache/harrys-gravatar-cache.php on line 238

Hi Harry,

I also call get_avatar in /include/meta.php which I guess you could rely on as a “usual suspect”.

However, I am also calling it in some specific template that I have made for a custom post type. Here is the call displaying a size 400px (quite large) avatar, and nowhere else. So I am not sure you can rely on these calls to be in specific files in all cases… so I am hoping you can solve this without trying to second guess the programmers of other plugins/themes/customisations!

Peter

Sorry I am not sure I understand what you are asking. Are you asking in which files I am calling get_avatar?

Peter