Ceon URI Mapping v4.x

[lankeeyankee]

you have to modify a bunch of different files in admin/includes/modules for it to show up in the products and categories pages. I looked at the download from the plugins section and there is a copy of admin/includes/functions/general in there under the modified core files folder. I used the version from torvista's github. I don't believe there were a lot of file changes between 1.5.5a and e. But you can see what was changed in the change log in docs/changed_files-v1-5-5.html in the zen cart install directory.

[pixelpadre]

you have to modify a bunch of different files in admin/includes/modules for it to show up in the products and categories pages. I looked at the download from the plugins section and there is a copy of admin/includes/functions/general in there under the modified core files folder. I used the version from torvista's github. I don't believe there were a lot of file changes between 1.5.5a and e. But you can see what was changed in the change log in docs/changed_files-v1-5-5.html in the zen cart install directory.

So not only do I have to guess which files have to be modified in a directory of 20 files, but I have to guess how to modify them? Does that make sense to anyone. If it were that simple wouldnt the author have done that a year ago?

[lankeeyankee]

They are all drop in sections of code, you don't have to actually modify core code if I remember correctly. So it really shouldn't matter what version it is in the 1.5.5 series. It really isn't that hard to drop in the sections of code, they are very well marked and it doesn't take a coding professional to do it. Don't know why you are complaining, maybe you could update the files to 1.5.5e and send it to plugins to be updated and get your first contribution under your belt?

[lankeeyankee]

So I had this working perfectly on my new updated site. ZC 1.5.5e, PHP 5.6.3. It all was doing as expected, but now for some reason my ezpages with internal links are not converting anymore even though they were to begin with. For instance, an ezpage for contact_us, with an internal link of index.php?main_page=contact_us was converted to /Contact-Us. When I went to that link it loaded the contact us page, just as expected. Now, on the site the link is showing as index.php?main_page=contact_us instead of Contact-Us. If I manually enter Contact-Us in the address bar it loads a page that says Contact Us in the main column but the rest of the main column is blank. I don't understand what's happened, what modification I did since installing this might have caused this issue. I have spent a number of hours reviewing my changes since installing this mod and can't find anything that would be responsible. I have changed to the default template, but that's not it. If I create new new ezpage that is a "regular" ezpage that has some html content and not an internal link, the rewrite works correctly. So it seems to be an issue with the use of internal links in the ezpage.

Has anyone come across this issue before?

[lankeeyankee]

So I had this working perfectly on my new updated site. ZC 1.5.5e, PHP 5.6.3. It all was doing as expected, but now for some reason my ezpages with internal links are not converting anymore even though they were to begin with. For instance, an ezpage for contact_us, with an internal link of index.php?main_page=contact_us was converted to /Contact-Us. When I went to that link it loaded the contact us page, just as expected. Now, on the site the link is showing as index.php?main_page=contact_us instead of Contact-Us. If I manually enter Contact-Us in the address bar it loads a page that says Contact Us in the main column but the rest of the main column is blank. I don't understand what's happened, what modification I did since installing this might have caused this issue. I have spent a number of hours reviewing my changes since installing this mod and can't find anything that would be responsible. I have changed to the default template, but that's not it. If I create new new ezpage that is a "regular" ezpage that has some html content and not an internal link, the rewrite works correctly. So it seems to be an issue with the use of internal links in the ezpage.

Has anyone come across this issue before?

After much more trial and error, I have gotten the internal-linked ezpages to show the correct page when manually entered in the browser address bar and the breadcrumbs are also correct. But the ezpage header and footer links are still pointing to the dynamic URL instead of the rewritten one. What I noticed in the DB was it was entering page for the main page of the internal-linked ezpages. Having page in that column was only working for regular ezpages and they are displaying the rewritten link properly and going to the correct page. When I manually added them to the DB and used contact_us, about_us, etc in the main page it is working if I manually enter the URL in the address bar.

So now I just need to figure out why the links in the ezpage header and footer are showing the dynamic URL instead of the rewritten one. Any suggestions about where to look would be highly appreciated!

[mc12345678]

After much more trial and error, I have gotten the internal-linked ezpages to show the correct page when manually entered in the browser address bar and the breadcrumbs are also correct. But the ezpage header and footer links are still pointing to the dynamic URL instead of the rewritten one. What I noticed in the DB was it was entering page for the main page of the internal-linked ezpages. Having page in that column was only working for regular ezpages and they are displaying the rewritten link properly and going to the correct page. When I manually added them to the DB and used contact_us, about_us, etc in the main page it is working if I manually enter the URL in the address bar.

So now I just need to figure out why the links in the ezpage header and footer are showing the dynamic URL instead of the rewritten one. Any suggestions about where to look would be highly appreciated!

Might I suggest reading the instructions related to internal links? This is a specific issues that as memory serves specifically does not rewrite on display of the uri on hover, but on click should direct and land at the uri that is either rewritten or "normal" as the case may be. Now, what I have done in times past if I remember correctly is to establish a rewritten uri for a given page then as the internal link I have used that rewritten uri to get there. Ie. The hover upon uri matches the final uri with regards to the rewritten state. That is at least how I recall setting it up way back when.

I know DivaVocals had posted something further about internal links as well not "all" that long ago. (long enough, but not like years..)

[lankeeyankee]

Might I suggest reading the instructions related to internal links? This is a specific issues that as memory serves specifically does not rewrite on display of the uri on hover, but on click should direct and land at the uri that is either rewritten or "normal" as the case may be. Now, what I have done in times past if I remember correctly is to establish a rewritten uri for a given page then as the internal link I have used that rewritten uri to get there. Ie. The hover upon uri matches the final uri with regards to the rewritten state. That is at least how I recall setting it up way back when.

I know DivaVocals had posted something further about internal links as well not "all" that long ago. (long enough, but not like years..)

Hmmm, I had read and reread the docs and never saw that part. Thanks for pointing out what it should be doing. It does indeed go to the rewritten URI but not if I use the default auto-generation feature for ezpages. And the hover links are the rewritten URI for all other links ie products, categories and manufacturers.

If I use the default link generation in ezpages, it assigns the main_page as 'page' in the DB. Page is correct for ezpages that do not use an internal link, and they work correctly and have the hover link display the new URI. But, it has 0 effect on internal links. Even though in the DB it shows up, when I hover it shows dynamic URL and when clicked it takes me to the dynamic URL, too. When I change main_page from 'page' to say 'contact_us' and associated_db_id to NULL then the hover link still shows the dynamic URL but it does take me to the page with the rewritten URI.

I just tried this on a new vanilla 1.5.5e with only this module installed. I get the same behavior. So something is different because it was working properly when I first installed it. I didn't have to do any messing around in the DB, I just went into each ezpage and saved it just like existing categories and products (there were only a couple test ones) and it worked out of the box. Now, the internally linked ones don't work with auto create.

[lankeeyankee]

Now, what I have done in times past if I remember correctly is to establish a rewritten uri for a given page then as the internal link I have used that rewritten uri to get there. Ie. The hover upon uri matches the final uri with regards to the rewritten state. That is at least how I recall setting it up way back when.

This didn't work until I manually entered the internal-linked ezpages in the DB, using the main_page of 'contact_us' etc and associated_db_id set to NULL. Then I went back in to ezpages and set the internal link to Contact-Us and now it has the hover link correct and goes to correct page.

Thanks for the pointer!!

[DrByte]

If it were that simple wouldnt the author have done that a year ago?

Perhaps. But he died several years ago. His family has posted about getting back into updating his modules, but I'm not sure where exactly they're at with that today.

[pixelpadre]

Perhaps. But he died several years ago. His family has posted about getting back into updating his modules, but I'm not sure where exactly they're at with that today.

Did not know this. R.I.P.

These events are happening all around us today. The pioneers are dropping along the great trails of technological exploration that have redefined the lives of everyone on the planet. Some people think the greatest generation that ever lived were kids with guns shooting at kids with guns. I can make a convincing argument that they pale in comparison to today's heroes who have changed our lives much more profoundly than any battlefield victory. Many expert authorities in all sectors of the computing world have already departed and left roads unfinished and unpaved.

Whoever said there is no sense in re inventing the wheel was wrong...we will be doing it for a very long time. Or at least as long as these pioneers work independently with no documentation for others to pick up where they left off. Judging from what I have seen over the past 20 years in computer programming code, we are in for a rough time as we try to decipher others works. A short read here will explain what I am talking about. http://www.cs.utah.edu/~germain/PPS/...ommenting.html