Lou Friedman

Hi Vee,

Regarding this subject, I am using the following code in a child theme functions.php:

add_action( 'wp_enqueue_scripts', 'theme_enqueue_styles' );
function theme_enqueue_styles() {
    wp_enqueue_style( 'parent-style', get_template_directory_uri() . '/style.css' );

}

Using a style.css file within my child theme directory, I am applying styles to overwrite some bootstrap and plugin CSS. What I’m finding is that the child theme CSS gets enqueued before bootstrap and plugin CSS, but it should be the last to enqueue to maintain proper cascading and prevent use of !important in almost every overwriting CSS property.

Any ideas appreciated!

Hi @congthien.

I just updated to OnePress 1.4.3 but the issue remains. Please see the link again.

My bad. I updated the parent theme and the plugin is now working correctly. Thanks!

Absolutely. Work in progress here:

https://hgauto.staging.wpengine.com/

The bottom of the hero image sits a few pixels beyond the edge of my browser window, even when logged out.

I welcome any suggestions you might have, in customizer or CSS.

Thank You!

OK, got this sorted out. The final CSS applied is this:

.evision-social-section a[href*="instagram.com"]::before {
	content:"\f16d";
}
.evision-social-section a[href*="instagram.com"]:hover {
    background-color: #000;
}

It should be noted that the version of FontAwesome with BizLight 1.0.8 does not include the updated Instagram logo.

Thanks again.

Hello again,

The theme update from 1.06 to 1.08 fixed this issue.

Thank you.

Thanks Simon!

Re-saving the sliders did the trick!

Same problem here. I noticed that this was an issue right after upgrading from WP 4.3.3 to WP 4.5. I ran a restore on a full backup that was completed when the WP version was 4.3.3. After the update to WP 4.5, these options are missing. The restore did not properly downgrade my install, it’s still at WP 4.5 but should be 4.3.3, so the plugin failed in that respect.

I then did a manual downgrade to 4.3.3. And guess what – … these options came back.

Forgot to close issue. Thank you.

Hi Sarah,

I ran the validation again on https://lowcountrydrycleaners.com/

This time I did not get any errors on the plugin code. And the width and height are set explicitly as you described.

I suspect I copied the wrong code or the validation service I used had a bug. Sorry for the bother!

Great plugin!

Hi Darkmatter661:

The issue is this. If you, or your site editor, uploads a media item with the name “helloworld.jpg”, WP creates a slug like /helloworld/ for the attachment.

Then, if you create a post and title it “helloworld”, WP creates a slug like /helloworld-2/.

Proper training could prevent this, but there’s no recourse but to edit every last attachment, and every post slug, then properly redirect old slug names for posts, for sites that already have the issue.

This issue is also happening to me, however I cannot fix with the above described methods.

The artwork post we want visitors to see, but without the “-2”: https://mysite.com/artwork/great-times-ahead-2

The site Editor added an image called “great times ahead” before creating the post. WP created a permalink in 3 locations:

1. https://mysite.com/artwork/great-times-ahead
2. https://mysite.com/great-times-ahead
3. https://mysite.com/?attachment_id=7053

“Artwork” is a custom post type driven by CPT UI plugin.

When I tried changing the media title to “great times ahead img” the title changed, but the permalinks stayed the same.

The only way I got it to work was by editing the database, changing the post_name for the media image to great-times-ahead-3.

Then I went back into the WP backend and edited the permalink for the artwork post from “great-times-ahead-2” to “great-times-ahead” and wordpress accepted this change because there wasn’t a conflicting image-attachment with the same post_name in the DB.

After this change we get:

1. https://mysite.com/artwork/great-times-ahead = correct artwork custom post, yeah!
2. https://mysite.com/artwork/great-times-ahead-2 = 404 (needs a redirect)
3. https://mysite.com/great-times-ahead = 404 (needs a redirect)
4. https://mysite.com/?attachment_id=7053 = correct attached media

What a nightmare – we have 1172 pieces of artwork and I’m not sure how many posts are affected. Time to get editing though, our SEO is going to be diluted if we don’t!

I agree Janaa, there should be a warning before the slug is modified.

I have instructed my editors to name the images differently than artwork post slugs, but the damage is done.

Hi aware.

I didn’t try to reproduce it. Maybe I will outside of normal business hours to prevent the site from disappearing.

Let me get some logs for you. Umm, eh, where do I find those again?

When the server stopped due to 503, the godaddy rep I was chatting with stopped the PHP processes, but the memory usage was still very high.

Since this was the last plugin I had installed, I deactivated it and right after that memory fell from 500MB to 45MB. That’s me only evidence. It’s not rock-solid.

I feel like line 301 of basic.php might be the place, but need a guiding hand:

// Filter the title
		$instance['title'] = apply_filters('widget_title', $instance['title'], $instance, $this->id_base);
		if ( !empty( $instance['title'] ) ) {
			echo $args['before_title'] . $instance['title'] . $args['after_title'];
		}

Hi guys – I’m having the exact same problem when running Delightful Downloads on my dev subdomain. I tried following the steps taken above to 1)search my DB to see if the issue is there and 2)Update the code in functions.php as Ryan did to change the document root.

Findings: My DB lists the correct path: https://dev.mysite.com/wp-content/uploads/delightful-downloads/2013/10/filename.pdf

Updating the code to $_SERVER['REAL_DOCUMENT_ROOT'] has no effect.

Do I need to uninstall the plugin and reinstall for that change to take place?

Instead of $_SERVER[‘REAL_DOCUMENT_ROOT’], should it be $_SERVER[‘/dev/’]?