Ceon URI Mapping v4.x

Thank you so much. That worked a treat! The only problem I have now, is when I switch between the languages (Welsh and English in my case) as there isn't an associated_db_id it just goes back to the homepage. This isn't a problem with the product pages etc. Is there a way of rectifying this? Thanks so much for your help.

See that field for language? Need to look at either of two things (or more) in your admin where you can add/modify languages (localities I think it is?) the language id associated with your other language (more than likely 2) is to be used for the matching url for that language.

The other "source" would be to inspect the ceon_uri_mappings table for the number(s) related to working alternate language product.

Keep in mind in all of this that only one of the potential many uri's with a matching language and other matching fields can be the current_uri... All the others are well... not current. :)

You may also need to add parameters to the definition (force the entered uri to change the site to the other language.)

Change required for ZC155.

In ZC155 this section was added in /common/html_header.php.

<?php // BOF hreflang for multilingual sites if (!isset($lng) || (isset($lng) && !is_object($lng))) { $lng = new language; } reset($lng->catalog_languages); while (list($key, $value) = each($lng->catalog_languages)) { if ($value['id'] == $_SESSION['languages_id']) continue; echo '<link rel="alternate" href="' . ($this_is_home_page ? zen_href_link(FILENAME_DEFAULT, 'language=' . $key, $request_type) : $canonicalLink .** '&**language=' . $key) . '" hreflang="' . $key . '" />' . "\n"; } // EOF hreflang for multilingual sites ?>

Ceon URI Mapping produces canonical links with no ?parameters:

<link rel="canonical" href="http://blah-blah.....aballetes/rg-padd-front-bk-caballete-delantero" />

so the additional &language needs to be ?language (or it becomes an invalid link that gives page not found).

I did this:

<?php //steve bof CEON uri mapping
//CEON uri mapping produces a CANONICAL link with no ?parameters so '&language=' gets a page not found: need to change separator
$alternateSeparator = ( !isset($ceon_uri_mapping_canonical_uri) ? '&' : '?' );
?>
<?php
  // BOF hreflang for multilingual sites
  if (!isset($lng) || (isset($lng) && !is_object($lng))) {
    $lng = new language;
  }
  reset($lng->catalog_languages);
  while (list($key, $value) = each($lng->catalog_languages)) {
    if ($value['id'] == $_SESSION['languages_id']) continue;
    echo '<link rel="alternate" href="' . ($this_is_home_page ? zen_href_link(FILENAME_DEFAULT, 'language=' . $key, $request_type) : $canonicalLink . $alternateSeparator . 'language=' . $key) . '" hreflang="' . $key . '" />' . "\n";//steve changed & for a variable separator
  }
  // EOF hreflang for multilingual sites
 //steve eof CEON uri mapping
 ?>

For people having problems with logins not working and going straight to "Your Shopping cart is Empty" page, especially on a LOCAL server, this thread should be looked at:
https://www.zen-cart.com/showthread.php?215358-Problem-using-root-as-cookie-path-after-installing-CEON-URI&p=1310146#post1310146

Website https://www.onlinesurgicals.com/store/ stopped working after upgrade to VPS with Bluehost. I just get a blank page.

The debugging file in cache folder showed the following.

[10-May-2016 22:13:30 America/Denver] PHP Strict Standards: Declaration of CeonURIMappingHandler::_handleHistoricalURIWithNoCurrentMapping() should be compatible with CeonURIMappingHandlerBase::_handleHistoricalURIWithNoCurrentMapping() in /home/hlcindia/public_html/onlinesurgicals/store/includes/classes/class.CeonURIMappingHandler.php on line 41
[10-May-2016 22:13:30 America/Denver] PHP Strict Standards: Declaration of CeonURIMappingHandler::_handleUnmappedURI() should be compatible with CeonURIMappingHandlerBase::_handleUnmappedURI() in /home/hlcindia/public_html/onlinesurgicals/store/includes/classes/class.CeonURIMappingHandler.php on line 41

However the mobile version of site is working fine in mobiles.

.htaccess file has the rewrite rules as per the codes shown in Ceon URI mapping installation check page within Zencart admin.

I am using zencart version 1.3.9h and fortunately, ZC admin interface is working well in both desktop and mobile.

Please help and treat this very urgent as desktop site is getting significant traffic.

gopinathgoswami:

Website stopped working after upgrade to VPS with Bluehost. I just get a blank page.

The debugging file in cache folder showed the following.

[10-May-2016 22:13:30 America/Denver] PHP Strict Standards: Declaration of CeonURIMappingHandler::_handleHistoricalURIWithNoCurrentMapping() should be compatible with CeonURIMappingHandlerBase::_handleHistoricalURIWithNoCurrentMapping() in /home/hlcindia/public_html/onlinesurgicals/store/includes/classes/class.CeonURIMappingHandler.php on line 41
[10-May-2016 22:13:30 America/Denver] PHP Strict Standards: Declaration of CeonURIMappingHandler::_handleUnmappedURI() should be compatible with CeonURIMappingHandlerBase::_handleUnmappedURI() in /home/hlcindia/public_html/onlinesurgicals/store/includes/classes/class.CeonURIMappingHandler.php on line 41Evidently you PHP is complaining about violation of Strict Standards. That's likely a result of using old PHP code on a newer version of PHP (newer PHP versions are increasingly more strict about clean code).

Your v1.3.9 site is using PHP code written and released in 2010. That's 6 years ago. And lots of PHP versions ago.

So, I guess you have two options:
a) downgrade PHP to an older version compatible with your old site
b) upgrade your site and plugins to be compatible with your newer PHP version

Or if you can find the new maintainers of the Ceon code online you might purchase a support contract from them to have them adjust the code to work for your site.

So, I guess you have two options:
a) downgrade PHP to an older version compatible with your old site
b) upgrade your site and plugins to be compatible with your newer PHP version

I've just forced this issue and yes, with E_STRICT reporting, when CEON URI has to generate a new uri automatically when someone visits a product with no URI defined, a pile of errors are reported while it generates one (it still works ok).

Fortunately (for you) I am currently fixing stuff like this on my site for PHP7 so I'll look into it.

Your immediate stop-gap solution would be to remove E_STRICT error reporting or downgrade php.
I would guess this has just started since your host upgraded to php 5.4:
http://php.net/manual/en/function.error-reporting.php>

5.4.0 |
E_STRICT became part of E_ALL. |

followed immediately by a site upgrade or you are just hiding the problems and putting off the inevitable.

It's "funny" that no-one ever has time to upgrade their site but somehow they find that time when it breaks. Be prepared.

I don't find the same error as you. I have fixed all my E_STRICT error messages related to this mod.

Look in the two files referenced in the first error message for the function declaration.

**function **_handleHistoricalURIWithNoCurrentMapping($main_page, $associated_db_id, $query_string_parameters)

they should be using the same number of parameters. The error message implies they don't. Mine do.

This is no longer valid advice. README has no information.

weljkodj:

Lets say the page you want to change is /index.php?main_page=conditions, which represents "Conditions of use" page. In PHPMyAdmin, insert record with this values:

uri -> /conditions
language_id -> type your language_id
current_uri -> 1
main_page -> conditions
query_string_parameters -> NULL
associated_db_id -> NULL
alternate_uri -> NULL
redirection_type_code -> 301
date_added -> select NOW() function next to field

It is the same for all pages: privacy, contact_us, shipppinginfo, advanced_search...

This doesnt appear to work for page_2

Tried this and it didnt work. +1 post for me

mc12345678:

I think you're overthinking things. :)

Main_page is the content that follows the url parameter main_page=

So, for /index.php?main_page=page_2, main_page field is page_2. For the associated_db_id, there is no "unique" value that is associated so it should remain blank. This value is used to target a specific type of "item" for which the URI rewriter is to apply "conversion" a products_id, a category, an ez-page, or a manufacturer. These "items" all have a unique id and that is the associated_db_id.

So depending on your condition/desire, the above example could be entered as:
Uri=/page-2, language=1, current_uri=1, and main_page=page_2

Tried this and it didnt work for me. +1 post

pixelpadre:

Tried this and it didnt work for me. +1 post

How about being more descriptive of your attempted solution, the setup of your store, what didn't work, etc...

Here is the entry from a control panel on which the main_page=page_2 was rewritten. The store is located in a web-facing sub-directory called shop the HTTP_CATALOG and HTTPS_CATALOG allow for both to use the equivalent DIR_WS_CATALOG path information for http and https. Entry of the standard ZC path of http: // site /shop/index.php?main_page=page_2 where page_2 is not an ez-page (is instead defined in defined page editor of define_page_2.php) redirects to http: // site /shop/Monthly.

[TABLE="class: data"]
[TR]
[TH][/TH]
[TH]uri[/TH]
[TH]     language_id[/TH]
[TH]     current_uri[/TH]
[TH]     main_page[/TH]
[TH]     query_string_parameters[/TH]
[TH]     associated_db_id[/TH]
[TH]     alternate_uri[/TH]
[TH]     redirection_type_code[/TH]
[TH]     date_added[/TH]
[/TR]
[TR="class: odd"]
[TD="align: center"][/TD]
[TD]/shop/Monthly[/TD]
[TD="class: nowrap, align: right"]1[/TD]
[TD="class: nowrap, align: right"]1[/TD]
[TD]page_2[/TD]
[TD][I]NULL[/I][/TD]
[TD="align: right"][I]NULL[/I][/TD]
[TD][I]NULL[/I][/TD]
[TD]301[/TD]
[TD]2013-06-25 12:08:57[/TD]
[/TR]
[/TABLE]

Here is a screenshot

pixelpadre:

Here is a screenshot

For the contact_us to be rewritten, remove main_page=

That field (column) represents the main_page= portion and only needs the value to the right of it up to the & of the next parameter if another parameter were to exist.

Also, if your database will support it, the associated_db_id field should be NULL instead of 0. Though 0 may still work. I forget how that portion of evaluation is written and prior to posting this haven't dug through the code. It is expected though that no such dB field would actually be 0 so I suspect that it will be a non-issue.

As I said earlier, "this didnt work for me"/ Maybe your advice will work.

I tried null for dbase number and it added 0.

Also, previous advice suggested using select NOW() for date. all that gives me is 00000000

That advice made no difference. Still get this http://mydomain.com/index.php?main_page=contact_us

pixelpadre:

As I said earlier, "this didnt work for me"/ Maybe your advice will work.

I tried null for dbase number and it added 0.

Also, previous advice suggested using select NOW() for date. all that gives me is 00000000

The time issue certainly sounds like a mysql database setup issue (host related) or the absence of providing an appropriate date/time command/string (see the table configure settings below), but perhaps one or more of the following would provide a non-zero timestamp if used within a SQL statement:
CURDATE()
CURRENT_TIMESTAMP()
LOCALTIME()
LOCALTIMESTAMP()
SYSDATE()
UNIX_TIMESTAMP()
UTC_TIMESTAMP()

Though some of these only return dates not date and time.
Curious though, NOW() is typically used in ZC for changing settings such as configuration options. Does this mean that all of your configuration settings either show a date/time of when added or when modified as 0000-00-00 or not at all?

As to the null to 0, this appears to be related to the definition of the database table. The install sql declares the associated_db_id field as default null. Was there a problem with installation that required it to be modified? If not, then can you show an image of the area where you are entering your data to try to provide a rewritten uri.

Other question, in the attempts to obtain a functional version of the rewrite is there only one instance where the main_page of contact_us is listed and the active_uri is 1?

Here is the table creation sql for the ceon_uri_mappings table:

[code]CREATE TABLE
" . TABLE_CEON_URI_MAPPINGS . "
(
uri TEXT NOT NULL,
language_id INT(11) UNSIGNED DEFAULT NULL,
current_uri INT(1) UNSIGNED DEFAULT '0',
main_page VARCHAR(45) NULL,
query_string_parameters VARCHAR(255) DEFAULT NULL,
associated_db_id INT(11) UNSIGNED DEFAULT NULL,
alternate_uri VARCHAR(255) DEFAULT NULL,
redirection_type_code VARCHAR(3) DEFAULT '301',
date_added DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
INDEX assoc_db_id_idx (language_id, current_uri, main_page, associated_db_id)
);[/url]

Lastly for now, what is your mysql database setup? Is this hosted possibly on a Windows system? Or with database setup preventing integers or unsigned integers from being null? The other fields seemed to get populated with NULL but somehow in the "making" the associated_db_id NULL (which really is or should be done by adding nothing into the field because afterall, NULL is (should be) the default meaning it's automatically that until something else is assigned.

So I scanned back thru the last few pages of this thread and could find no reference to the latest zen.

ZC155a was released May 5, 2016 and the last Ceon URI update was March 26. Since I'm about to install Ceon URI into zc155a, I compared the Ceon modified core files to the core files changed between 155 and 155a:
https://www.zen-cart.com/docs/changed_files-v1-5-5.html#v155a

From that list, only one file needs merging:
/admin/includes/functions/general.php

I'm going to merge the Ceon changes into the zc155a, then install.

Is anybody else running the latest Ceon URI on a 155a? Any known problems?

Feznizzle:

Is anybody else running the latest Ceon URI on a 155a? Any known problems?

I'm using...until now, all looks good!