Dave Liske

Hi pwit, I haven’t been able to duplicate this issue yet. It sounds as though my CSS is possibly conflicting with theirs, but I’m not sure. Can you post the URL to your site please? I’d like to look at the source for the page to possibly see if the different CSS are loading properly.

If you look toward the bottom of global-content-blocks.php in version 2.1.3 (the new version) you’ll find this:

function gcbEndSession() {
if(!session_id()) {
session_destroy ();
}
}

What I’d done by mistake in earlier versions was this:

function gcbEndSession() {
session_destroy ();
}

If this is causing an incompatibility with iThemes Security Pro I’ll be glad to make reasonable changes they recommend. We need to get this taken care of, I consider it a priority. Please keep me posted.

“Shortly” as in, it’s already uploaded to www.ads-software.com. Just waiting for it to propogate, should be any minute now.

imagineds, my apologies, that was a simple error on my part. I wasn’t checking that a session ID was still invoked prior to destroying it, and if another plugin had already destroyed said ID, well, that generates the error you’re seeing. I’m finishing up version 2.1.3 specifically to address this problem, and should have it uploaded shortly.

balvan64 I’ve been looking into this issue and have finally located the most-likely problem. Looking at the source code for the page you linked to:

<!– This site is optimized with the Yoast SEO plugin v3.0.3 – https://yoast.com/wordpress/plugins/seo/ –>
<meta name=”description” content=”[contentblock id=hmn_yanagibas_oct] [contentblock id=17 img=gcb.png]”/>

What happens is that Facebook scrapes the meta description (or an og:description if you have that set up instead) and loads it as the description for their link. That’s probably what you’re seeing happen, especially since this is the only place the shortcodes appear when viewing the page source. This is a known issue with the Yoast SEO plugin, as described here:

https://github.com/Yoast/wordpress-seo/issues/2846

Looking at their changelog, it appears the fix has not yet been implemented. If you’re so inclined, the solution is also listed on the above linked page. I haven’t tried it myself, so I can offer no guarantees. But your issue is definitely reproducable with the current version of the Yoast plugin installed.

kristianserrano I apologize for the delay in looking into this issue. Which method are you using for the emails? The method in Jetpack is the default, but there are also a number of plugins available for the same functionality, that’s why I ask.

Hi cascompany … In looking into this issue over the past week I’ve included code similar to your override_mce_options example, which now retains most if not all HTML code as written. However, the Link tag is an issue unto itself. TinyMCE is removing this to stay compliant with HTML5, which doesn’t allow the Link tag in the Body of a page. That’s not something I want to orverride whatsoever.

Having said that though, it looks as though you need to be able to use a custom CSS. That’s not only something I want to include, it’s also needed for a fork project I’m about to start. I was going to include a Textarea field on a Settings page to keep the custom CSS in the database, but I think it’d be better if users such as yourself could instead add their own file, I’ll call it customstyles.css, to the CSS folder. I’ll then include code to load it in the header of the page, with a selection on the Settings page to load it either before or after the plugin’s own CSS, your choice. I won’t include a customstyles.css file with the plugin, ensuring I don’t override during updates.

//// Your other request for a %%variable%% dialog … I’m considering it, but that’s not something everyone would want to see. I could probably include a way to Opt-In if you want that function turned on, but I’d question how many other users need that functionality.

I’m going to mark this as Resolved since the first issue is taken care of. If you’d like people to get in on the conversation on the %%variable%% issue, which I wouldn’t object to, please feel free to start a separate thread.

Dave

You’re welcome, glad to be of assistance. ??

thisisbbc, version 2.1.1 is ready for installation. As I don’t have an HTTPS environment I’m hoping this is the fix you’re in need of.

Dave

thisisbbc, I’ve found the plugin is using the older WP_PLUGIN_URL instead of plugins_url, which is encouraged viz the Codex. I’m finishing testing the fix in global-content-blocks.php and should have a new Commit uploaded soon for what will be version 2.1.1.

Hi Simon, it’s only been tested through PHP 5.4. But because of your question we’ve begun this testing on a separate PHP 7 installation. I’ll mark this as Resolved once the testing is complete.

vlad13, this is included in version 2.1.0. Again, thank you.

Hi cascompany, this is an issue I’ve run into regularly over the years. The plugin uses the TinyMCE editor for WYSIWYG editing as do many other plugins. I’ve developed a tendency to never switch to the Visual tab. Instead, I have the site I’m working on open in another tab in the browser, and constantly keep the Text tab open in the editor. Once I update something, I then refresh the site in the other tab in the browser to see how things are looking. Kinda clunky, I know, but it’s the only method I’ve been able to trust. I’ll be looking into some things I’ve found in an attempt to fix this in the plugin. But since it’s such an ongoing issue, I’m not so sure of how this will turn out.

Thank you, I’ll use this in testing the issue.

Hi Bobby … I have some projects I’m preparing for where I need the same layout. benz1 suggested tables, which works well. But for the next release I’ve also added a CSS to the plugin that will make created dual- and triple-column simpler. I’ve added both the table examples and views of the working beta of the CSS solution o the plugin’s new web site. You can view them on the Advanced Usage page at:

https://micuisine.com/content-block-plugins/category/gcb-advanced-usage/