Heyitsrick

Your “Before and After” row doesn’t look responsive to me. I’m talking about the brown row that says “View Before and After Rhinoplasty” It’s not collapsing correctly. You can see in mobile that it’s not centered at all and isn’t reformatting for the smaller width.

I would temporarily remove that visual composer row and check the mobile look again.

Hi, thanks – that took care of one particular background/shadow. I still had them at the bottom of my content, so had to go looking for more.

I found them in two places. One was in a background URL in a pseudo ::before element for the #wrapper id, and one was a background URL for the home-content-boxes (front page widgets).

Here’s what I used for the home-content-boxes to get rid of the background image:

.home-content-boxes {
	background: none !important;
	}

Here’s what I used to get rid of the background URL in the #wrapper id:

#wrapper::before {
	background: none !important;
}

Go into “Theme Options”. Go into “Styling”. Check the box that says “Disable Menu Background”. Save changes.

My link titles weren’t displaying when I first posted this (my bad), so if you’re reading these responses in email, go to the actual support page you created as I edited the post and now the links are displayed.

I see you switched to another slider on your site. Unfortunately, it takes a while to load up and that’s not what you want when people first visit your page. I know it’s frustrating, but you should really try to get the Bootstrap working. The Evolve support guy makes it sound like if you’re not setting up the Bootstrap Slider in the Theme Options panel, it might not work right. Read below:

You didn’t mention if you had the “Theme Options” panel available to you. The recommended plugin that enables this Theme Options panel is the “Reduxframework” plugin as prompted in your WordPress admin.

That’s the plugin the Evolve support guy told another person posting a bootstrap slider issue to make sure he had installed, and once installed, use the “Theme Options” panel to make all Bootstrap Slider choices, vs. the “Customize” panel.

Here are some links to photos I just took to show you exactly what plugin and where the Theme Options panel is in this theme. Maybe you’re already using this – I don’t know – but just want to be clear.

First, you need the Reduxframework plugin. If you don’t have it installed, you’ll be prompted at the top of the admin panel to install it. Here’s what it looks like in your plugins when it’s installed:

Redux Framework Plugin

Once installed, you need to open up your “Theme Options” panel. That’s located under the “Appearance” menu. See this screen shot – I circled Theme Options in yellow:

Theme Options Menu Item

Now, click on Theme Options and scroll down to Bootstrap Slider. THAT’S where the theme support people want you (and everyone) to make their Bootstrap Slider options. Here’s a screen shot of mine, but I only show the first image here (otherwise the photo/screen shot would be very long), but this shows you what I’m talking about. You just go through the same process with multiple images as you do for the first, of course, in terms of filling out the information for the slider:

Theme Options Opened Up

Sure – it’s a development site right now. I was under the impression that this was a universal feature so didn’t post the site before.

https://dev.cryderpoint.com

Look at the bottom of the home page. There’s a line that I described under the “home-content-boxes” div, and there’s another one shortly there after in a blank area. (I’m hiding the footer.)

Same when you look at the “Welcome” page. It just seems like all content in this theme has a baked in divider line at bottom that’s decorative, but I’d like to be optional in places.

Are your slider photos in order with no skipped numbers? For example, are you using slider 1, slider 2, slider 3 and slider 4, vs. something like slider 1, slider 2, slider 4, slider 6, etc.? Are all the photos you have in the slider displaying? I mean can you double check to see that you don’t have one in there in the admin panel that’s not actually showing up in the slider?

Can you refresh the theme, itself by reinstalling it? Is it the latest version of the theme (there have been updates, even to the free version). Do you have the “recommended” plugins that Evolve wants installed?

These are just things I’m thinking of off the top of my head.

Edit: I also noticed the theme author told another person with a Bootstrap Slider issue NOT to use the “Customize” option that’s in WordPress, but rather use the “Theme Options” (Look under Appearance for “Theme Options”, and then once you click on that, click on “Bootstrap Slider” down the list.

It looks like you have several sliders on this page – the Bootstrap slider – as well as what appears to be “Site Origin” sliders. I’m going to guess that the Bootstrap slider might be having its timing thrown off by the other sliders and their code.

Can you create another page that has nothing on it but the Bootstrap slider and label that page (temporarily) as your Home page? See how the Bootstrap slider works then.

Just looking around at the AddThis code, and it appears these ASCII control characters are intentional (although I’m sure not where they are ending up, lol). There are references to these control codes in at least one of the AddThis PHP files and at least one AddThis Javascript file.

Here’s a code excerpt from the “add-divs-to-coded-excerpts.js” file:

/**
 * Queries window.document for a 3-letter non-printing code
 *   The order of the code identifies a type of excerpt (archive, category, etc).
 *   Inserts sharetoolbox and recommendedbox divs on either side of the excerpt.
 *
 * @alters window.document
 */
function addDivsToCodedExcerpts() {
    var excerptNodes = getDocumentNodesWithCode();
    for(var i=0; i<excerptNodes.length; i++) {
        var excerptNode = excerptNodes[i];
        var excerptCode = excerptNode.data.substring(0,3);
        var suffix = "";

        if(excerptCode === String.fromCharCode(5,6,7)) {
            suffix = "-homepage";
        } else if(excerptCode === String.fromCharCode(5,7,6)) {
            suffix = "-page";
        } else if(excerptCode === String.fromCharCode(6,7,5)) {
            suffix = "";
        } else if(excerptCode === String.fromCharCode(6,5,7)) {
            suffix = "-cat-page";
        } else if(excerptCode === String.fromCharCode(7,5,6)) {
            suffix = "-arch-page";
        }

That’s not the complete function – just showing some of it to show the ASCII codes 5, 6, and 7 are used to identify and alter with surrounding divs various types of WP page excerpts.

AddThis: I don’t know if this matters, but just poking around your add-divs-to-coded-excerpts.js code, I see that you’re doing a regular expression match search on line 15 where you explicitly list the repetition by using the {3} parameter.

Code: if(data && data.match && data.match(/[05-07]{3}/g))

However (and again, I don’t know that this actually matters or not) later you don’t specify a repetition when you’re replacing those character codes with empty strings on line 72:

Code: excerptNode.data = excerptNode.data.replace(/[05-07]/g, "");

(repeating this reply from a separate post by sevensoutbill in this forum)

Having the same issues when the latest AddThis plugin is activated.

We had to troubleshoot why our WordPress feeds weren’t working today, and there are three ASCII characters that are included in the <description> tag of our RSS feeds generated by WordPress when the latest version of the AddThis plugin is activated. (We probably didn’t notice the broken feeds when the plugin was first updated a couple of days back).

Important: Actually, it’s not really the RSS that’s the problem – these ASCII characters are being injected into the post source code, so it’s just that the RSS is breaking because the source code itself is bad from whatever AddThis is adding.

We’re seeing this in any page/post that has summaries/excerpts while AddThis is activated. What happens is that in the summary/excerpt, the first <p> tag gets three ASCII control characters after it, the ACK ENQ and BEL character codes. You can plainly see them when looking at the code in a text editor.

sevensoutbill: Find a page of yours (like a category page) that has excerpts or summaries. Copy the page’s source code into a text editor. See if you don’t see those ASCII characters right there in the source code after the first <p> tag like we’re seeing with AddThis activated. Once we deactivate AddThis, those ACK ENQ and BEL characters that immediately follow the <p> tag go away and the code looks clean (and hence, the feeds work again).

I can corroborate what sevensoutbill says above. We had to troubleshoot why our WordPress feeds weren’t working today, and there are three ASCII characters that are included in the <description> tag of our RSS feeds generated by WordPress when the latest version of the AddThis plugin is activated. (We probably didn’t notice the broken feeds when the plugin was first updated a couple of days back).

Important: Actually, it’s not really the RSS that’s the problem – these ASCII characters are being injected into the post source code, so it’s just that the RSS is breaking because the source code itself is bad from whatever AddThis is adding.

We’re seeing this in any page/post that has summaries/excerpts while AddThis is activated. What happens is that in the summary/excerpt, the first <p> tag gets three ASCII control characters after it, the ACK ENQ and BEL character codes. You can plainly see them when looking at the code in a text editor.

sevensoutbill: Find a page of yours (like a category page) that has excerpts or summaries. Copy the page’s source code into a text editor. See if you don’t see those ASCII characters right there in the source code after the first <p> tag like we’re seeing with AddThis activated. Once we deactivate AddThis, those ACK ENQ and BEL characters that immediately follow the <p> tag go away and the code looks clean (and hence, the feeds work again).

Hey, no problem. Thanks again for the documentation links. And funny about the virus.mp3 example. Should have known that. We’re going to be moving away from the old WP Audio plugin ourselves, but need to get a couple of things in place first. Thanks for chiming in.

@electblake – Appreciate the links. However, your method doesn’t work for me. While I can see the link itself in visual mode after editing/composing the post, I don’t see the brackets, or the audio keyword, etc., if I go back into visual editing mode. Plus, the mp3 link you posted to dubstep.info is dead, anyway, lol.

Remember, this post is about people who are still using the WP Audio Player plugin that uses an audio shortcode. You’re quoting how to embed an html5 native audio player in WP. While I know that’s an option, we (for our own reasons at present) are using the older WP Audio Plugin and the latest WP update broke the way the WP plugin shortcode displays when in visual mode (the player itself still works fine).

Here’s a sample working mp3 link that anyone can test:

[audio src="https://www.tonycuffe.com/mp3/cairnomount.mp3" /]

Using your method:

[audio src="https://www.tonycuffe.com/mp3/cairnomount.mp3"] doesn’t work for a couple of reasons. First, after editing you only see the link itself when in visual mode. So, you don’t see [audio src=" "]

More importantly, while the old WP audio player does display when previewing the post or looking at the published post using your syntax, it always returns “File Not Found” for the audio cut.

My workaround is to just capitalize the “a” in “audio”, so it would be seen like this:

[Audio: https://www.tonycuffe.com/mp3/cairnomount.mp3]

Using this method, you see the entire shortcode in either visual or text mode, and the WP audio player displays and finds the track fine.

Here’s how the test mp3 syntax above would look with additional WP Audio Player (the old plugin we’re using) parameters, such as title and artist info, as well as counting UP the time, vs. counting down:

[Audio: https://www.tonycuffe.com/mp3/cairnomount.mp3|titles=Test MP3|artists=Tony Cuffe|remaining=no]

We have a suspicion (just a theory) that “audio:” is now a reserved shortcode in WP 3.9.

As an experiment, I tried capitalizing the “A” so my shortcodes started with [Audio: instead of [audio: .

Guess what? They showed up fine in visual mode, AND they also worked in that the actual audio player displayed normally.

You can try that yourself and let me know if it works for you. If you really needed to edit older posts for some reason, you could probably do a global search and replace to capitalize the A (assuming capitalizing it works on your end). But it’s most helpful when creating new posts, obviously. Old posts are already in play unless they need to be edited, and, of course, switching to text mode is also a clunky workaround.