Forum Replies Created

Viewing 15 replies - 1 through 15 (of 124 total)
  • By the way.
    This solution would have been found easier in my new closed topic:
    Close to the top, or in some STICKY or well named topic which nobody did yet.

    Here it’s buried under 20+ posts about what didn’t fixed it. If you are a internaut you know just a few get down here.

    Oh, wait… such a straightforward topic would alert of something not working in WP, and probably will be quickly deleted or never posted.

    WP community is priceless. Passing the moderators to get to them, costs an arm and a leg.

    Jan: Thanks for your help
    You are helping, and those I’m talking about, they know it’s about them. It’s mostly moderators/programmers who have both power to shut up people and the workload when others find each-other with the same bugs.

    And this is not an exception: I FIXED IT.

    It’s a known bug, but seems easier to write two lines and close my topics than sending a link to the bug.

    The problem is post_name values are NOT updated for all the existing posts when you switch from ugly to pretty permalinks. I don’t find so bad to take care of the urgent emerging issues fist and the rest later, but covering up and abusing of moderation power really bothers me.

    So it works as far as your posts were created AFTER your (pretty) permalink settings.

    I figured it out trying to make my own permalinks, and nothing worked for get permalink, nor post->post_name, nor nothing. AND since the comparisson between the requested url and the returned one fails to match because post_name doesn’t have a pretty permalink, even single posts and pages included a canonical link.

    Now every plugin for canonical links work, but they are not needed, because since WP 2.9 they come in the box.

    For every user that was ignored and told the missing slug updating “is not a bug” and WP works “as intended”, instead of give help and admit should be done so other things (and plugins) work, here’s the plugin you need to run to patch the WP hole and re-generate them:

    http://wordpress.org/extend/plugins/rp-recreate-slugs/

    esmi: Nobody said you did.
    Close this topic if you don’t want to have two for “the same” issue, and re-open the other please. This one is finished for me, and I need to address the issue in a different way, as the other post said.

    Dan:
    I’m not saying the rules don’t work. Regex are ment to work.
    I’m saying THEY DON’T DO A THING in a WordPress installation with no plugins.

    I just tested and re-tested the blog and everything works THE SAME without your rules. If you have another idea of something I can reset/clear to triple-test they are not still being applied… as I said, I REMOVED them all, and all works the same. Urls are guessed, even inside blog/, so your (and mine) rules are useless.

    The whole problem seems to be completely un-related to the rewrite rules.
    I’ll try to remove the canonical links, but I’ll create my own, pointing to where they should. If I have to do that, it means WP canonical is a joke and won’t work.

    esmi:

    That’s it. Stop it guys.

    YOU KNOW long discussions like this are not of interest for nobody anymore, and will be forgotten until some day in a few MONTHS some desperate user with the same LITTLE idea of how to fix it (and help me) will probably contribute with ANOTHER QUESTION or bump… and you STILL FORCE ME TO STAY THERE? (closing the new one I just opened).

    And then, when I DO want to leave a discussion open ON PURPOSE to get another opinion other than the ones from the same 2 moderators who exhausted their power to “convince me” of their point of view or shut up… you CLOSE IT?

    So… why don’t you just give us your script so we can all help you to run the show you want in “your” forum and we save some time?
    That way I can post all happy WP features, help others to shut up or submit a quiet ticket nobody notices, or convince them they should work as you programmed and no change is good…

    I’m tired of moderator’s abuse. If you don’t like my questions and points of view, LEAVE THEM OPEN. You are not the only sources of knowledge here. Even less the only source of opinion diversity.

    If you are SO TIGHT about rules, OK, DELETE THIS ONE, and reopen the other. This is useless, and if you consider it’s of use for others, then DON’T FORCE ME to take it as the solution to my problem, and move to ANOTHER POST that better describes what I need.

    Let me guess: This issue was already found in WP core and you prefer nobody talk about it until fixed, right?

    Jan:

    I just removed ALL the htaccess rules (other than WP’s) and waited many hours, even removed my computer’s DNS cache, to be double sure and confirmed they are not working (.html files are not found) and:

    ALL OUR RULES WERE DOING NOTHING.

    All the above behaviors remain the same:
    Pages like /?p=287 remain being redirected to /287
    /287 keeps redirecting to itself.
    canonicals remain not pointing to /post-name

    So, excuse me, but I’ll post this again. When others see a topic like this they think I’m being taken care of and won’t get involved in a discussion at this stage.
    Thanks for your time.

    Are there other rules above the one’s I suggested? If they are they may be sending the request to a cached copy such as with WP Super Cache or W3TC.

    No. Not other rules besides default WP below these.

    So no penalty. 301 -> 301 -> 200 is fine.

    Ohhh… I get what you mean. The problem is you are browsing a PAGE, not a POST.
    /123 works different for pages/posts.

    I was testing a post page, that were under /blog/
    Pages didn’t move, just dropped the .html

    My test shows:
    /blog/287 301 -> /?p=287
    /?p=287 301 -> /287
    /287 301 -> /287
    … and that’s a dead end.

    A request for http://site/123 gets 301 redirected to http://site/?p=123 via [R=301,L].

    The browser then requests http://site/?p=123 and is once again 301 redirected to http://site/some-slug-here via [R=301,L].

    The browser then requests http://site/some-slug-here and the web page is delivered with a http status code of 200.

    Yes, I understood your explanation before. That’s why I got so exited 🙂
    But that’s not happening.

    When I request
    http://biscaynebayfishing.com/blog/287

    It is successfully converted to
    http://biscaynebayfishing.com/287

    and then it shows me the right content for the post-ID 287, as if I had typed
    http://biscaynebayfishing.com/287 in my browser
    which was already working, thanks to WP guessing magic.

    and THEN…

    Unfortunately, the process ends there, and the url at the address bar is the above one, as well as the canonical. No slug / pretty permalink is retrieved / shown / canonicalized.

    The url and canonical link stays as
    http://biscaynebayfishing.com/287

    I need to fix that asap.

    Hehe, excuse my english, I was not opposing, but making sure we are talking about the same thing or figuring out if I missed something.

    The page called with /123 is showing the content for post-ID 123 correctly, but not showing /post-name either in the url or the canonical.

    Isn’t that an issue?

    I think it’s great to “predict” what the visitor tried to see, but there can’t be different canonicals for the same content. All of them should point to /page-name. Shouldn’t them?

    I don’t want to disable the canonicals! I just want either:
    1) canonicals point to the right place
    2) Return /post-name in the url so no canonical is needed.
    3) disable /123 prediction at all if none of above is possible.

    But it’s not damaging

    Yes, it is. I was talking about serving a page with /123. Those posts are showing that url in the canonical (not even /?p=123), instead of “/post-name”. That’s duplicate content.

    Which takes me to the subject of this post: If I can’t get WP to generate the proper canonical, how do I PREVENT wordpress serving those pages? Those URL don’t really exist, so if I can’t canonicalize them or redirecting them to /post-name (AND showing /post-name in the address bar) , I’d prefer to deliver a 404.

    I haven’t had time yet to understand exactly how a redirected page shows the requested or the final url in the address bar.

    Good work jan. The explanations are something I always wanted when learning regexes 🙂
    Still not there, though.

    This code is better than mine in the sense that this one does redirect the number-trailing URLs.

    Although the query string url stays with the number, and doesn’t include the canonical, which I don’t know if that’s a WP “feature” is damaging our blogs with duplicate content?

    You just reminded me that “existing files and folders” don’t include WP pages, because they don’t exist until the WP rules below.

    Should I hack the core for that? :S

    Yes, That’s what I did for now. I’ve put it in the header.php file, but eventually I’ll make it a plugin, so I need it to work from a function outside the theme.

    I will try the wp_head. I hope I don’t bother whatever wp_head needs to return.

    Nice!. Thanks Jan Dembowski

    Here it goes:

    If url contains /blog/ followed (and ending with) by a number
    but not /blog itself
    Redirect to current domain/?p=number
    # (Should we make it the last rule? I don't know how WP manages to deliver a pretty permalinked page)
    
    If url contains /blog/ but not /blog for not-found pages
    remove /blog (find the pages in the root domain
    If still not found remove any .html trailing

    Which is basically what the previous redirects were doing (the query number rule not working yet)

    I still would like to know how to prevent WP deliver pages in any other way not pretty permalinks, just in case robots or idiots index a page like domain.com/123 (It was indexed so obviously was not serving a 404.)

    Thanks.

    PS: I always try to make the ruls NOT containing a hardcoded domain, just in case I have to move it, rehuse it, or simply test it somewhere else other that thisdomain.com

    I think I need a little more complex rules, because the /blog/ is not the only thing I need to cover the old pages redirection. I need to remove the .html too.
    Also the old site ALSO had this issue, and still needs be addressed. (The page got indexed and is sending visits like that.

    I tried this rules, no success.

    # Redirections for static pages made dynamic
    RewriteEngine On
    # Try query string page numbers first
    RewriteCond ^/blog/%{REQUEST_FILENAME}$ f
    RewriteRule ^/blog/(\d*)$ /?p=$1 [R=301]
    
    # Try try removing /blog/ from url first
    RewriteCond ^/blog/%{REQUEST_FILENAME}$ -f
    RewriteRule  ^(.+)  /$1  [R=301]
    # If not found, try removing html
    RewriteCond %{REQUEST_FILENAME}\.html !-f
    RewriteRule ^(.*)\.html$ /$1 [R=301,L]

    PS: the default WP code is there, at the end.

    Well, not necessarily. I don’t care if /123 is not redirected to /?p=123 as far as WATEVER is retrieved has canonical link pointing to /page-name or a proper 404
    I’ll try your suggestion in .htaccess as soon as I get a regex working (I suck at apache’s regexes)

    Anything that avoids a duplicated content issue would be fine.

    The site is biscaynebayfishing.com.

    and I created these rules before WP’s in .htaccess file when moved the blog to the root (and created a /blog page)

    # Redirections for static pages made dynamic
    RewriteEngine On
    # Try try removing /blog/ from url first
    RewriteCond ^/blog/?%{REQUEST_FILENAME}$ -f
    RewriteRule  ^(.+)  /$1  [R=301]
    # If not found, try removing html
    RewriteCond %{REQUEST_FILENAME}\.html !-f
    RewriteRule ^(.*)\.html$ /$1 [R=301,L]
Viewing 15 replies - 1 through 15 (of 124 total)