Ceon URI Mapping v4.x

[shags38]

v1.5.5f php7.1

I need some qualified advice here please on a major problem.

Firstly the background;

I posted yesterday in the USU (Ultimate SEO) thread - details below - about reverting to USU from CEON and how this could be seamlessly done.

This was the post;

I installed CEON URI Mapping as a matter of 'have to' when USU had the canonical problem. CEON is too complicated for me so I want to revert back to the latest version of USU.
Question: will USU seamlessly re-write the CEON generated urls? .... as well as those that are still using the standard ZC generic index.php?xyzacb format? ... i.e. will all currently indexed urls remain indexed without having to be found again by Google?

Are there any specific things I need to do and in any particular order to ensure the changeover works .... seamlessly :)

this was the response;

USU won't be able to rewrite those customized CEON-generated links since they can be fairly free-form. The only thing that comes to mind is to add rewrites to the .htaccess for each of the CEON-customized links prior to the bit that's required by USU. The developers in the CEON forum might be able to shed additional light on a different solution.

QUESTION for this forum;

Is there a way to have the now CEON generated urls on my sites (6 of them) numbering thousands per site re-write to the USU format when I install and enable USU ???

I look forward to some advice.

cheers,
Mike
p.s. I am still trying to recover my previous ranking prior to the USU issue

USU thread link, https://www.zen-cart.com/showthread....74#post1357674

[shags38]

@mc12345678 .... found this thread with 'similar' query - goes back to 2014 - you were integrally involved in it. So wondering if there is an advancement in the process?

cheers,
Mike

[torvista]

Is there a way to have the now CEON generated urls on my sites (6 of them) numbering thousands per site re-write to the USU format when I install and enable USU ???

As I understand it, either
- you make USU create links in the same format as CEON so they effectively do not change.
- you take those CEON rewrites and manually put them in the htaccess and then prevent USU from creating new links for the same products.

Neither of those options I would want to do. Your problem seems to be based on finding CEON "dificult to use". Well it was always intended to be used with the (commercial) CEON Mappings Manager. Speak to CEON and see if you can buy it, I have used CEON for ten years and still do. Difficult to use it is not (as Yoda might say).

[shags38]

Many thanks for your response - I appreciate it

As I understand it, either
- you make USU create links in the same format as CEON so they effectively do not change.

so how can this be done, 'make' USU create identical links?? Having used USU before I am not aware of any configuration that would handle this.

- you take those CEON rewrites and manually put them in the htaccess and then prevent USU from creating new links for the same products.

just a couple of things on this one;
- talking about hundreds of products plus ez pages, category pages etc ........... are you suggesting adding hundreds of url redirects in an htaccess file?
- how would I obtain the list of urls?

Neither of those options I would want to do. Your problem seems to be based on finding CEON "dificult to use". Well it was always intended to be used with the (commercial) CEON Mappings Manager. Speak to CEON and see if you can buy it, I have used CEON for ten years and still do. Difficult to use it is not (as Yoda might say).

- yes you are right, neither option is practical - would be better off reverting to ZC dynamic urls and then installing USU, less work
- last time I looked at the CEON website the CEON Mappings Manager was no longer available - it would be an option if it was - any idea where I could get a copy other than their website?

cheers,
Mike

[torvista]

so how can this be done, 'make' USU create identical links?

No idea, it's just an "option" only in the general that with open source anything is possible if you are prepared to throw lots of time an money at at. In all cases one has to decide if it is justified....

are you suggesting adding hundreds of url redirects in an htaccess file?

Nope. That's another "option" that sounds nuts.

last time I looked at the CEON website the CEON Mappings Manager was no longer available

Contact them directly. They have the code, which is being reworked to a completely new animal. Convince them to take your money!

Or bite the bullet/take the (hopefully temporary) hit and use a solution that is supported here/revert to native urls.

I think your case illustrates what many people think, better to not fix what is not broken (the native urls) or you may get in a SEO mess when you want/have to change something.
I only use friendly urls to paste into emails and because it looks better/more professional to the browsing customer.
I don't worry about SEO, I consider that out of my little hands: I let Google invest their time and money in getting relevant search results from my unique, well-written, html/css correct content, irrespective of the url that locates it.

[mc12345678]

@mc12345678 .... found this thread with 'similar' query - goes back to 2014 - you were integrally involved in it. So wondering if there is an advancement in the process?

cheers,
Mike

The two programs are based off of two major differences. This module allows assigning the url to be just about anything desired and maintains a record of each url assigned so that a link previously made is always accessible. The other depends primarily on a pattern existing (e.g. Product: -p-{products_id}, Category: -c-{categories_id}).##
‎
This module can both be edited or used to create similarly formatted URLs, but one of considerations is that it doesn't matter what those numbers are to the public, they are looking to get to the thing that is identified by the url. The software cares, but a url that points to products_id=5 could just as easily be modified to point to products_id=232 or to an ez-page for that matter. So long as it is unique and the only active url to the object.
‎
None of that though really addresses your issue of "hot-swapping" between the two programs. ‎Mind you with this module, if you wanted to no longer reference to a rewritten uri and instead use the default uri, the item of interest would just not have an active rewrite. All of the historical would remain (and be reachable), but then identify to stop using the rewritten uri and instead use the default. Now given sufficient time, that should be sufficient for everything to be linked back to the original URIs.##

The original URIs can also be obtained by use of the htaccess to convert the provided REQUEST_URI into the ZC original identifier. Because this module uses the database to translate between the two, the database could be used to recreate such rewrites that are then copied into the htaccess file. It doesn't necessarily mean that all need to or should be done that way, again some intelligent determination could be used to select the "important" ones. ##

A third option is the slightly more direct revision of the rewrites already made using this module to rewrite to those of the other. This though introduces yet another potential problem for future maintenance. What if then that rewriter is no longer being used and yet another association must be made with the possibility of rewriting to a rewrite to a rewrite, etc...

Any quality rewriter should be able to accept the ZC original URIs and provide the rewritten uri output by the module. That is why I recommend that if going to put in effort to undo what was done (which appears to not have included collecting the rewritten uris from the other module and populating the database with them as the active rewrites) to "make it simple" by rewriting back to the original url and then allow whatever rewriter to convert to the then current uri.##

As to moving everything to another domain, well, that is easiest when/where there is some one-for-one relationship. At the moment, redirecting to the alternate domain will cause that to initially inherit the issues of the existing domain where whatever is being done to address those issues on the one site, would be done with the other.

Another thing that could be done, though I haven't seen much discussion on is to actually have both active and as necessary some rewritten code to support migrating away from this module. As torvista has indicated and I think I have seen discussion of, the commercial version of this module seems capable of transitioning away from any other module, but it is up to whatever other module to support transitioning away from this one.##

Regardless, it seems that at least time is needed to get back to where things were with either no action taken or to reduce that time to put in some level of effort.
‎
Looking over the posts I provided I did not come out and spell exactly how to accomplish the goal of this module recognizing the previous URIs. I did try to lead on and teach, but it appears unfortunately that I failed. I do know also that at the time I was trying to help amidst being busy with a number of other things and trying to not answer questions not asked (one of those comments I've gotten about my postings).##

The expectation was to collect the URIs associated with all desired destinations. Then populate the database with those URIs and the associated data necessary to reference the appropriate object. The information needed for each type of redirect is, as I said, provided in the instructions and collecting the desired/necessary data is something possible when using any bulk product exporter.##
‎
Yes, that information would still need a little massaging. That would be relatively straight forward when using a spreadsheet program where "formulas" can be used to join text together or use only portions of data. Then the resulting operations could be stored as text and executed. A rather straight forward series of operations.##
‎
As to some thread back in 2014, I don't see a link to it and as can be seen I've been involved in a number of conversations over the years. If would like more of a response on the topic, would need to know what thread was in question.

Whatever you decide to do, I recommend setting out a plan, determining the pros and cons, what issues are likely to exist and how important each issue is to prevent or mitigate.

[shags38]

reply to torvista and mc12345678 (in this one post rather than separately)

Thank you both for your considered responses, I really do appreciate it;

I think your case illustrates what many people think, better to not fix what is not broken (the native urls) or you may get in a SEO mess when you want/have to change something.

Yep - I recall RodG (passed) was very vocal about exactly that.

What this does raise is why is it that a urls rewriter is not included in the base ZC platform - switchable enable/disable (for those who do not want to use it) .... something that as part of the platform would require testing and compatibility validation every time a version revision is released ??

The 'mess' that exists, with my situation, is as a result of an incompatibility problem of USU plugin with the new release 1.55f (as it was then) ... the issue was fixed only late last year. The original author (ihungil) is no longer with ZC (sound familiar?) - neither of the two url rewriters are supported by their original authors and it has rested with other good samaritans to tackle the issues and get the plugins working correctly (i.5.6 in the case of CEON). Meanwhile ZC sites using these plugins that are not doing what they should are suffering in respect to Google ranking, a point missed by so many. The USU issue at least (not using 1.5.6 so not sure what the CEON issue there was), affected the urls delivered to the sitemap, or non delivery more to the point. So Google was being told to find the urls in the sitemap but they were wrong - reflected in Google Search (WMT) and in SERP rankings. The url submitted which doesn't match the page url becomes a totally new page which needs indexing (re-indexing).

Yes Google can find any url and appropriate it 'eventually' to the right page but best practices suggest it is imperative that a sitemap be submitted ..... any links, both to and from, the rewritten page url will be lost forever if the redirection of that page to the new url is not effective .... it becomes a totally new page.

...... as mc12345678 points out

This module can both be edited or used to create similarly formatted URLs, but one of considerations is that it doesn't matter what those numbers are to the public, they are looking to get to the thing that is identified by the url.

It is not about anything else but what Google sees and if Google is getting mixed messages it reflects on SEO - in the true sense of the phrase, Search Engine Optimization .... optimizing the site for the search engines to make their job easier to do their job, present search results according to the query - if they are provided confusing signals then your site becomes less 'optimal' to them.

Opinion from an opinionated ZC user;

'User Friendly' urls are now expected by Google as an integral component of their algorithm putting user experience to the fore in ranking sites - they say as much, and it makes sense .... granted it is not 'critical' but neither is html5 but it is certainly desirable.

The fact remains there are differing opinions however let me suggest that the purists are in the not needed camp and the progressives agree with Google. You are very hard pressed, very hard pressed indeed to find an eCommerce website anywhere in the top 5 pages of SERP's still using dynamic urls ... begs the question why? We all know the answer.

I will likely get belted from dawn to dusk over the following comment by those who volunteer their time to help people like me, something I and many others respect and appreciate, but before pulling out the baseball bat the comment is not directed at any individual nor group of individuals bot more so at the 'system'.... and some will argue the system is the community but as we know any community has leaders or a council or similar - so the developers of ZC.

So the 'safe' option in Zen Cart is to leave things alone, stick with the integrated dynamic url system ... that in itself is, in my humble opinion, archaic in 2019. What is more concerning is that when what I will call a vital plugin (and there are differing opinions of what is and isn't vital) identified as broken and the author is no longer involved in the forums it then rests on a volunteer to put up their hand to attempt to fix it .... if they have the skills, the motivation and importantly if they are indeed even aware of the problem (dependent on what forums they read and or how often). Plugins of such importance, those that are critical to the actual performance of the site (seo or otherwise) vs nice to have available plugins should not be left to others to make sure they work with the version changes as they are released.

I have no idea how many of those that downloaded 1.5.5f, when it was released or was still the current version, actually installed it and how many of those had USU installed or subsequently installed it (before lat9 fixed it) but all of them will have had the canonical compatibility issue - problem is some site owners do not do their own build / management and some webmasters may not be as diligent as they possibly could be - in either case if not regularly checking your sites performance, in the eyes of Google, via Google Search (and not just Analytics or other metrics) then those site owners would be unaware of the damage being done. Maybe site owners like me are more diligent, not sure, but I didn't see too many others raising the USU canonical issue (I believe I was the first) - but that aside there is absolutely no doubt in my mind that many if not all of those sites will have suffered ranking issues, through no fault of their own.

So what it means, at least for me, is that I will never again install a ZC version upgrade until I see evidence that the plugins I use are indeed compatible with the new version. Fortunately I had a couple of sites I didn't upgrade and left at 1.5.1 - they never suffered ranking loss (USU was fully compatible). However I think the issue is far bigger than me. The problem is that few are aware of the issue (now fixed) and fewer 'participate' in the forums (may explain the first part of the sentence).

I have tried everything I can think of, other than piracy, to get hold of a copy of CEON URI Manager (commercial) which as I understand it would be of some assistance to me to better understand / manage CEON ..... sent an email to CEON .net and will see if I get a response.

This is what I am going to do now;

Having read your responses, for which I thank you again, I am going to stick with things as they now stand, i.e. continue with CEON URI Mapping - the alternative is far too messy .... and will likely become a nuisance asking dumb questions in this forum. I did say to you some time back mc12345678 that I would study the instructions and learn the CEON system .... well read it thoroughly but only once, I will need to read it over a few times and experiment - at 65 and not being a developer it takes a bit longer to register (if at all).

The only question left is the 'other' part of the query - wrong forum but whilst here :) - redirecting the site url to a new url name - same site, same host, just a domain name change - what steps are required to effect this smoothly? (I think I know but looking for validation).

Again thank you both.

cheers, Mike

I don't worry about SEO, I consider that out of my little hands: I let Google invest their time and money in getting relevant search results from my unique, well-written, html/css correct content, irrespective of the url that locates it.

Steve - you should bottle this :)

p.s. I do have some questions regarding the 'unique content' in quote above but will ask it in another forum and hope I get some helpful responses :)

[shags38]

@mc12345678

was browsing the forums and found this post that you commented in https://www.zen-cart.com/showthread....72#post1357772 and saw this comment;

- Ceon module was turned off instead of changing all of the active URIs to being inactive. As a result, now the site has to be completely reindexed rather than having the links updated back to their Zen Cart original paths by reference to their former rewritten uris.

not sure if I may be taking it out of context but .... not that I am likely to now however just for my edification, if turning CEON off, to revert to original ZC original paths I assume that there is a process - not that I need it explained now - is it in the instructions? a simple yes & yes will do :)

cheers, Mike

[torvista]

You are very hard pressed, very hard pressed indeed to find an eCommerce website anywhere in the top 5 pages of SERP's still using dynamic urls ... begs the question why?

Don't hold your breath waiting for an answer from the developers (last roadmap update 2016):
https://www.zen-cart.com/showthread....45#post1353345

[picandnix]

Is it my imagination or has Ceon released their update? I've just downloaded Version 5.0 from ceon.net itself.