Ceon URI Mapping v4.x

mc12345678:

I'm not sure why you think or are saying that new products, or any of the items in the upper menu are considered ez-pages as they all point to static pages which require manual entry into the ceon_uri_mappings table. (See instructions).

As per my previous response, these are internal links that are part of the EZ Pages top menu.. You add these internal links using the EZ Pages function (which IS allowed). However this module will NOT generate URIs for EZ Pages internal links..

DivaVocals:

There are posts from the original author on this.. If you are using EZ Pages for some of the store pages (new, featured, specials, all products) this module will NOT create a URI for these kinds of EZ pages.. There are instructions in the readme for creating URIs for pages that are not auto-generated..

Well, yes, I did go through every active EZ-page and generated the URI's, or do you mean something else?

DivaVocals:

As per my previous response, these are internal links that are part of the EZ Pages top menu.. You add these internal links using the EZ Pages function (which IS allowed). However this module will NOT generate URIs for EZ Pages internal links..

Ah, just saw your response now, so the module won't work at all for my ez-pages links? Is there a workaround?

pexter:

Ah, just saw your response now, so the module won't work at all for my ez-pages links? Is there a workaround?

Follow the instructions in the readme for this module for adding URIs for pages like new, featured, specials, all, etc..

pexter:

Ah, just saw your response now, so the module won't work at all for my ez-pages links? Is there a workaround?

DivaVocals:

Follow the instructions in the readme for this module for adding URIs for pages like new, featured, specials, all, etc..

Following the instructions will resolve both issues, but the direct answer for can this program work with ez-pages, the answer is yes it does, there are some caveats though as Diva Vocals has indicated.

mc12345678:

Following the instructions will resolve both issues, but the direct answer for can this program work with ez-pages, the answer is yes it does, there are some caveats though as Diva Vocals has indicated.

I have really tried to get my EZpages to work but they won't. I have manually added the URL in the DB etc etc... Do I need to convert my EZpage to get this to work? What needs to be done? For instance, http://www.scaffoldusa.com/specials points to http://www.scaffoldusa.com/index.php?main_page=specials. I have set the main page cell to specials in the DB, I have also tried using the URL instead.

Thanks!

/Peter

pexter:

I have really tried to get my EZpages to work but they won't. I have manually added the URL in the DB etc etc... Do I need to convert my EZpage to get this to work? What needs to be done? For instance, http://www.scaffoldusa.com/specials points to http://www.scaffoldusa.com/index.php?main_page=specials. I have set the main page cell to specials in the DB, I have also tried using the URL instead.

Thanks!

/Peter

I believe I would have to disagree that http://www.scaffoldusa.com/specials points to http://www.scaffoldusa.com/index.php?main_page=specials. It may point closely to it, but entering both addresses gives two different results.

What information has been entered for each field of the ceon_uri_mappings table for any/all entries where the uri has /specials in it?

mc12345678:

I believe I would have to disagree that http://www.scaffoldusa.com/specials points to http://www.scaffoldusa.com/index.php?main_page=specials. It may point closely to it, but entering both addresses gives two different results.

What information has been entered for each field of the ceon_uri_mappings table for any/all entries where the uri has /specials in it?

URI= /specials
Language_id= 1
current_uri= 1
main_page= specials (it used to say "page" but I changed it just now to specials, the others still says page)
query_string_parameters= NULL
associated_db_id= 17
alternate_uri= NULL
redirection_type_code= NULL
date_added= (the date it was added)

Check the specials link again, it now points somewhere but the link addresses hasen't changed on the website, shouldn't the links automatically change to /specials /new-products etc...?

/Peter

pexter:

URI= /specials
Language_id= 1
current_uri= 1
main_page= specials (it used to say "page" but I changed it just now to specials, the others still says page)
query_string_parameters= NULL
associated_db_id= 17
alternate_uri= NULL
redirection_type_code= NULL
date_added= (the date it was added)

Check the specials link again, it now points somewhere but the link addresses hasen't changed on the website, shouldn't the links automatically change to /specials /new-products etc...?

/Peter

If the mapping is properly formatted, then yes the uri wouuld change. For a standard rewrite uri like this one, there is no associated_db_id, that too should be set to null.

As I went to test this again to see the effect of having 17 there, it appears that it has been removed... The uri for specials now points to the correct location.

As for the ezpage menu option pointing to the "right" location, we're back to what Diva Vocals pointed out. The Ez-page points internally to a uri. That uri is rewritten, CEON URI Mapping does not provide rewrite support for rewritten uris. Before anyone says I'm wrong, what I mean by that is if your ezpage redirects to site/index.php?main_page=specials, then the rewritten ez-page will show that as the link. But, if in the ezpage, you set the internal link to site/specials, then the rewritten ezpage will show that as the link... And it will then work as desired...

What I'm trying to get at is that if the last destination is something that needs to be translated by ceon uri mappings, and there are link after link embedded to get to that last link, the last link (or really the second from where the first link points) will not get translated. Only the link off of the current page is translated.

So again, in this case, go into your ezpage editor and change the link to which it goes from site/index.php?main_page=specials to site/specials. And done.

pexter:

URI= /specials
Language_id= 1
current_uri= 1
main_page= specials (it used to say "page" but I changed it just now to specials, the others still says page)
query_string_parameters= NULL
associated_db_id= 17
alternate_uri= NULL
redirection_type_code= NULL
date_added= (the date it was added)

Check the specials link again, it now points somewhere but the link addresses hasen't changed on the website, shouldn't the links automatically change to /specials /new-products etc...?

/Peter
From the readme

• Use software such as PHPMyAdmin to add a new record to the ceon_uri_mapping table.

• The URI mapping to be mapped from should be entered in the uri field. (Remember to begin the URI with a slash ‘/’).

• The number representing the language ID this URI mapping applies for should be entered in the language_id field.

• The current_uri field should be set to “1” to make this the “current” URI.

• The Zen Cart page to be mapped to should be entered in the main_page field.

• The date/time this URI mapping was added should be set in the date_added field (or just use the “NOW()” SQL function).

• **The query_string_parameters, associated_db_id and alternate_uri fields are not used, they must be left as “NULL”. The redirection_type_code is not used either so it doesn't matter what value it has (it can just be left at the default value of 301).

**

I don't know where/how you determined a value for or WHY you have an associated_db_id for the specials page, but my guess is THAT is the issue. Take that out.. what happens???

and if you haven't done so remove those EZ-Page redirects you created.

I have a couple of sites where I have utilized CEON URI Mapping. It works great except when Google caches web pages. For some reason, the CSS and JS links are broken and I'm assuming it has something to do with the rewrite rule, but just a guess. When the urls are basic such as https://www.domain.com/content, then Google caches it correctly. However, if another level is added to the url such as https://www.domain.com/content/more-content, this is where the caching becomes a problem. Does anyone have any ideas as to how to correct this? In advance, thanks.

Version used: 4.4.2
Zen Cart Version: 1.5.1
Effected URL: www.l i v i n g a v e n u e .com
Working cached page: https://l i v i n g a v e n u e .com/rick-warren
Working cached page at Google: http://webcache.googleusercontent.com/search?q=cache:LS7D2Ow2y3EJ:https://livingavenue.com/rick-warren+&cd=3&hl=en&ct=clnk&gl=us
Incorrect cached page: https://l i v i n g a v e n u e .com/introductory-logic-student/james-nance/1591280338
Incorrect cached page at Google: http://webcache.googleusercontent.com/search?q=cache:BNl4Egn3QQsJ:https://livingavenue.com/introductory-logic-student/james-nance/1591280338+&cd=2&hl=en&ct=clnk&gl=us

DivaVocals:

From the readme

I don't know where/how you determined a value for or WHY you have an associated_db_id for the specials page, but my guess is THAT is the issue. Take that out.. what happens???

and if you haven't done so remove those EZ-Page redirects you created.

The why has to do with the how... There is/was an entry for the ezpage to go to specials, that ezpage had a value of 17. When attempting to create a redirect for just main_page=specials, the instructions were only partially followed/understood and the associated_db_id was not properly set/nulled.

DivaVocals:

From the readme

I don't know where/how you determined a value for or WHY you have an associated_db_id for the specials page, but my guess is THAT is the issue. Take that out.. what happens???

and if you haven't done so remove those EZ-Page redirects you created.
Disregard that last part..

mc12345678:

The why has to do with the how... There is/was an entry for the ezpage to go to specials, that ezpage had a value of 17. When attempting to create a redirect for just main_page=specials, the instructions were only partially followed/understood and the associated_db_id was not properly set/nulled.

Right.. It was a rhetorical statement.. wasn't really looking for the logic behind the decision of adding a associated_db_id.. I posted the readme instructions to point out that it wasn't needed..

jmcdougal:

... For some reason, the CSS and JS links are broken and I'm assuming it has something to do with the rewrite rule, but just a guess. ...
It appears the "cached" page from October 17th, 2014 has an out of date base element (does not match the current site's base element as of November 10, 2014). The out of date / incorrect URL in the base element on the "cached" page is why the external CSS, JS, and images are not being loaded.

lhungil:

It appears the "cached" page from October 17th, 2014 has an out of date base element (does not match the current site's base element as of November 10, 2014). The out of date / incorrect URL in the base element on the "cached" page is why the external CSS, JS, and images are not being loaded.

Thanks for the reply, but the base elements are indeed the same from the cached date and today. Are you possibly looking at the base element Google creates on the cached page? Thanks again.

Yay! It works! The associated_db_id was automatically created by CEON, but when I nulled it and changed the internal link in EZpages, it works.
However, I did immediately run into some problems when trying to fix the FAQs link... don't know why though, it must be something else, got a 404 so I have reverted it back to original until I find a solution.

Thanks everybody, great work! :D

pexter:

The associated_db_id was automatically created by CEONNot by Ceon, but perhaps your mySQL editor added it??? In any case the readme instructions clearly state not to use it..

In any case glad you have it working now..

pexter:

However, I did immediately run into some problems when trying to fix the FAQs link... don't know why though, it must be something else, got a 404 so I have reverted it back to original until I find a solution.Leaving it at the original is CORRECT (as per the EZ Page on page usage instructions) I wouldn't spend any time trying to "fix" that..

@jmcdougal

If Google is still not supporting retaining the base element for cached pages (instead of clobbering it with their own), you will need to apply the same fixes as were needed to handle images with the FaceBook OpenGraph crawler. Option #1 or Option #2 from that post are probably your best bet at this time.

For option #2: Most themes currently use page relative links instead of zen_href_link() when linking to a CSS or JS file. This needs to be changed in your theme as part of option #2. The file in most themes generating links to CSS and JS resources is: "/includes/templates/your_theme_name/common/html_header.php".

NOTE: "zen_href_link($page_relative_link, null, $request_type);" should work nicely as long as everything in "/includes/configure.php" is correct.