Ceon URI Mapping v4.x

[mc12345678]

I *do*/*will* have more to say on the issue, but the first thing is, never should someone apply the files provided (in this module by version) blindly. Yes, copying 1.5.3 files onto 1.5.4 files *will* remove functionality/action of the 1.5.4 files. They should always be reviewed/merged. If not mistaken the docs for this module even suggest the same... The important thing to know/understand/recognize is if the files being "replaced" have been modified by anything else... Something that has made installation of this module "easy" in the past has been the inclusion of the zc specific version of the file(s). Therefore the simplest of sites could blindly apply the plugin and continue forward without missing a beat. It is that part (to start) of this plugin that is missing for 1.5.4 and then any potentially needed logging associated with the added PCI compliance feature of 1.5.4.

Regarding "recovery" of existing/past uris, the data is all in the database and merely needs to be retrieved/handled at the right point in the code or .htaccess as identified above.

[torvista]

never should someone apply the files provided (in this module by version) blindly.

EXACTLY. And not from ANY mod.

I think mods requiring edits to core files should provide the edits and not the files to force people to merge, take more care and more importantly LEARN.
For the 1000th time I repeat mods are very rarely "plugins" in any sense of the word, they are modifications.

I am using this mod in 1.54 with no problems, and with respect, I never expected to see "train wreck" and "Conor" mentioned in the same thread!

[DivaVocals]

I think mods requiring edits to core files should provide the edits and not the files to force people to merge, take more care and more importantly LEARN.

I have to disagree with this for the simple fact that there are modules which modify the SAME files as other modules.. having JUST the edits out of context with the rest of the file makes it difficult for NOVICE DIY shopowners to know exactly HOW and WHERE to place the code changes.. and not everyone knows how to write CLEAR, EASY TO UNDERSTAND user docs.. I have seen this first hand at play with some of the modules that I have submitted updates for.. The support threads for these modules were LITTERED with questions from novice shopowners who tried to follow the instructions on how/where to add the code edits only to get the white page of death or worse happening.. I'm all for people LEARNING.. but learning should have to be a struggle.. IJS..

[lat9]

I'm going to go with DivaVocals on this one.

I spoke with one store-owner who has very little coding experience and the POODLE change required to the PayPal payment's curl function (commenting out a single line) was causing him major heartburn. Having the changes (even minimal) pre-canned but well-commented will help everyone understand what's going on.

[mc12345678]

Okay, I'm back and this is ***NOT SHORT***... Wanted to give this post some appropriate consideration. A lot has been stated in the last few posts, and if I may address some of it. I would like to state up front that personally I like this mod and that it appears to fit the very public structure of the organization that uses it, but professionally, I have nothing against any of the other uri rewriters (albeit any/all be supported by at least someone, and preferably appropriately upgraded relatively close to the release date of new versions).
So, regarding updates and anyone just starting to read this thread:

I will not edit the files and upload a new version. I don't want to be responsible for this train wreck.

This is a completely personal decision. We all (everyone that offers assistance) does so as they see fit, as they desire, as they can, etc... Free support... Free time... Just because delia (and others) may have made modifications to get the plugin to work on ZC 1.5.4, does not mean that they/us need to share with everyone/anyone, not to mention that by providing the file(s) one does feel a sense of responsibility for all that follows.

If I may summarize some of what followed the above message excerpt... A workaround was suggested about how to continue to operate under ZC 1.5.4 effectively without taking action to incorporate the changes needed for full functionality of the plugin, equivalent to halfway installing the plugin effectively disabling the ability to extend its operability. (This to an extent led to discussion about how best to provide plugins/code/code changes.) Yet again, the discussion of this or any uri rewriter impacting "SEO" is yet to be proven. Just because the acronym appears in a programs title doesn't make it so.

Somewhat surprisingly the actual code inserted into ZC is relatively simple/small, but calls ever more complex code in the background. Anyways, any module could be "dead" at any next revision, if no one does anything to address it. Certainly, if JSWeb has taken to a financial perspective only, either they will transition from providing any support at all for this free module and only offer for pay versions moving this particular functionality availability away from the masses. I would be surprised to see if the requested rates are truly reaping the supposed value. Anyways, the use of a uri rewriter (any) can have its downside. Here we are talking about how to transition from one to another, meanwhile the question tends to be, why have one in the first place. About three years ago now, our organization was trying to figure out how best we could get people to remember us and quickly find us as a service organization. It came to light that one of the easiest ways was to have a uri that was memorable and not to just funnel all traffic to one page (main page), but to deliver into the area(s) applicable to the activity considered.. So, yes there were some choices to be made and difficulties initially. The instructions and the individual version files made things easier/better. Reading through the installation as well as potential removal and interaction with other URI mapping programs, it was obvious that once a store starts to use something like this, it appears to be somewhat a commitment to using it into the future.. That is unless/until action is taken to "undo" the rewrites. Now I'm not out to either force this code to remain in place, nor am I out to tear it down. It accomplishes what is desired, and can be used with newer versions when the necessary changes are considered. Yes, it is more involved than a simple copy and paste, and the overall complexity of it is simplified by these files being provided, but perhaps the transition is one to where the plugin is installed by only those that understand how to apply the code differences, rather than by the "masses". At the same time I have also recently seen an installer that supposedly will self integrate with existing code. I haven't tested this out yet, but it if it works as described, then it is a step in the right direction.

So, as I said, I'm not out to tear down this (or any) plugin/code modification/whatever you want to call it. I can say that there is an application that can assist with several of the aspects of interest of this code. Want to create uris from products existing or newly added to the database? It can support it/it is available. Want to convert uri's, well the github available version has a feature that could help in either direction (coming from another uri rewriter to this one or going from this one to another), using an admin control. Yes, generating an .htaccess file to rewrite a rewrite for the purpose of another rewriter to rewrite the result is a bit ridiculous, but I believe the code discussed in this paragraph could handle that generation in a few clicks and again in either direction. Incorporating a method to continue the rewriting of existing uris to support a mix of the old and new is nearly equivalent to operating with two or more uri rewriters at once, but I'm sure that there is a way to make that sort of transition occur...

In regards to some of the specific statements:

One client specifically has over a 1000 products. I don't know if he has actually edited any of those urls and there's really no way to find that out.

Not sure I understand what is considered to have been "edited", but if the client has used this module as designed (and not manually modified the database table), then such modifications are still held in the database and are potentially still doing their function of redirecting customers to the currently active product uri. I'm afraid that if that central functionality is not understood that there is a flavor of not understanding the module that is also a bit disconcerting in light of the strong message to abandon it.. (again there are those that advocate never using any such thing to begin with.)

lat9 has a module that may help bridge the gap. Read more here: http://www.zen-cart.com/showthread.p...ile-overwrites. In this post I ask for clarification about how the script she wrote works and it is NOW available in the free downloads.. I do believe that this module will bridge the gap between the currently available version of this module and Zen Cart v1.5.4.

lat9's adaptation of the new code in ZC 1.5.4 to be applied to code that would/could be used in previous versions of ZC, is certainly valuable to any module that is broadly applicable to any/most ZC versions. It is far more necessary for a module that doesn't contain unique application/design for the applicable ZC version... So, in the case of this module, if the next modification is "entered" to support ZC 1.5.4, there would be no need for lat9's plugin, because a folder for ZC version 1.5.4 will be created to be applied against that version of ZC which already has the necessary files to process the PCI commands. Further, because the ZC 1.5.3 folder applies to ZC 1.5.3 and ZC 1.5.3 and below do not use the PCI commands, then the plugin also does not apply. If, however, the code were written as a "one-size" fits all, then lat9's file(s) would be needed. For example EasyPopulate v4 is a single set of files that functions in ZC 1.3.9 all the way up to ZC 1.5.4 (not including ZC 1.5.2 on purpose), because of that lat9's plugin is relatively crucial, because the code could attempt to log a PCI event; however, none will be logged because the underlying functionality doesn't exist in the earlier versions.

As for rewriting the rewrites, one aspect about it has to do with sequencing... I don't know how everyone is at algebra or simple substitution:
All cats have fur
All fur is long hair
All long hair is on a mammal
All mammals breath air, then one would/could say reading left-to-right and downward that all cats breath air...

But in reverse order the following is not true, and substitution would not occur:
All air breathers are mammals
All mammals have long hair.
All long hair is fur,
All fur is on cats...

The first set has logical statements that are true leading to a result, the second set also has logical statements (even if they are not true statements) that lead to central location for the answer. Thing is I would say that the first one is one where more substitution is performed than desired (each step downward) as compared to a single substitution step of resultradcon is working to the DR to verify that the work has been complete.

So, like described in the article referenced (though not verified to be correct), the category rewrites should follow (come after) the product rewrites to ensure the right product is being rewritten with the right name.

[DannyVarley]

Okay, So I have read over the last few pages and It seems that this module is only partially working with 1.5.4? It seems that lat9's module that has been linked provides a way to circumvent the problem but unfortunately I am only a novice and Im not too sure what to do with that mod. So do I install this and figure it out myself and try and use lat9's workaround or does it look likely that something will be submitted that works on 1.5.4?

It seems very disheartening that conor made all these modules and supplied so much effort and now this has been left to a company who seem to just be in it for the money by selling his versions of the modules with DRM! Offering no support for the free modules and in effect forcing people to consider forking out lots of money for the only version of the module that is actually working!

Please help!

[mc12345678]

Okay, So I have read over the last few pages and It seems that this module is only partially working with 1.5.4? It seems that lat9's module that has been linked provides a way to circumvent the problem but unfortunately I am only a novice and Im not too sure what to do with that mod. So do I install this and figure it out myself and try and use lat9's workaround or does it look likely that something will be submitted that works on 1.5.4?

It seems very disheartening that conor made all these modules and supplied so much effort and now this has been left to a company who seem to just be in it for the money by selling his versions of the modules with DRM! Offering no support for the free modules and in effect forcing people to consider forking out lots of money for the only version of the module that is actually working!

Please help!

So, I have thought about the above and my LAP. If the code that is added by this module (ie, the classes) is to contain the recording of the PCI information and not the ZC version specific files, then yes lat9's plugin would be needed for "backward's" compatibility.

To you kind individual, installation of lat9's plugin referenced here ought to be simple and have almost no visible effect on the store when installed alone. I haven't reviewed the package specifically but I have used the "original" code as posted elsewhere on the forum.

As for the functionality, when merged appropriately, the module has been shown to function. That said, ZC 1.5.4 has included additional actions support PCI compliance. Part of this has been to log changes made to the database through the admin console or admin files. This plugin modifies the database when creating, editing, deleting products and rewritten uris... Further, the module itself does spit out pretty much the information that would be desired to capture as a message to the screen... This goes back to whether the plugin is needed or if the information could simply be captured by documenting the messages that come back from the code.

Let's see, software has been issued for over three weeks now. It may have been available to the for preliminary testing/beta testing, but let's assume not. Last time the ZC version changed, how long was it before the compatible version was posted? Has anyone followed the process of notifying JSWeb through their site about the issues they are having with installing the module on ZC 1.5.4 requesting that they make it available or something?

[Ryk]

Thank you mc12345678 for that

Has anyone followed the process of notifying JSWeb through their site about the issues they are having with installing the module on ZC 1.5.4 requesting that they make it available or something?

The answer is no.

I'm not at all sure we deserve this current wave of hostility from some people round here, but I am not prepared to waste time entering into a debate.

All I will say this:

1. It is almost certain that every single person who has posted on this forum is either making money out of ZenCart or is hoping to make money out of ZenCart, whether it be building a successful ecommerce business or by using their knowledge to implement and enhance the software.

And that includes our detractors.

2. Although it is absolutely no business of anyone else whatsoever, JSWeb have an agreement with Ceon Ltd which began prior to the loss of Conor (who, by the way, worked so closely with JSWeb that he attended several of our periodic company meetings in Dublin & Birmingham, was instrumental in the management of our servers and was in more or less daily discussions about the way forward for both Ceon & JSWeb - so how anyone on this forum can presume to know what Conor would have thought is both outrageous and offensive).

The original agreement was that JSWeb would sell Conor's commercial modules at whatever price our market would support and pay Ceon Ltd the amount he would have charged. After his passing, the agreement with Ceon Ltd was adjusted so that we would continue to market those same modules and would also assume the support and maintenance of them, continuing to pay commission on each sale. That we still do, and will continue to do so.

Free modules were not, and are not, included in our agreement. Such modules are put into the public domain and ANYONE can modify them as they see fit - a fact which seems to be overlooked by those bad-mouthing us. Should someone choose not to do so, then that is their decision, but that does not give reason to criticise us for not doing so.

We have no legal - nor indeed, moral - obligation to support the free modules supplied by Ceon, but as I've said in the past when we get the time we will endeavour to update the free contributions when necessary.

3. JSWeb focus MUST be on servicing our paying clients' requirements. That includes keeping the Ceon commercial modules up to date. Over the past year we have upgraded/rebuilt various modules to handle API changes by couriers, payment gateways etc - and of course, keep them up to date with ZenCart version changes. IF changes are relevant to one of the free modules, then we would implement them too, but there are no free versions of those particular modules.

After the experience of 1.3.9 a-d in rapid succession from Apr-Jun 2010 (then e-h by Oct 2010!), we always wait a few weeks before encouraging our clients to upgrade (it's one thing keeping your own site upgraded with quick-fire releases - entirely different when you have a couple of hundred to manage). During that period we assess the commercial modules to see if there will be any impact so we can implement ZC upgrades without breaking sites. URI Mapping is not essential for a successful website whereas a functioning payment gateway integration/shipping module is, so it was not top of our list. Once the necessary changes have been identified, they will also be applied to the free version ..unless someone else has, as they are perfectly entitled to do, already uploaded a new version to the forum.

[DivaVocals]

It may have been available to the for preliminary testing/beta testing, but let's assume not.

It was made available to those who regularly maintain certain modules or are participating in the v1.6 community..

[DivaVocals]

Sooooooooo having an opinion about a topic and expressing that opinion in a DISCUSSION forum makes one a "hostile" and a "detractor" eh?? Hmmmmmmm.. well okay.. Everyone is entitled to interpret my words ANY WAY they like.

I personally had NO REASON to contact ANYONE about this module because based on my OWN observations it was clear that this module would no longer be a maintained in a manner that made it a reliable tool for me to CHOOSE to use on my client's site.. Expressing that is not hostile, it is my OPINION, and since this is a DISCUSSION forum I expressed that opinion..

So let me be clear:

• I could CARE LESS what Ceon and JSWeb's arrangement is
• I don't think JSWeb is in any way OBLIGATED to maintain ANY of the Ceon free modules
• I agree with the point made that ANYONE in the community COULD pick up the ball and maintain this module

On this last point I think the reason no one has picked up this or any other Ceon module is that everyone looks at modules as being "owned" by whomever they perceive is the active maintainer. So they don't want to step on toes by taking over the care and upkeep of these modules. I saw this first hand with Edit Orders. People asked me if I had gotten Scott's "permission" to submit an update. In the case of this and other Ceon modules, upon Conor's death, JSWeb communicated that they would be assuming responsibility for Conor's modules. What was not clear in that announcement and subsequent communications (until recently) was the fact that this did NOT necessarily include the free modules Conor developed. Not having this bit of information is likely partially WHY no one in the community has stepped up and taken the baton so-to-speak on this or ANY of Conor's other modules. Speaking personally for myself, it was my observation that free support ended with Conor's death, and I began considering other options for my clients.. However, for most folks it was clear that they were unsure of the state of things. (as demonstrated by the discussions here)

Regardless as to WHY the free Ceon module will not be maintained by JSWeb is not important.. I could care less WHY.. All I know is that this IS the state of the Ceon free modules. There's NOTHING hostile about laying the cards out on the table on this..

Now there are some folks who have an expectation that free modules will be maintained forever, and many small business owners don't have a realistic plan for what happens when that free module they NEED stops being maintained.. Anyone who's read any of my posts knows that I have expressed opinions about free module development expectations, the need for small business owners to include paying for professional assistance when needed, and that it's unrealistic to build a business without paying a DIME for technical assistance on occasion. So though JSWeb has labeled me a "detractor" or "hostile", I am in fact neither..

What I am is of the opinion that until this module has a regular active maintainer, it is not something I will continue to install on my client's site. So YES I am actively looking for options to migrate my current Ceon URI clients to Ultimate SEO (which will delay the v1.5.4 upgrade for these clients). Finally I will continue to express THAT opinion. If expressing an HONEST opinion is considered being a "detractor" or "hostile", then color me a "hostile detractor".. Personally I consider myself one who is zealously looking out for my clients.

one last note.. it is "both outrageous and offensive" to assume that Conor (or his family) never spoke with anyone else on this forum.. Some folks have formed their own opinions based on their OWN interactions with Conor..