Child pages
  • Automatic mod-rewrite redirecting
Skip to end of metadata
Go to start of metadata

Imported From: http://groups.google.com/group/in-portal-dev/browse_thread/thread/4657b3af9de8f9d8#

  1. I propose we redirect with 301 code (moved permanently) in case if user visits non-rewrited url, when mod-rewrite is currently enabled.
  2. Also we could redirect to "index" template (maybe with same code) in case if user just types site url without concrete page.
  3. Don't include any kind of page tracking code (e.g. google analytics), when admin is editing site contents (front-end in a frame) so page tracker won't count any fake visits.

This will make google analytics statistics more readable and google will be happy to automatically update it's search index.

Related Tasks

INP-453 - Getting issue details... STATUS

INP-438 - Getting issue details... STATUS

17 Comments

  1. This sounds like a good add-on plus we have done this somewhere
    already - just need to refactor now.

    Do you think we should include this in 5.0.3 as a bug/task or 5.1.0 is
    better?

    DA.

  2. Yes, of course. For this to work we should apply patch for GW_NOTIFY
    constant for In-Commerce. Otherwise payment gateway notification scripts
    will fail to work properly.

  3. I guess you meant we should include it in 5.1.0 since that task with
    gateway:

    531: Define additional constant to be able to identify how exactly
    processIdentification of payment gateway is called

    MINC-32 - Getting issue details... STATUS


    Is in that 5.1.0 release so far.

    However it's an In-Commerce so can be pretty much anywhere including
    5.0.3, so what's your opinion 5.0.3 or 5.1.0?

    DA.

  4. That In-Commerce task is really small. I'm voting for moving it to 5.0.3.

  5. I agree and also for 5.0.3

    Let's give it a day to see if anyone else wants to vote ;)

    --
    With best regards,

    DA

  6. Okay, time is up.

    1. Let's move this task from 5.1.0 to 5.0.3:

    531: Define additional constant to be able to identify how exactly
    processIdentification of payment gateway is called

    MINC-32 - Getting issue details... STATUS


    2. Let's create a new task in 5.0.3 for a task original Described
    here:

    Alex, would please do above things.

    DA.

  7. Done. New task created:

    INP-438 - Getting issue details... STATUS


    (0000548: Automatic mod-rewrite redirecting)

  8. Task

    MINC-32 - Getting issue details... STATUS

    was splitted and moved
    into 5.1.0 release and part of it was moved to

    INP-453 - Getting issue details... STATUS

     (0000566: Don't include
    tracking code during site content editing in browse modes) - 5.0.3 release.
  9. Thanks for doing this Alex.

    I am working on "566: Don't include tracking code during site content
    editing in browse modes" task and have a question:

    Can't seem to find "cms_DefaultIndextoolsCode_SSL" and
    "cms_DefaultIndextoolsCode" variables anywhere in install_data.sqls or
    in my local DB install.

    We are referring to them in function PageInfo($params) method.

    Did you every saw these things?

    DA.

  10. This is interesting note. I will crawl through repository history to find
    any traces of those variables myself.

  11. Hi Alex,

    Anything interesting here?

    Cheers

    DA.

  12. Haven't much time lately, will look into it next week.

  13. You were right. I've searched through our repository and there never were
    such configuration variables like *cms_DefaultIndextoolsCode_SSL* and *
    cms_DefaultIndextoolsCode* in any of our projects.

    Looks like we need to create them in proper place and maybe rename to match
    global naming ideas of configuration variables.

  14. Also there is no need to for two separate configuration variables, since
    most of page tracking code is javascript and it can determine itself (like
    google analytics code) if page has been viewed in http:// or https://. Maybe
    name "cms_DefaultIndexTools" will work out, because we have "IndexTools"
    field for categories.

  15. To be Honest I don't like IndexTools part here "cms_DefaultIndexTools"

    This variable contains Tracking Code and I think we should call it
    accordingly. Example would be:

    cms_TrackingCode

    Also I would keep SSL one as well. It not always true that it's
    checked and I think it's not too much space, but in some case it might
    be needed (not for ie. Google Analytics)

    cms_TrackingCode_SSL

    DA.

  16. What cases exactly? Those variable were missing since IndexTools
    functionality was firstly developed. Most of tracking code is javascript and
    what's not javascript could be converted to it. Since we don't have separate
    field in category table for ssl tracking code making separate field in
    configuration doesn't help much. And for google analytics we need to copy
    same code in two fields?

  17. Also we could redirect to "index" template (maybe with same code) in case if user just types site url without concrete page.

    This case wasn't processed in  INP-438 - Getting issue details... STATUS  task and I've reported it separately on No redirect from "/index.html" to "/" [5.2.2-B1].