Forum Replies Created

Viewing 15 replies - 31 through 45 (of 70 total)
  • Thread Starter definitio

    (@definitio)

    It’s getting really weird…

    A) I have run some tests again with
    – WP Super Cache disabled
    – Logged out users
    – Video caching in Youtube Embed Options also disabled
    – “dynamic resize” and “maximum width” on

    The results
    ———–
    All three browsers: Firefox, Chrome & I9 display the above video (link also below) problematically: float value is lost and no wrapping text…

    http://tomakrypodari.gr/politiki/mesi-anatoli/gia-pollosti-fora-stoxos-vandalismon-eginan-xristianika-mnimeia-sta-ierosolyma/

    B) Running the test again with Youtube Embed caching on yielded the same results.

    C) Running tests with
    – WP Super Cache enabled
    – Logged out users
    – Video caching in Youtube Embed Options also disabled

    The same!

    D) Running tests with
    – WP Super Cache enabled
    – Logged out users
    – Video caching in Youtube Embed Options enabled

    The same!

    E) Running the same tests logged in, I had the same results with all three browsers.

    F) Running tests with
    – WP Super Cache enabled
    – Video caching in Youtube Embed Options also enabled
    – “dynamic resize” and “maximum width” OFF

    I get the video displayed correctly for logged in users for all three browsers…
    For logged out users on all three browsers the float value is not kept and text does not wrap around the video

    G) Running same tests
    – WP Super Cache enabled
    – Video caching in Youtube Embed Options also disabled
    – “dynamic resize” and “maximum width” OFF

    Like the previous test…

    Works for logged in, does not work for logged out…

    Don’t know what the f*** is going on, I am not getting consistent results, I give up.

    I am getting an error on the backend I had not previously noticed though
    Warning: Cannot modify header information - headers already sent by (output started at /home/domain/public_html/mysite.com/wp-admin/includes/template.php:1642) in /home/domain/public_html/mysite.com/wp-content/plugins/youtube-embed/includes/aye-options-general.php on line 79

    Thread Starter definitio

    (@definitio)

    Right now I don’t have another computer to test…my pc is using a Nvidia 6600GT 128mb dedicated memory VGA.
    Sure not latest technology but surely OK for web stuff…

    It’s encouraging that it doesn’t happen with your PC..

    I have to say though, that with Viper’s Video Quicktags I am not getting any such behaviour, that’s why I don;t think it’s related to my pc

    Thread Starter definitio

    (@definitio)

    I am sorry to bring this up again, but I have come to a conclusion, whether it just happens to me or not I don;t know.

    The aforementioned problem persists but only for logged in users (administrator at least)

    That is with
    1) dynamic resize on and
    2)maximum size on
    the video does not respect float (set right, floating left) value and text does nor wrap around it…

    The issues I am witnessing always involve Chrome and there are small differences depending on login status

    Here is the screenshot
    http://postimage.org/image/91i6dc3rr/

    and it’s for this link here.
    http://tomakrypodari.gr/politiki/mesi-anatoli/gia-pollosti-fora-stoxos-vandalismon-eginan-xristianika-mnimeia-sta-ierosolyma/

    Before I looked at the output once while logged in and once when logged out.
    When I was logged in, I saw it displayed problamtically as I reported and when I was logged out it displayed normally.

    Could it be a caching thing?

    I have WP Super Cache installed on my site.

    Thread Starter definitio

    (@definitio)

    I did, it’s on the link in my previous post

    http://tomakrypodari.gr/dokymanter/sikelia-i-gi-pou-aimorragei/”

    another screenshot
    http://postimage.org/image/66dtekxlj/

    Thread Starter definitio

    (@definitio)

    Seems like I just needed to clear my cache…

    Thread Starter definitio

    (@definitio)

    A screenshot for you to see
    http://postimage.org/image/jufppzhjl/

    Thread Starter definitio

    (@definitio)

    With Chrome, in the following page and all pages containing video embedded with Youtube Embed I get the flickering on the black-bars part of the player…
    With the new settings (dynamically resize and maximum size)
    – the progress bar flickering is not that accentuated as when the profile settings are not set to dynamic size
    – but the thumbnail flickering above the progress bar is just as annoying (on the black-bars area…if you click there when the video starts playing you will see it)
    – and the bottom part of the player is kind of cropped..

    http://tomakrypodari.gr/dokymanter/sikelia-i-gi-pou-aimorragei/”

    With Chrome I get those issues, not with IE9 or FF

    Thread Starter definitio

    (@definitio)

    Another Chrome thing…with chrome it displays to the left with no wrapping text

    Thread Starter definitio

    (@definitio)

    you’re right I had the “dynamically resize” option off and now I remembered why…this may be a different “bug” (or not, Idon;t know)

    It’s because if I have it on the following things happen
    without maximum size it sticks to the right side of the content and also ignores all size settings I have set in the shortcode taking up the whole area…
    if I set the maximum size, it does respect the values I have set on the backend or in the shortcode, but ignores the float setting…all space to the side of the video becomes empty.

    you can see the latter effect here
    http://tomakrypodari.gr/politiki/mesi-anatoli/gia-pollosti-fora-stoxos-vandalismon-eginan-xristianika-mnimeia-sta-ierosolyma/

    Thread Starter definitio

    (@definitio)

    Yes it does, although it is not so visible, because – as I said above – it is visible on the black bars space of the video and the video displayed on the backend takes most of the player real estate.
    But it does still occur and is visible on the edges, yes

    Thread Starter definitio

    (@definitio)

    Thread Starter definitio

    (@definitio)

    I have personally fixed several client sites problems that were caused by doing this. The problems ranged from Google assigning penalties to Google deindexing the sites pages. If you know what you are doing then be me guest. I can only tell you what I have found and fixed in my own personal experience.

    In this case, the www. site is not being indexed, nor was it indexed at any time (made conscious decisions from the start and stuck to them), so we’re not talking about deindexing penalties. In my case it was crawling errors reported.
    Still, if the non-preferred version of the site was being indexed, this does not seem possible to have been caused by the claiming of both versions of the site (with and without www.) in Google itself.
    It sounds like it could have been caused by
    – bad rewrite
    – no rewrite
    – change of heart concerning the use of www. along the way.
    In this case, there would have to be deindexing.

    Still, the option of making Google use only one of the versions of the site for the search results/links it presents to users is no bad thing and it can only be done if one claims both and explicitly sets the preferred one.
    I cannot see how this is in itself problematic, unless one sets the wrong choice in preference settings, which is not that easy to do, i.e. it’s not at all complicated.

    If Google is not crawling the www site submission then this is of course a good thing otherwise you would be in the possible scenarios I mentioned above of recovering from Google penalties and scrambling to get your website pages reindexed after Google deindexed them. 😉

    The crawl error is obviously not an “error” but a good thing. I doubt that you want Google to crawl the function.require file.

    So we’re good then! That’s great actually, cause it saves me the worrying.

    As I said my novice rationalizations interpreted this as a potential problem. Cause before the site was not being indexed either but this happened without (crawl) errors being reported, now it’s still not being indexed, but it’s reporting crawl errors.

    I thought that might mean inefficient rewrite/redirection but I’d rather be wrong than right.

    If the result is the same, I’m happy. The difference does still seem to be with how WordPress manages the www. version…is it the php rewrite making the difference between Joomla and WordPress? Let it be…

    Thank you for answers, I know I have taken advantage of your good will and taken up much of your time.

    Thread Starter definitio

    (@definitio)

    I thought you said you had a non-www site? You should not have both a www and non-www domain submitted in Google Webmasters Tools.

    I have read guides telling administrators to claim both the www. and the non-www. version of their site in Google and set a preferred choice through the dashboard settings. Google will then display their links in www. or non-www as per choice.

    I get automated warnings and notifications from Google intermittently. Some of them are valid and some are just false alerts/not valid. All warnings, messages and alerts are autogenerated by Google so some are going to be accurate and some are not. So you need to check and confirm that there is an issue/problem or if it is just a false alert.

    Yes I don’t have the knowledge to do that and have already acknowledged that I may be making novice rationalizations.

    What I am seeing is Google reporting failure to crawl the www. version of the site
    – Is this actually “good”, signifying that WP has set a global “Disallow” on ‘www.mysite.com’? Could be
    – The other hypothesis/conjecture is that the www. version is somehow now more “visible” for Webmasters Tools to report errors on it (?). Never had this thing happen before.

    I forgot to mention that in “Crawl Errors” on this site I am getting a reported failure to crawl this url
    http://www.mysite.com/function.require
    …at least that’s new and it started on the day I made the official switch from Joomla to WordPress

    I have a few questions for you. What plugin(s) are you using? What WordPress version are you using? What is your sites address?

    1) Plugins: http://postimage.org/image/c9q78gclz/
    2) WordPress 3.5
    3) http://tomakrypodari.gr

    Have to say a big thank you for your interest.

    Thread Starter definitio

    (@definitio)

    4. Don’t really know…went for the one of the most popular out there, Yoast’s SEO plugin, which also creates the sitemap.

    The error I am getting in Webmasters Tools is this:
    A red exclamation mark next to the www. version of the site and I am getting a warning to check its health, saying that robots.txt is blocking some important page. The link of that important page cited in the “details” on the right is the www. site itself.

    When I navigate in the health section for the www. site, I am told that googlebot is blocked from the www. site

    The content of the robots.txt file shown there is

    User-agent: *
    Disallow: /

    When I click the link to the ‘www.mysite.com/robots.txt’ I am instead shown the contents of the ‘mysite.com/robots.txt’ although the browser URL shows “www.mysite.com/robots.txt”. Its contents are

    User-agent: *
    Disallow: /wp-admin/
    Disallow: /wp-includes/

    Never had an error before in Webmasters Tools. I have correctly set my preferred domain to non-www from the beginning.

    Don’t know what to make of this, if there really is an issue or not. My novice rationalization may have complicated it more, confused me worse.

    Thread Starter definitio

    (@definitio)

    Thank you but the choice between www. and non-www is not my issue, don’t know if I have been vague above.

    Let me try and sum up my problem:

    1) My site has been on the non-www for two years, so I don’t intend to change it (used to be Joomla, now WP).

    2) When I installed WordPress, I went for the non-www version, intentionally.

    3) By picking the non-www version in settings, WP automatically redirects all www. to non-www

    4) I have doubts as to whether the rewrite WP is automatically doing is actually efficient

    5) The reason I think so, is that for the first time in two years, I see in Google’s WebMasters Tools errors in the www. version of the site (set to point to non-www), whereas it was totally invisible before.
    Now I am getting reports about indexing failures by Googlebot. Before it didn’t even see it, didn’t have stats for www. reported.

    6) I want to add my old www. to non-www rewrite code in WP htaccess file, but I read somewhere that because WP already does that, the inclusion of the extra code might actually cause trouble.

    So I fear WP does not do the rewrite efficiently & that adding the previously proven as efficient code might break the site in some way.

    For now I have the extra code added as you instructed me. It doesn’t seem to break anything. May be early to tell.
    My wondering was, will the extra code break WordPress, which is already redirecting www. to non-www. in what may be a not definitely efficient manner?

Viewing 15 replies - 31 through 45 (of 70 total)