Joel G Goodman

Thanks Ryan, my issue with that solution is in hardcoding a URL into my functions.php — as someone who develops custom WP themes and sites for clients (and has been in the community for 9 years), while this hook does work and I’ve used it, it’s not really a good practice hardcoding url and text variables into that filter, especially considering the tools WP core gives us to modify interface and field outputs through hooks.

Apart from that, I as the developer have to hardcode that location and that then bars any non-technical users of the site from making changes to the URL. It’s less than ideal.

Which I get, but it still doesn’t get Google SpeedRank off my back for loading in blocking JS and CSS assets in the head. My pages are generally lightweight as far as markup and graphics go and I’m aiming for better time to first load, regardless of the layout.

Thanks for the git link, that’ll be helpful.

I understand that, but if I’ve added an image size for another place in my theme, it’d be helpful if I had to option to choose one of those image sizes for the slider.

Another way to put it, I’m probably not going to add_image_size() specifically for this slider, but if I am already generating those images elsewhere in my theme, it would be nice to be able to use one of those custom sizes in the slider should I want to.

Oops, nevermind. My other dev had it included in mu-plugins.

This has to do with HTML/CSS validation rules. And ID can apply to only one specific element on the page while you can group elements together with a class.

So, say you had a list of links to PDFs on a resources page you wanted to track download events, you could apply a class of pdf-download to all of those links and this plugin would track the event on everything with that class. Otherwise you have to break down a separate ID for each link and manually enter them.

This is a good explanation of the difference: https://css-tricks.com/the-difference-between-id-and-class/

I have a theory…

This happened on a Multisite install. I think that my client mistakenly network-activated GF+Stripe when GF wasn’t network activated. Maybe GF+Stripe missed a check to see if GF is networked activated if that’s attempted?

Haven’t tried to replicate, but that’s my thought.

Sorry. False alarm. The WP auto-update process must’ve broken something on this upgrade.

Resolution was: removing the directory. Flushing the plugins cache. Reinstalling, activating GF, activating GF+Stripe. Not sure. Maybe a 3.7.1 upgrade bug.

Won’t be able to today, too busy. Looked like the plugin wasn’t properly printing through wp_footer(); originally. Not sure if something was hanging it up, or what, but I ran both the WP theme checker plugin and made sure debug wasn’t throwing any errors and all came up clean for my theme.

Manually writing the JSON object for the parameters and loading the addthis script via wp_enqueue scripts has worked for me, for now.

It would be nice in the WYSIWYG to be able to choose some of the share buttons included, so I probably would have needed to use the Advanced panel to get at those anyway. At that point, I might as well just load it directly through my theme functions so I can control where and when it enqueues.

Original issues exists, but since this is for a client, I’ve just gone and done it through wp_enqueue_scripts manually. And that’s working fine. Still not sure what the issue is with the plugin.

I also get this notice in the WP Admin on activation:
The plugin generated 530 characters of unexpected output during activation. If you notice “headers already sent” messages, problems with syndication feeds or other issues, try deactivating or removing this plugin.

Well… the update throws a few errors when debug is on… I guess I have some digging to do in the code.

Notice: Use of undefined constant ADDTHIS_SMART_LAYER_PRODUCT_CODE - assumed 'ADDTHIS_SMART_LAYER_PRODUCT_CODE' in /wp-content/plugins/addthis-smart-layers/addthis-smart_layers.php on line 12

Notice: Use of undefined constant ADDTHIS_SMART_LAYER_AT_VERSION - assumed 'ADDTHIS_SMART_LAYER_AT_VERSION' in /wp-content/plugins/addthis-smart-layers/addthis-smart_layers.php on line 13

Well, so I figured that part of the error out — Even if I switch back to WYSIWYG and save changes, if there was custom code left in the Advanced field, it will still load the “Advanced” custom code (that’s bad practice).

So now, you’ll see it shows up on 404, but without the settings I’ve applied in the WYSIWYG settings (should be the dark theme, not transparent).

I’m a professional theme developer. Everything I do is hand-coded to the current WP specifications for theme development using modern WordPress functions and techniques. That said, this theme was built from scratch, by me.

If you take a look, that js error that console is throwing is apart of the addThis script…

</script><script type="text/javascript" src="//s7.addthis.com/js/300/addthis_widget.js#pubid=de5052ebd24c66a8d2fe157b83e70a75"></script><script type="text/javascript">addthis.layers({
theme : 'dark',
share : {
    'position' : 'left',
    'services' : 'facebook,twitter,pinterest',
    //'numPreferredServices' : 5,
    'postShareTitle' : 'Thanks for sharing!',
    'postShareFollowMsg' : 'Follow us',
    'postShareRecommendedMsg' : 'Recommended for you'
}
mobile : {
    'buttonBarPosition' : 'bottom',
    'buttonBarTheme' : 'dark'
}
}
  );</script>

The error is caused at mobile: { according to the console readout with an error of [Error] SyntaxError: Expected token '}' (404, line 108)

And it doesn’t even load the AddThis script and markup on other pages.

Which I’m guessing is because you need a , after the share{} object…

Yeah, it had to be. That’s very odd because I’ve been running that function for years on my sites and have never run into such a large, forward-facing issue with it. Even more strange since it’s a widely used and recommended method for fixing auto formatting issues.

Oh well. Thanks for the help.

@jeremy

I figured it out. My theme was filtering wptexturize to disable auto-formatting, but too load in the function queue. Removing that function entirely fixed the issue. I’ll have to see what other problem I just created, but that was where the error was happening. Full trace below:

—

I do not use special characters in the descriptions. It happens to specific imagesin that they specifically have the description field filled out when others don’t.

I tried disabling other plugins first.

If I disable Jetpack galleries and/or use Cleaner Galleries to overwrite the settings, the images display fine.

However, when I inspect the code on that page it seems curly quotes are being injected for these HTML attributes: data-image-description (on close), data-medium-file, data-large-file, style (the first instance of this), source, title

It appears to me as though the ending quote on data-image-description isn’t being escaped after the description HTML is rendered by WP. Especially since the issue doesn’t appear on those images not containing a data-image-description.