Forum Replies Created

Viewing 14 replies - 46 through 59 (of 59 total)
  • Thread Starter Keirwatson

    (@keirwatson)

    I have found a solution.

    I have switched Yoast’s media options to “Redirect attachment URLs to the attachment itself?” -> YES

    Now the links I posted above all show as 404s, and the internal links to those images (e.g. open image in a new tab) go to the image itself and show the proper URL

    Thanks for staying with me as I unravelled this. Not sure why the images gained the strange permalink in the first place, but at least it should index properly now, and hopefully not send people to weird-looking pages!

    Thread Starter Keirwatson

    (@keirwatson)

    I have disabled two fo the three plugins, but I need to leave the SVG one in place so SVGs are displayed properly. But as this is a fixed site, I am not uploading new media files, so I don’t expect the issue will suddenly fix itself.

    NEW CLUE: When I check the images in the media library, there is a difference between the permalink and the file location. For example:

    Permalink: https://rosemarycottageclinic.co.uk/organic-acid-testing/
    File URL: https://rosemarycottageclinic.co.uk/wp-content/uploads/Organic-acid-testing.png

    Thread Starter Keirwatson

    (@keirwatson)

    Ah Ha! I realise what these are… they are images. The ones that appear just as words are the names of SVG icons, such as “my-blog” and “Fork-N-knives” which do not get displayed.

    It looks like almost all of the images used on the site are now located and accessible like this:

    https://rosemarycottageclinic.co.uk/manufacturers-2/
    https://rosemarycottageclinic.co.uk/herbal-medicines-flat-small/
    https://rosemarycottageclinic.co.uk/our-approach-infographic-small/

    Is this where wordpress usually places images? And are they usually indexed?
    I have three image plugins: 1) Add full SVG support 2) Enable Media Replace 3) Compress JPEG & PNG images
    Is it likely they have moved images around?

    Thread Starter Keirwatson

    (@keirwatson)

    Thanks. I have done that, and it found nothing except a couple of plugins that are no longer supported so I disabled them (WP Autoloader and WP super simple speed), but I don’t think they were the issue.

    Any other suggestions?

    I think the code below will work. The shortcode is used to display just one post followed by a horizontal rule. This is then repeated using offset=“1” to display the second post etc. Just keep repeating until you have the total number of posts you want on your page. By wrapping the shortcode in a div the horizontal rule should start on a new line, not half way down the image!

    <div>
    [display-posts image_size=”medium” posts_per_page=”1” wrapper=”div” offset=“0”]
    </div>

    <hr />

    <div>
    [display-posts image_size=”medium” posts_per_page=”1” wrapper=”div” offset=“1”]
    </div>

    <hr />

    <div>
    [display-posts image_size=”medium” posts_per_page=”1” wrapper=”div” offset=“2”]
    </div>

    <hr />

    Etc…

    Thread Starter Keirwatson

    (@keirwatson)

    Thanks Frank, you’re a star.

    I’ve chosen settings that give the fastest page load speeds and its quite good now. What I’m seeing though with repeated tests is that there is a lot of variation (from 0.50 sec to 4.5 s load time for the home page) which is primarily caused by varying initial server response time (Google PageSpeed reported <0.2 / 1.6 / 1.6 / 1.3 / <0.2 / 1.6 seconds)

    I can’t imagine that variability is coming from my site do you? That’s got to be host side don’t you think?

    Anyway, not your problem! Thanks again for the plugin and help.

    Happy new year.

    Thread Starter Keirwatson

    (@keirwatson)

    After spending a happy afternoon running tests and removing bottlenecks (featured images in post slider turned off) I got my page speed stats somewhat higher, but there seem to be some page errors being generated by Autoptimize (they disappear when it is deactivated)

    body.custom-background {
        background-image: url(//rosemarycottageclinic.co.uk/\/\/rosemarycottageclinic.co.uk\/wp-content\/themes\/circumference\/images\/page-bg.png);
        background-position: left top;
        background-size: auto;
        background-repeat: repeat;
        background-attachment: fixed
    }

    You can see that that ‘rosemarycottageclinic.co.uk’is duplicated in the URL making it return a 404 (after a 560ms delay) There are a couple of these during the home page load, one with ‘///’ between the duplicates and the other with just ‘/’.

    Any ideas?

    Thread Starter Keirwatson

    (@keirwatson)

    Yes: I can get your results when I’m logged out of WordPress (which means I get cached pages like you see), but they too have not shifted since using autoptimize.

    Looks like I’ve got some work to do! (Especially as I am seeing over 800ms of server response time!)

    Thanks for your suggestions – incredibly helpful.

    Happy New Year!

    Thread Starter Keirwatson

    (@keirwatson)

    Thank you for getting back to me so promptly – I was impressed over the holiday period too!

    That made it all much clearer!

    However, having installed and checked all the basic settings I was disappointed to find that my google page speed test didn’t budge (in fact it went down by an insignificant amount!), however, it no longer tells me I should minify css/html.

    The site in question is rosemarycottageclinic.co.uk

    home page (mob/desk) before: 65/64 after: 63/63

    Any ideas?

    Thread Starter Keirwatson

    (@keirwatson)

    Ah ha! Fixed it!

    This is weird… the problem turned out to be incorrect nesting in my custom css – I had one closed curly bracket missing in the first block of css which stopped everything following to not work. Weird, because the css stopped working only when I upgraded Jetpack!

    Why would upgrading JetPack cause this problem? My guess for what it’s worth, either
    1. The upgrade somehow deleted the bracket. (Seems unlikely), or
    2. The new css editor is more of a stickler for syntax, whereas the old one ‘corrected’ it on the fly so I was unaware it was wrong?

    The way I found this was in the customiser I noticed a warning message ‘unbalanced Curley brackets’ – the old Jetpack css editor didn’t do that.

    Hope this helps anyone else who is having similar trouble.

    Ah ha! Fixed it!

    This is weird… the problem turned out to be incorrect nesting in my custom css – I had one closed curly bracket missing in the first block of css. Weird, because the css stopped working only when I upgraded Jetpack!

    Why would upgrading JetPack cause this problem? Either
    1. The upgrade somehow deleted it. (Seems unlikely), or
    2. The new css editor is more of a stickler for syntax, whereas the old one ‘corrected’ it on the fly so I was unaware it was wrong?

    Hope this helps anyone else who is having similar trouble.

    So my situation should be easier to resolve as I can see the custom css, all revisions are present, but it’s not being displayed. Any suggestions?

    Hmm. I’ve just restored the backup I took before upgrading, and the site is working again. However, if I click on Jetpack support I get the same error “There seems to be a problem with your site’s ability to communicate with Jetpack! It looks like your site can not communicate properly with Jetpack.”

    Perhaps that issue already existed and is independent of the CSS breaking issues?

    I updated to the latest WP – everything fine, then updated Jetpack and custom CSS is not being applied to the site. I’ve tried deactivating all other plugins and the problem persists. When I click ‘support’ on the Jetpack plugin it says “There seems to be a problem with your site’s ability to communicate with Jetpack! It looks like your site can not communicate properly with Jetpack.”

    The CSS shows up properly in the customiser, but is not being applied to the webpages.

Viewing 14 replies - 46 through 59 (of 59 total)