Printable View
I followed the instructions to do the following:
* For example, to create a static URI for “index.php?main_page=specials”:
uri: /latest-offers
main_page: specials
by updating the table ceon_uri_mappings, now when i type the URLwww.mysite.com/latest-offers
it takes me to the special page but the URL in the browser change to
www.mysite.com/index.php?main_page=specials
Did i forget something?
Which instructions?Quote:
Originally Posted by TamyA
What specific SQL was used to add the record to the database?
Are uris of other product that are generated working fine or are they too responding by taking the visitor to the desired page but with the base ZC uri?
I use the insert SQL statment to insert that information in the tableQuote:
Originally Posted by mc12345678
uri
language_id current_uri main_page query_string_parameters associated_db_id alternate_uri redirection_type_code http://discounthomeoffice.com:2082/c...themes/dot.gif date_added /latest-offers 1 0 specials NULL NULL NULL NUL 2017-06-05 11:26:00
The products/category pages are working fine but still have some pages like specials, contact us, shipping and return that shows index.php?main_page= in the url and my understanding that these pages need to be added to the table manually.
Quote:
* Please note: There is no admin interface for entering these URI mappings in this module, they have to be entered manually (using software such as PHPMyAdmin).
The issue is that current_uri is set to false (0) which means that the program will "respect" the uri, but will display/respond as if it was the ZC default version of it or find the version that exists as the current_uri (value of 1).
You are correct that these type uris if desired to be used must be manually added. Or rather added from outside of the base code of the version available from this website.
Thanks, the 1 did it. Thank you.Quote:
Originally Posted by mc12345678
I'm having issues with 2 of my 3 domains not working now that I installed CEON. I've narrowed it down to the htaccess file.
My hosting file structure is set up as:
/maindomain (zen files under this location)
/maindomain/_aa_domain_2 (2nd hosted website files)
/maindomain/_bb_domain_3 (3rd hosted website files)
My htaccess is:
As it is above, the main domain works but the 2 other domains return:Code:ErrorDocument 404 /404.shtml
RewriteCond %{HTTP_HOST} ^www\.maindomain\.com$
RewriteRule ^/?$ "http\:\/\/maindomain\.com\/" [R=301,L]
## BEGIN CEON URI MAPPING REWRITE RULE
RewriteEngine On
# Don't rewrite any URIs ending with a file extension (ending with .[xxxxx])
RewriteCond %{REQUEST_URI} !\.[a-z]{2,5}$ [NC]
# Don't rewrite any URIs for some, popular specific file format extensions,
# which are not covered by main file extension condition above
RewriteCond %{REQUEST_URI} !\.(mp3|mp4|h264)$ [NC]
# Don't rewrite any URIs for some specific file format extensions,
# which are not covered by main file extension condition above
# Uncomment the following line to apply this condition! (Remove the # at the start of the next line)
#RewriteCond %{REQUEST_URI} !\.(3gp|3g2|h261|h263|mj2|mjp2|mp4v|mpg4|m1v|m2v|m4u|f4v|m4v|3dml)$ [NC]
# Don't rewrite _aa_domain_2 directory
RewriteCond %{REQUEST_URI} !^/_aa_domain_2/ [NC]
# Don't rewrite _bb_domain_3 directory
RewriteCond %{REQUEST_URI} !^/_bb_domain_3/ [NC]
# Handle all other URIs using Zen Cart (its index.php)
RewriteRule .* index.php [QSA,L]
## END CEON URI MAPPING REWRITE RULE
Not Found
The requested URL /maindomain/index.php was not found on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
If I comment out the last line, the other 2 domains work but it crashes the main domain:
#RewriteRule .* index.php [QSA,L]
I'm hoping someone can offer some assistance on the proper code to use to prevent this issue.
Regards
There are other ways to do this, but because htaccess rules "inherit" upwards, your secondary site(s) are being affected by the htaccess in the primary site. Therefore, one way to eliminate that is to preclude the secondary sites from the rule testing such as the two lines added before which would need to be modified to suit your "scheme".Quote:
Originally Posted by idc1
Code:ErrorDocument 404 /404.shtml
RewriteCond %{HTTP_HOST} ^www\.maindomain\.com$
RewriteRule ^/?$ "http\:\/\/maindomain\.com\/" [R=301,L]
## BEGIN CEON URI MAPPING REWRITE RULE
RewriteEngine On
# Don't rewrite any URIs ending with a file extension (ending with .[xxxxx])
RewriteCond %{ HTTP_HOST} !^www\.othersite1\.com [NC]
RewriteCond %{ HTTP_HOST} !^www\.othersite2\.com [NC]
RewriteCond %{REQUEST_URI} !\.[a-z]{2,5}$ [NC]
# Don't rewrite any URIs for some, popular specific file format extensions,
# which are not covered by main file extension condition above
RewriteCond %{REQUEST_URI} !\.(mp3|mp4|h264)$ [NC]
# Don't rewrite any URIs for some specific file format extensions,
# which are not covered by main file extension condition above
# Uncomment the following line to apply this condition! (Remove the # at the start of the next line)
#RewriteCond %{REQUEST_URI} !\.(3gp|3g2|h261|h263|mj2|mjp2|mp4v|mpg4|m1v|m2v|m4u|f4v|m4v|3dml)$ [NC]
# Don't rewrite _aa_domain_2 directory
RewriteCond %{REQUEST_URI} !^/_aa_domain_2/ [NC]
# Don't rewrite _bb_domain_3 directory
RewriteCond %{REQUEST_URI} !^/_bb_domain_3/ [NC]
# Handle all other URIs using Zen Cart (its index.php)
RewriteRule .* index.php [QSA,L]
## END CEON URI MAPPING REWRITE RULE
Quote:
Originally Posted by mc12345678
Thank you. This worked like a charm.
Quote:
Originally Posted by idc1
Glad that it did. BTW, in review of your tagline:
You should update to at least ImageHandler4 with using any ZC 1.5.x version of ZC. On a side note to that, the information in the tagline doesn't help anyone reading about issues (in the future) that you may post about. The tagline if updated will update throughout the forum website and no longer apply to the conditions referenced by any such post. This is also why it is requested to post the system conditions when attempting to address an issue. It helps in a number of ways: what currently may be the source of the issue, later what may have had a similar problem that relates to other software having the same issue and even better what resolved that issue.Quote:
ZC 1.5.5
Add ons: - Column/Grid 1.3.8 - Dual pricing 1.7 - ImageHandler3
Anyways, glad that the problem was resolved with at least one method of resolution. :)
I have a bucket load of errors in the admin check ceon installation.
A file requires 2 modifications to be made for it but none of the modifications have been made.
I have tried both github and ZC downloads and I get the same errors on 155e. I am using php 5.6.3. I have created the .htaccess file in root and pasted recommended rewrite rules. When I look at my zc150 site I have all of the referenced error files present. So after installing the latest CEON URI Mapping on zc155e, some of the files are completely missing when I run the check installation.
Is this not compatible with 155e? If not, are there plans to make it compatible with future ZC releases?
Thanks
If they are the 2 html_output files, and you are using the files from github, in the readme you will see that those 2 files no longer require editing although the installer check script hasn't been adjusted yet. So you can ignore those 2 warnings. I have this running correctly on 1.5.5e, although it seems some other modification I did after has buggered up ezpages being rewritten, but that's for another post if I can't figure it out...
There are many other files that claim they need to be edited.
I have ceon set to "1". Adding products does not show the usual name your product url option either.
For example, the first error I get is /includes/functions/general.php...
A file requires 2 modifications to be made for it but none of the modifications have been made.
This file is the original dist and has never been modified. And the latest ceon URI does not have that file for 155e, although it is available for earlier ZC versions. So how in the heck can we modify it?
Since the field for URI Mapping in the catalog/products addition is not even there, is it safe to say that the database wasnt modified?
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?Quote:
Originally Posted by 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?
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?
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.Quote:
Originally Posted by pixelpadre
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.Quote:
Originally Posted by lankeeyankee
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.Quote:
Originally Posted by lankeeyankee
I know DivaVocals had posted something further about internal links as well not "all" that long ago. (long enough, but not like years..)
Quote:
Originally Posted by DrByte
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
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.Quote:
Originally Posted by mc12345678
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.
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.Quote:
Originally Posted by mc12345678
Thanks for the pointer!!
I have searched this thread and cannot find the answer that helps me with this when trying to get to my Contact Us page:
This is the ONLY page that does this. the url looks like this when I click the link or tab:Quote:
Not Found
The requested URL /fsr/index.php was not found on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
with a red forward slash through the the https
I do Not have SSL yet.
I am using the latest version of everything.
Thanks a million in advance to anyone that can help me get my Contact Us page to work.
You may not have SSL yet; however, it would appear that your includes/configure.php file has ENABLE_SSL set to true...Quote:
Originally Posted by wtashby
Please provide that portion of your includes/configure.php file.
May also want to review that proposition that "everything else" is working ok. Same issue occurs if attempt to login... (There is a SSL "available" it just isn't yours...)
That was exactly the problem! Thank you! It's working fine now.Quote:
Originally Posted by mc12345678
OK got it working.
The mistake I made was not uploading all v150 and v155a files. I figured since I was using v155e that those were not necessary. Maybe it was a stupid mistake. But I can see that others did the same thing in this thread but probably never resolved their problem. Persistence.
One other mistake.....after I got everything to pass the test, I still wasnt getting any good urls. After about 20 minutes, I remembered, I had to go back to each product or category and regenerate the url.
I would recommend that a new wrapper labeled 155e be created to avoid confusion for future users.
I've just integrated with zen card 1.5.5e, find one part not working in the product listing pagination, can not go to the page, always display page 1.
Any help are welcome!!!
Well, actually need you to help in order for productive help to be given. Please remember, no one but you can see what you are seeing. Somehow others need to be able tosee and reproduce the problem. So, the problem needs to be understood and explained. Furthermore there is a difference between say not belng able to get to a fferent page by clicking on a specific buttn on a specific page and simply typing in the url needed to get to that page. So again in a way the help to you is to help us to help you.Quote:
Originally Posted by ouyangqx
Ok guys, I can't find the answer I'm looking for, though it's probably in these 200 some pages somewhere... How do I add define pages such as contact us, about us, login etc...? please and thank you, John
ZC1.5.5E + CEON 4.5.2
Didn't take much backreading (3 pages back from here) to find an example of what was requested. The linked post shows the field data needed to be entered except the active status is incorrect for the particular situation. The active status of the example should be a 1 and further a destination should have only 1 active uri, all others should be 0.Quote:
Originally Posted by bumba000
https://www.zen-cart.com/showthread....29#post1330629
hey MC, while I do appreciate the response, that was unnecessarily condescending. I started from page one, skipped around a bit and also searched the thread for posts containing "define", "define page", "about us" and so on. How would I have known to go to the end of this thread and move back three pages? The only reason you knew that is because you were involved in the conversation three pages back.
Thanks, John
The about-us entry is not working. When adding the record I get a warning that NULL is not an acceptable value for associated_db_id. The about-us page auto generated link remains as main_page=about_us. If I attempt to access the URL manually .com/about-us it changes to .com/NULL and returns page not found.
Attachment 17130
Unintentionally so.Quote:
Originally Posted by bumba000
For a thread that has existed a long time, it is generally suggested that in absence of reading the entire thread that at least one work backwards from the end a little possibly as much so to the point of the last update. There are those that will read the entire thing, but for the most part issues and things identified early on would be expected to have been resolved and such early beginnings would not likely be as fruitful.
This action and similar manual rewrites are also something described in the instructions, though a direct sql statement was not provided. This was something I had already indicated in a related discussion with you about the topic. It can be found in section 10 of the configuration tab of the instructions.
It appears that the text NULL has been entered rather than using the checkbox to assign as NULL (if entering via phpMyAdmin) also see that one entry has NUL and is left justified like the other entry of NULL on that row. Looking at the row above, one can see that an entry of NULL has been made but is right justified.Quote:
Originally Posted by bumba000
That was definitely the problem. I had typed NULL into the fields and had even misspelled one of them. It works now. Thank you very much!
Welcome!Quote:
Originally Posted by bumba000
ZC v1.5.5e
SBA
CEON 4.5.3
DPU
Dynamic Filter
Zen Magnific
User Tracking
One Page Checkout
CSS_JS Loader
Stirling Grand
I've been using CEON URI Mapping for years on a number of sites, but on one (recently upgraded to CEON v4.5.3 and ZC v1.5.5e) I've found the categories in the breadcrumb are not being rewritten. All other links on the site (inc. categories) are being rewritten just not these.
The includes > init_includes > overrides > init_add_crumbs.php is as in the mod package, not sure where else to look, any suggestions?
Adding the includes>functions>html_output.php modifications present in CEON v4.5.2 seemed to do the job.
This is a bit strange as edits to that file are not required in v4.5.3 - replaced by observers. All observer/class files are present and correct.
(using PHP 7)
I can confirm that the friendly url is not being generated from the breadcrumbs when the notifier added in 1.55 is used
NOTIFY_SEFU_INTERCEPT
in function zen_href_link
instead of the hard-coded CEON code chunk originally included in the CEON URI mapping distribution for html_output.
So in the hope of interesting people who know what they are talking about, a bit of info on a plate.
The breadcrumb link is called from init_add_crumbs: eg:.
So this goes off to html_output to make the link:PHP Code:$breadcrumb->add(HEADER_TITLE_CATALOG, zen_href_link(FILENAME_DEFAULT));
Normally $zco_notifier->notify('NOTIFY_SEFU_INTERCEPT'... would send this off to be modified by \includes\classes\observers\auto.ceon_uri_mapping_link_build.phpPHP Code:function zen_href_link($page = '', $parameters = '', $connection = 'NONSSL', $add_session_id = true, $search_engine_safe = true, $static = false, $use_dir_ws_catalog = true) {
global $request_type, $session_started, $http_domain, $https_domain, $zco_notifier;
$link = null;
$zco_notifier->notify('NOTIFY_SEFU_INTERCEPT', array(), $link, $page, $parameters, $connection, $add_session_id, $static, $use_dir_ws_catalog);
if($link !== null) return $link;
but the observer is not working for the breadcrumbs. It works for all other links.
I assume that this because init_add_crumbs is happening earlier in the page than this observer has been instantiated, but I am bit vague on how this works/how to prove it/fix it.
Here's the autoload debug from my dev shop, its seems CEON gets started before init_crumbs, so any advice would be appreciated...
Quote:
actionPoint=>0 include('includes/version.php');
actionPoint=>0 include('(path...)/includes/classes/class.base.php');
actionPoint=>0 include('(path...)/includes/classes/class.notifier.php');
actionPoint=>0 $zco_notifier = new notifier();
actionPoint=>0 include('(path...)/includes/classes/class.phpmailer.php');
actionPoint=>0 include('(path...)/includes/classes/boxes.php');
actionPoint=>0 include('(path...)/includes/classes/category_tree.php');
actionPoint=>0 include('(path...)/includes/classes/template_func.php');
actionPoint=>0 include('(path...)/includes/classes/split_page_results.php');
actionPoint=>0 include('(path...)/includes/classes/language.php');
actionPoint=>0 include('(path...)/includes/classes/cache.php');
actionPoint=>0 include('(path...)/includes/classes/sniffer.php');
actionPoint=>0 include('(path...)/includes/classes/shopping_cart.php');
actionPoint=>0 include('(path...)/includes/classes/navigation_history.php');
actionPoint=>0 include('(path...)/includes/classes/currencies.php');
actionPoint=>0 include('(path...)/includes/classes/message_stack.php');
actionPoint=>0 include('(path...)/includes/classes/breadcrumb.php');
actionPoint=>0 include('(path...)/includes/classes/query_cache.php');
actionPoint=>0 $queryCache = new QueryCache();
actionPoint=>0 include('(path...)/includes/classes/class.zcPassword.php');
actionPoint=>0 $zcPassword = new zcPassword();
actionPoint=>0 include('(path...)/includes/classes/class.CeonURIMappingHandler.php');
actionPoint=>0 include('(path...)/includes/classes/observers/class.user_tracking.php');
actionPoint=>10 require('includes/init_includes/init_file_db_names.php');
actionPoint=>10 require('includes/init_includes/init_database.php');
actionPoint=>30 $zc_cache = new cache();
actionPoint=>40 require('includes/init_includes/init_db_config_read.php');
actionPoint=>41 require('includes/init_includes/init_notifier_trace.php');
actionPoint=>41 require('includes/init_includes/init_report_all_errors.php');
actionPoint=>50 $sniffer = new sniffer();
actionPoint=>50 require('includes/init_includes/overrides/init_gzip.php');
actionPoint=>50 require('includes/init_includes/init_sefu.php');
actionPoint=>60 require('includes/init_includes/init_general_funcs.php');
actionPoint=>60 require('includes/init_includes/init_tlds.php');
actionPoint=>70 require('includes/init_includes/init_sessions.php');
actionPoint=>71 require('includes/init_includes/init_notifier_trace.php');
actionPoint=>78 include('(path...)/includes/classes/observers/class.products_options_stock_observer.php');
actionPoint=>78 $posObserver = new products_options_stock_observer();
actionPoint=>80 actionPoint=>90 $currencies = new currencies();
actionPoint=>90 include('(path...)/includes/classes/observers/class.ec_analytics.php');
actionPoint=>90 $ec_analytics = new ec_analytics();
actionPoint=>90 include('(path...)/includes/classes/observers/class.perfmon.php');
actionPoint=>90 $perfmon = new perfmon();
actionPoint=>99 $ceon_uri_mapping = new CeonURIMappingHandler();
actionPoint=>100 $template = new template_func();
actionPoint=>100 require('includes/init_includes/init_sanitize.php');
actionPoint=>100 actionPoint=>110 require('includes/init_includes/init_languages.php');
actionPoint=>110 require('includes/init_includes/init_templates.php');
actionPoint=>115 require('includes/init_includes/init_zca_layout.php');
actionPoint=>120 $_SESSION[navigation]->add_current_page();
actionPoint=>120 require('includes/init_includes/overrides/init_currencies.php');
actionPoint=>130 $messageStack = new messageStack();
actionPoint=>130 require('includes/init_includes/overrides/init_customer_auth.php');
actionPoint=>139 require('includes/init_includes/init_posm_product_valid.php');
actionPoint=>140 require('includes/init_includes/init_cart_handler.php');
actionPoint=>150 require('includes/init_includes/init_special_funcs.php');
actionPoint=>160 $breadcrumb = new breadcrumb();
actionPoint=>160 require('includes/init_includes/init_category_path.php');
actionPoint=>161 require('includes/init_includes/overrides/init_canonical.php');
actionPoint=>170 require('includes/init_includes/overrides/init_add_crumbs.php');
actionPoint=>175 require('includes/init_includes/init_observers.php');
actionPoint=>180 require('includes/init_includes/overrides/init_header.php');
actionPoint=>190 include('(path...)/includes/classes/observers/class.products_viewed_counter.php');
actionPoint=>190 $products_viewed_counter = new products_viewed_counter();
actionPoint=>190 include('(path...)/includes/classes/observers/class.search_log.php');
actionPoint=>190 $search_log = new search_log();
actionPoint=>199 $user_tracking_observe = new user_tracking();
actionPoint=>200 include('(path...)/includes/classes/observers/class.advshipperCheckoutProcess.php');
actionPoint=>200 $advshipper_checkout_process = new advshipperCheckoutProcess();
actionPoint=>200 include('(path...)/includes/classes/observers/class.back_in_stock_notificationsAccount.php');
actionPoint=>200 $back_in_stock_notifications_account = new back_in_stock_notificationsAccount();
actionPoint=>200 include('(path...)/includes/classes/observers/class.back_in_stock_notificationsProductInfo.php');
actionPoint=>200 $back_in_stock_notifications_product_info = new back_in_stock_notificationsProductInfo();
actionPoint=>200 include('(path...)/includes/classes/dynamic_price_updater.php');
actionPoint=>200 include('(path...)/includes/classes/observers/class.emailFor404.php');
actionPoint=>200 $emailFor404 = new emailFor404();
actionPoint=>200 include('(path...)/includes/classes/observers/class.emp_order_observer.php');
actionPoint=>200 $emp_order_observer = new emp_order_observer();
I don't have a copy of the updated Ceon URI up/open to see how the observer is incorporated, but seeing that there is no specific call to the observer, then it loads at point 175 which is after the crumbs ran at 170. So to specifically support the rewrite of the breadcrumbs, the Ceon observer would need to load before the breadcrumb of 170. This would be accomplished by adding an includes/autoloader file to specifically load at least that one observer point prior to 170 (168?).
Great. I swapped around the breakpoints in config.core (init_observers at 170 and init_add_crumbs at 175) and all appears to be working now.
Thanks for the quick response.
PHP Code:/** STEVE swapped 170 and 175 around to allow breadcrumbs to be handled by observer
* Breakpoint 170.
*
* require('includes/init_includes/init_observers.php');
*
*/
$autoLoadConfig[170][] = array('autoType'=>'init_script',
'loadFile'=> 'init_observers.php');
/**
* Breakpoint 175.
*
* require('includes/init_includes/init_add_crumbs.php');
*
*/
$autoLoadConfig[175][] = array('autoType'=>'init_script',
'loadFile'=> 'init_add_crumbs.php');
That may have shown proof of concept, but is not an ideal solution to what could be corrected with a minor change of the plugin rather than ZC core code.Quote:
Originally Posted by torvista
Please see https://github.com/mc12345678/CEON-U...0c83abf882e64f
mc, thank you for that GitHub fork. All's working fine now.
Welcome, though if I didn't know any better it seems Torvista put a lot of effort into making changes supporting the above discovery in the main/parent repository.Quote:
Originally Posted by simon1066
Coming from my corner of semi-php-literate, I am of this line of thinking:Quote:
That may have shown proof of concept, but is not an ideal solution to what could be corrected with a minor change of the plugin rather than ZC core code.
1) breadcrumbs uses the zen_href_link function,
2) zen_href_link has a notifier available...so that notifier should be available for anything that wants to use it.
It doesn't work, because the breadcrumbs code is loaded before the notifier-observer code.
So that notifier (nor any, I imagine) does not work.
That seems like a core bug to me and nothing to do with any external code that may use the notifier...?
This is the content from the top of includes/init_includes/init_observers.php:Quote:
Originally Posted by torvista
It describes how this particular feature of ZC can be used and identifies that if the load point provided doesn't suit the desire operation then to incorporate an alternate means of loading the necessary observer.Code:/**
* auto-load and instantiate all /includes/classes/observers/auto.xxxxxxxxx.php classes
*
* This looks for any files in the DIR_WS_CLASSES/observers folder matching the naming convention of "auto.XXXXXX.php"
* It then automatically "include"s those files.
* And then it checks to see whether the XXXXXXXXX part of the filename matches a class name using "zcObserver" + the CamelCased XXXXXXXXX string.
* ie: zcObserverTemplateFrameworkAbc would match auto.template_framework_abc.php
* If the properly named class exists, then it instantiates that class using an object of the same name. If the class inside the file is NOT properly named, it will NOT be instantiated, despite being loaded.
*
* The assumption is that the class is an observer class which properly extends the base class.
* All normal observer class behavior applies.
*
* This fires at AutoLoader point 175, so all previously-processed system dependencies are in place.
* If you need an observer class to fire at a much earlier point so it fires before other system processes, you'll need to add your own auto_loaders/config.yyyyy.php file with relevant rules to load those observers.
*
Based on the explained logic above that snippet, then one would say that the file should load well before 175 because there are observers throughout the ZC code not just the one that is affected by init_breadcrumbs. It's a sound thought that the fix be to move the load up sooner, but at what cost to the overall process. There are likely those programs that use the auto. style of observer and may actually need it to be at 175 or after the breadcrumbs, modifying the core load sequence to suit the program when the program could be modified to integrate with the core is not the same thing.
Of course, thank you Torvista.Quote:
Originally Posted by mc12345678
Just to confirm that my Github is now updated with the solution recommended above.
If I put a store with this mod in a subdirectory, none of the URIs work anymore.
mysite.com/Category works fine but
mysite.com/upgrade/Category fails
Has anyone else dealt with this?
Assumption for the below is that after the move, the uri for the associated failing product has not been regenerated. This is as compared to moving the store into a directory, creating a new uri and that uri failing. I am below addressing the first situation, not the second based on my understanding of the question and condition(s) provided.Quote:
Originally Posted by swguy
Yes. By moving the store into or out of a directory, the uris have technically changed and need to be created/recreated as the new active uris with the old active uris made not-current so that the old links will still direct to/reach the now current uri of the same product.
This is one reason that it is recommended when pre-creating a store or when testing operation that a sub-domain having the same directory structure of the end store is recommended. In this way, effectively the HTTP_SERVER changes but not the DIR_WS_CATALOG.
You have to rerun the ceon_uri_mapping_installation_check.php. I get that. But after updating my .htaccess, I'm still getting 404s with every combination of the final rewrite rule.Quote:
Originally Posted by mc12345678
RewriteRule .* /my_site/index.php [QSA,L]
RewriteRule .* my_site/index.php [QSA,L]
RewriteRule .* /index.php [QSA,L]
RewriteRule .* index.php [QSA,L]
and I'm not sure how to debug that.
Does the sub-directory also have an .htaccess as a result of the move?Quote:
Originally Posted by swguy
I have another problem, I have a slide in the home that takes the product id from the db, if I read the source code I notice that the link of the category or the product link is not generated by ceon uri I products = id etc. clicking does a normal thing, but SEOs have links on the page with rederict 301 is not the best. How can I do to generate the correct links without cpath etc.
$productlink=HTTP_SERVER . DIR_WS_CATALOG.'index.php?main_page=product_info&cPath='.$cpath.'&products_id='. $products_id;
$showmorelink=HTTP_SERVER . DIR_WS_CATALOG.'index.php?main_page=index&cPath='.$cpath;
<a href="<?php echo $productlink; ?>"><span class="a-btn-text">Buy now</span></a>
<a href="<?php echo $showmorelink; ?>"><span class="a-btn-slide-text">More</span></a>
replying from my phone, so I can not give the right syntax, but you should use the zen_href_link function, instead of the hardcoded link.Quote:
Originally Posted by diamond1
Hi, you can give me an example
When you can of course hihih
Torvista can you help me? do I get the solution?
To maximize the possible operation, I think this will accomplsh what was requested:
Code:$productlink = zen_href_link(zen_get_info_page($products_id), 'cPath=' . ( ($_GET['manufacturers_id'] > 0 and $_GET['filter_id']) > 0 ? zen_get_generated_category_path_rev($_GET['filter_id']) : $_GET['cPath'] > 0 ? zen_get_generated_category_path_rev($_GET['cPath']) : zen_get_generated_category_path_rev(zen_get_products_category_id($products_id)) . '&products_id=' . $products_id);
$cPath_new = 'cPath=' . $_GET['cPath'];
// strip out 0_ from top level cats
$cPath_new = str_replace('=0_', '=', $cPath_new);
$showmorelink = zen_href_link(FILENAME_DEFAULT, $cPath_new);
I should not get a white page.
Quote:
Originally Posted by mc12345678
A closing parenthesis was missing from the first line:
In the future, please remember that a blank screen will more than likely have generated a myDebug log in the logs folder as identified in this FAQ: https://www.zen-cart.com/content.php?124-blank-pageCode:$productlink = zen_href_link(zen_get_info_page($products_id), 'cPath=' . ( ($_GET['manufacturers_id'] > 0 and $_GET['filter_id']) > 0 ? zen_get_generated_category_path_rev($_GET['filter_id']) : $_GET['cPath'] > 0 ? zen_get_generated_category_path_rev($_GET['cPath']) : zen_get_generated_category_path_rev(zen_get_products_category_id($products_id)) . '&products_id=' . $products_id));
$cPath_new = 'cPath=' . $_GET['cPath'];
// strip out 0_ from top level cats
$cPath_new = str_replace('=0_', '=', $cPath_new);
$showmorelink = zen_href_link(FILENAME_DEFAULT, $cPath_new);
No
it remains as it does before but does not show rewriting
<a href="https://mozit:8890/index.php?main_page=product_info&cPath=7&products_id=33"><span class="a-btn-text">Buy</span></a> <a href="https://mozit:8890/index.php?main_page=index&cPath=7"><span class="a-btn-slide-text">More</span></a>
Sorry I made a mistake for the product, but for the category I get it
<href="https://mozit:8890/index.php?main_page=index&cPath=">
Quote:
Originally Posted by diamond1
Or:Code:$productlink = zen_href_link(zen_get_info_page($products_id), 'cPath=' . ( ($_GET['manufacturers_id'] > 0 and $_GET['filter_id']) > 0 ? zen_get_generated_category_path_rev($_GET['filter_id']) : $_GET['cPath'] > 0 ? zen_get_generated_category_path_rev($_GET['cPath']) : zen_get_generated_category_path_rev(zen_get_products_category_id($products_id)) . '&products_id=' . $products_id));
$cPath_new = 'cPath=' . ( ($_GET['manufacturers_id'] > 0 and $_GET['filter_id']) > 0 ? zen_get_generated_category_path_rev($_GET['filter_id']) : $_GET['cPath'] > 0 ? zen_get_generated_category_path_rev($_GET['cPath']) : zen_get_generated_category_path_rev(zen_get_products_category_id($products_id));
// strip out 0_ from top level cats
$cPath_new = str_replace('=0_', '=', $cPath_new);
$showmorelink = zen_href_link(FILENAME_DEFAULT, $cPath_new);
Code:$productlink = zen_href_link(zen_get_info_page($products_id), 'cPath=' . ( ($_GET['manufacturers_id'] > 0 and $_GET['filter_id']) > 0 ? zen_get_generated_category_path_rev($_GET['filter_id']) : $_GET['cPath'] > 0 ? zen_get_generated_category_path_rev($_GET['cPath']) : zen_get_generated_category_path_rev(zen_get_products_category_id($products_id)) . '&products_id=' . $products_id));
$cPath_new = 'cPath=' . $cPath;
// strip out 0_ from top level cats
$cPath_new = str_replace('=0_', '=', $cPath_new);
$showmorelink = zen_href_link(FILENAME_DEFAULT, $cPath_new);
No, the first white page code, the second does not change anything forever
<href="https://mozit:8890/index.php?main_page=index&cPath=">
In this:Quote:
Originally Posted by diamond1
Remove the extra parentheses (highlighted above):Code:$productlink = zen_href_link(zen_get_info_page($products_id), 'cPath=' . ( ($_GET['manufacturers_id'] > 0 and $_GET['filter_id']) > 0 ? zen_get_generated_category_path_rev($_GET['filter_id']) : $_GET['cPath'] > 0 ? zen_get_generated_category_path_rev($_GET['cPath']) : zen_get_generated_category_path_rev(zen_get_products_category_id($products_id)) . '&products_id=' . $products_id));
$cPath_new = 'cPath=' . ( ($_GET['manufacturers_id'] > 0 and $_GET['filter_id']) > 0 ? zen_get_generated_category_path_rev($_GET['filter_id']) : $_GET['cPath'] > 0 ? zen_get_generated_category_path_rev($_GET['cPath']) : zen_get_generated_category_path_rev(zen_get_products_category_id($products_id));
// strip out 0_ from top level cats
$cPath_new = str_replace('=0_', '=', $cPath_new);
$showmorelink = zen_href_link(FILENAME_DEFAULT, $cPath_new);
Thought that before, the use of $cPath provided a result? Ohh, sorry: it was $cpath instead as shown here:Code:$productlink = zen_href_link(zen_get_info_page($products_id), 'cPath=' . ( ($_GET['manufacturers_id'] > 0 and $_GET['filter_id']) > 0 ? zen_get_generated_category_path_rev($_GET['filter_id']) : $_GET['cPath'] > 0 ? zen_get_generated_category_path_rev($_GET['cPath']) : zen_get_generated_category_path_rev(zen_get_products_category_id($products_id)) . '&products_id=' . $products_id));
$cPath_new = 'cPath=' . ($_GET['manufacturers_id'] > 0 and $_GET['filter_id']) > 0 ? zen_get_generated_category_path_rev($_GET['filter_id']) : $_GET['cPath'] > 0 ? zen_get_generated_category_path_rev($_GET['cPath']) : zen_get_generated_category_path_rev(zen_get_products_category_id($products_id));
// strip out 0_ from top level cats
$cPath_new = str_replace('=0_', '=', $cPath_new);
$showmorelink = zen_href_link(FILENAME_DEFAULT, $cPath_new);
So the second "form" could be:Quote:
Originally Posted by diamond1
Code:$productlink = zen_href_link(zen_get_info_page($products_id), 'cPath=' . ( ($_GET['manufacturers_id'] > 0 and $_GET['filter_id']) > 0 ? zen_get_generated_category_path_rev($_GET['filter_id']) : $_GET['cPath'] > 0 ? zen_get_generated_category_path_rev($_GET['cPath']) : zen_get_generated_category_path_rev(zen_get_products_category_id($products_id)) . '&products_id=' . $products_id));
$cPath_new = 'cPath=' . $cpath;
// strip out 0_ from top level cats
$cPath_new = str_replace('=0_', '=', $cPath_new);
$showmorelink = zen_href_link(FILENAME_DEFAULT, $cPath_new);
now it works perfectly with the second, you've been very kind thanks thanks
Hi,
I was about to install CEON URI into a zc155e and came here to confirm there were no conflicts. I read thru the conversation about breadcrumb issues and would prefer to avoid them.
I have two questions. First, both Torvista and MC supply github links... which should I use?
Second, Torvista's version is updated for php7 but I'm still running v5.5.38. Am I out of luck or is the php 7 version backwards compatible?
I would suggest torvista's version for now as I created one just to push a change and to carry a conversation.Quote:
Originally Posted by Feznizzle
As for changes to support php 7, changes that have generally been made/needed to support php 7 are conditions that have existed for php 5.x but had not been implemented because they weren't required then. So, you should generally be okay with php 5.5.x and software that supports php 7.
I haven't looked yet, but torvista indicated that he carried over the change we discussed about breadcrumbs. I took his word for it in his previous post indicating that he updated the repo.
Worked perfect, thanks!
Good to hear, that's the sort of post I'd like to see more often!Quote:
Worked perfect, thanks!
I have a zc155e with torvista's version of CEON URI.
Today I noticed that the .htaccess contains a reference to my renamed admin folder:
# Don't rewrite admin directory
RewriteCond %{REQUEST_URI} !^/admin_renamed [NC]
This left me with some questions.
FIRST:
Can the .htaccess be sniffed out? Or is it readable only by my server?
SECOND:
Can I safely remove that "don't rewrite" reference altogether? I experimented with that, deleting it from my .htaccess entirely. There seem to be no problems whatsoever.
THIRD:
I found some code (haven't experimented with it yet) for denying access:
Would applying that code cause any problems?Quote:
<FilesMatch "^\.ht">
Order allow,deny
Deny from all
Satisfy All
</FilesMatch>
Never mind, sorry!
Apache is configured by default to deny access to ht files.
Quote:
Originally Posted by Feznizzle
Glad you figured 1 and 3 out on your own and posted back.Quote:
Originally Posted by Feznizzle
Regarding 2, it somewhat depends on how the directory is called/used. Basically though without an exclusion of the directory, then if that directory is added to the url, it will attempt to be rewritten. If there is no rewrite for that portion of the path then the response will be as if a page is not found, even though the contents may be present.
As the installation test diagnostics indicate, there are various ways that the htaccess can be written to perform the identification of the need to rewrite or to go directly to a folder/file. The specific method implemented prevents access to a new folder that is added to the server by way of the web browser if it is not added to the exclusion list. Another method of implementation is to evaluate the browser path, determine if the path identifies a folder or file, if it does then use that path otherwise send it to be processed by ZC which would perform the rewriting.
Thanks for the additional insight!
We need to update the htaccess file to allow renewal of certificates. The problem is with the .well-known directory and rewrite rules in the htaccess. If I try to renew with the htaccess file I get a server timeout error. If I rename or delete the htaccess file certificate renewal is possible.
So what are the contents of your .htaccess file? What is the suggestion for the contents as made by the Ceon URI Mapping installation software as run on your current arrangement?Quote:
Originally Posted by pixelpadre
Geez you really know how to lead a fella around by his nose.............
After creating well-known directory, it was necessary to login to admin and re run ceon to generate a new htaccess file. Thanks MC.
Glad to help, sorry to have been so direct about it. (previous more discussion based direction apparently didn't get the point across as well.)Quote:
Originally Posted by pixelpadre
I am getting a 404 error again on a different site. Last time the problem was not uploading earlier files. This time I cant figure it out. I am not seeing any error on the server or ZC log files despite getting 404 error. Where can I find the error files?
The server logs would contain the error. Ability to access those is dependent on the host's permissions to the hosted account. Typical problems relate to things like a direct issue with the .htaccess that is in the root of the domain name, an .htaccess "above" that, or if the store is in a sub-directory off of the domain's path and the sub-directory also has an .htaccess.Quote:
Originally Posted by pixelpadre
If direct access to the server logs is not available, then the host should be able to identify the pertinent information.
I am using centos 7 and have complete control over the server.
hello
I am using Ceon Uri last version downloaded today and i have a problem with the reviews. the url seems fine but don't work :
ex : "https://www.ios.fr/index.php?main_page=reviews" give me all the reviews with their url, here no problem but when i want to go to a specific review, the url like https://www.ios.fr/cours-gestion/support-de-cours-sage-paie-i7/review?reviews_id=45" doesn't work.
https://www.ios.fr/cours-gestion/sup...s-sage-paie-i7 is ok
https://www.ios.fr/cours-gestion/sup...paie-i7/review is ok
https://www.ios.fr/cours-gestion/sup...?reviews_id=45 is not ok bur the review_id "45" is fine
The check of ceon is ok. I try to disable "automanage reviews page" without success.
Somebody has an idea ?
When identifying "doesn't work", it helps to explain what that means, what is happening, what "doesn't work", etc. Or something more specific.Quote:
Originally Posted by bilbaxo
I attempted to access: https://www.ios.fr/cours-gestion/sup...?reviews_id=45
And was presented with an error message: WARNING: An Error occurred, please refresh the page and try again.
When such a message occurs (which may not be related to this plugin), suggest reading the following FAQ: https://www.zen-cart.com/content.php...-and-try-again
Further, to identify if it is related to this plugin or not would be to disable it and try with a standard dynamic link and if that doesn't resolve it to attempt with the associated .htaccess rules removed or the file removed.
good idea !
And yes I have the same problem with ceon desactivated and the htaccess without the ceon lines.
So it is zencart and not ceon but i just don't see the problem.
I have no access to the logs directory (too much files ?)
Access to the logs directory can depend on the method of trying to reach the directory. I have seen some web browser based ftp programs that will "hide" the logs directory because it is named logs, if it is that you can see the directory, but are unable to see a list of files within it (takes too long to load), you could rename it, create a new one, upload the files that are in a default version of ZC (.htaccess and associated index file, etc..) and then attempt the operation again. If the previous one had too many logs in it, then it may fill up fast again. Start with the most recent log file/error, try to eliminate that then continue until new log files are not created for the operation that you are trying to perform.Quote:
Originally Posted by bilbaxo
There are a number of ways to address, but I would suggest starting a new thread or building on one that is directly related to the specific issue found/identified causing the additional log/errors. (or as necessary to troubleshoot why you are unable to access the logs directory). In either case, while this turned out to be a good starting point for your particular issue, it is not caused by Ceon URI Mapping and therefore should be addressed in a more appropriate location. :)
Hello - I've used Magic SEO urls for years... I'm planning to make the switch to CEON (mainly because Magic doesn't work with SitemapXML) and wanted to know if you had any advise before I begin. Like - should I uninstall Magic after installing CEON, because how else would my current url's get indexed and mapped? (I hope my terminology is correct...) And yet, it seems like there could be problems if I have two re-write programs running at the same time, however brief.
Any other advice would be greatly appreciated!
I'm currently on ZenCart vs 1.5.5e - having upgraded several times since I started with 1.3.6 in 2006
Thanks a million in advance.
To maintain the links that you have currently, you will want to gather the existing links as provided by Magic SEO before final transition to using Ceon URI Mapping. The software is written generally to support being installed (but inactive) along another URI mapper, but only one should be active at any one time. Should be possible to remove/disable the other and enable Ceon URI Mapping and continue moving forward without issue, though suggested to test (practice) that on a development location.Quote:
Originally Posted by Three Sisters
One way to get most if not all of the URIs is to use Easy Populate V4 to export and to include the URIs in the export (admin setting). As the export file is created the store side URI will be generated/collected as would be displayed on the store front and that information can then be used to populate the Ceon URI Mapping database table. Then if you wish to change the URIs away from the old style, the old URIs will remain reachable with the new URI taking its place.
Another tip, if you plan on building your database outside of the live store, then it is suggested that your temporary/development store be reached by using a sub-domain with the store setup in the same directory (or lack of) as intended for your live store. (ie. domain/store === subdomain/store) That way the database table can be transferred/used without edit.
Thank you @mc12345678 - was great and easy-to-follow advice!
I do use Easy Populate 4 - but on trying the export idea I found that the URI's were in the traditional ZenCart format. Which is the problem I get with SitemapXML - it appears neither program can read the encrypted file that generates the attractive URI's. Thus... the reason I want to switch to CEON. Not quite sure how I'm going to get this to happen without loosing my 10+ years of link history. I'm half wondering if CEON will be able to do it's initial read and map of the URI's either..... Once again, I find myself wishing I was more skilled! :blush:
The public version of Ceon URI Mapping will only generate a URI when the product is saved through the edit page. There are ways available to auto-generate the uris (many published in here as well as searchable via the internet). Ceon did have a commercial version that would auto-generate, but that doesn't appear to be yet again available.Quote:
Originally Posted by Three Sisters
An important question ro answer related to the existing uris would be what was the format generated? Maybe one of the other methods could easily and quickly generate them again from the existing data? Ie. Is the uri based on the category and product name only? Or is there extra information? We're they able to be entered independently or uniquely?
As for ways to regenerate what already exists, there may be some programmatic way to visit/retrieve the data and store it in a file. It mostly depends on the hooks of the software into the system and then the ease of visiting "everything"...
The Ceon software supports identifying any uri to the destination, just need to know what it is or what would be desired. :)
I am beginning to think I am misunderstanding what this program does... So, if I upload products via Easy Populate 4 and then don't open each one and edit it in the admin panel, the nice URI will not be generated unless I adapt this program by some other auto-generating means? Currently, Magic generates the URI the first time someone opens the product page from the shopping cart - I thought I understood this would do the same.Quote:
Originally Posted by mc12345678
It would be very easy to duplicate the URI's. Currently, the Magic uses: /category-name-and-id-01/product-name-and-id-52.html Easy pages are the only ones that, although they are done similarly, break this format.Quote:
Originally Posted by mc12345678
Not quite sure what "hooks" you mean, but the software only uses one file besides an edited .htaccess file; however the file is encrypted so no hope of finding anything about its behaviors from the file. (Upon initial install a cache/fancy-data folder is also added where, after the software is run, each and every category, sub-category, product, review, easy-page, etc has a file with one line including the name with spaces converted to dashes and the id - but it is not written in the exact order of the new URI.) When you mention the possible need for programmatically visiting/retrieving currently exiting URI data - that would be because of the inability for programs to see the nice URI's, correct? Not because it doesn't NORMALLY attempt to map exisiting URI's (from either a standard ZenCart format or perhaps another open source SEO URI re-writer) to the ones created?Quote:
Originally Posted by mc12345678
Maybe you can clarify this for my simple mind... I think I may be conflating several things software like this does. Are you saying CEON will scan and find any URI's that point to a certain product and then map it to whatever new URI CEON has created either through automatic generation or by hand in admin via edit product?Quote:
Originally Posted by mc12345678
And - perhaps this is a conversation for another topic - but since you are being so kind and explain things so well (thank you very, very much!) perhaps you can tell me if I am simply attempting something that doesn't even need to be done. When SitemapXML generates its sitemaps the links all look like "normal" Zencart links. If you click on them, you land on the correct web page with the "nice" URI that Magic generated. Is this OK - or is it an SEO problem that I really should address?
just installed on german zc 1.5.0
works like a charm :)
Thank you!
Successfully installed on Zen-Cart 1.5.5f with TPP, SitemapXML. Slight change to .htacces:
# Handle all other URIs using Zen Cart (its index.php)
Changed:
RewriteRule .* index.php [QSA,L]
To:
RewriteRule ^(.*)$ /index.php?path=$1 [NC,L,QSA]
After main page was giving an error/not showing up.
I thought it might help someone else.
I've updated to 155f , php 7.1 and CEON php7 .... and maybe this in not the right place to ask , but anyway here it goes:
I got issues! :smile:
Categories menu links are ok, but products ( canonical, breadcrumb ) are not.
I also had the breadcrumbs to work with product type handler ( or term) bookx like this:
$typefilter_parameters are ok, so I guess all this should be confined to the html_output.php or as I was reading the auto_loaders position.PHP Code:if ($get_term_breadcrumb->RecordCount() > 0) {
// BEGIN CEON URI MAPPING 1 of 2
// Set the required parameters so that an attempt can be made to map the link to any static URI for the
// filtered page
$typefilter_parameters = '';
if ($get_terms->fields['get_term_name'] != 'manufacturers_id') {
$fix_bookx_term = explode('_',$get_terms->fields['get_term_name'] );
//@ALTERED for Bookx terms
if( $fix_bookx_term['0'] == 'bookx') {
$typefilter_parameters = 'typefilter=' . $fix_bookx_term['0'] . '&';
} else {
$typefilter_parameters = 'typefilter=' . str_replace('_id', '', $get_terms->fields['get_term_name']) . '&';
}
}
$typefilter_parameters .=
$get_terms->fields['get_term_name'] . '=' . $_GET[$get_terms->fields['get_term_name']];
$breadcrumb->add($get_term_breadcrumb->fields[$get_terms->fields['get_term_name_field']],
zen_href_link(FILENAME_DEFAULT, $typefilter_parameters));
/*
// END CEON URI MAPPING 1 of 2
$breadcrumb->add($get_term_breadcrumb->fields[$get_terms->fields['get_term_name_field']], zen_href_link(FILENAME_DEFAULT, $get_terms->fields['get_term_name'] . "=" . $_GET[$get_terms->fields['get_term_name']]));
// BEGIN CEON URI MAPPING 2 of 2
*/
// END CEON URI MAPPING 2 of 2
}
}
Anyway, I've check and diff the html_output with the CEON 4.5.3 and I'm completely lost .
So maybe this is related to the auto_loaders position...
Sorry for the long report , but perhaps you could give a clue about this:
Code:[autoLoadConfig] => Array
(
[0] => Array
(
[0] => Array
(
[autoType] => include
[loadFile] => includes/version.php
)
[1] => Array
(
[autoType] => class
[loadFile] => class.base.php
)
[2] => Array
(
[autoType] => class
[loadFile] => class.notifier.php
)
[3] => Array
(
[autoType] => classInstantiate
[className] => notifier
[objectName] => zco_notifier
)
[4] => Array
(
[autoType] => class
[loadFile] => class.phpmailer.php
)
[5] => Array
(
[autoType] => class
[loadFile] => boxes.php
)
[6] => Array
(
[autoType] => class
[loadFile] => category_tree.php
)
[7] => Array
(
[autoType] => class
[loadFile] => template_func.php
)
[8] => Array
(
[autoType] => class
[loadFile] => split_page_results.php
)
[9] => Array
(
[autoType] => class
[loadFile] => language.php
)
[10] => Array
(
[autoType] => class
[loadFile] => cache.php
)
[11] => Array
(
[autoType] => class
[loadFile] => sniffer.php
)
[12] => Array
(
[autoType] => class
[loadFile] => shopping_cart.php
)
[13] => Array
(
[autoType] => class
[loadFile] => navigation_history.php
)
[14] => Array
(
[autoType] => class
[loadFile] => currencies.php
)
[15] => Array
(
[autoType] => class
[loadFile] => message_stack.php
)
[16] => Array
(
[autoType] => class
[loadFile] => breadcrumb.php
)
[17] => Array
(
[autoType] => class
[loadFile] => query_cache.php
)
[18] => Array
(
[autoType] => classInstantiate
[className] => QueryCache
[objectName] => queryCache
[checkInstantiated] => 1
)
[19] => Array
(
[autoType] => class
[loadFile] => class.zcPassword.php
)
[20] => Array
(
[autoType] => classInstantiate
[className] => zcPassword
[objectName] => zcPassword
)
[21] => Array
(
[autoType] => class
[loadFile] => class.CeonURIMappingHandler.php
)
[22] => Array
(
[autoType] => class
[loadFile] => observers/class.ceon_uri_mapping_link_build.php
)
)
[10] => Array
(
[0] => Array
(
[autoType] => init_script
[loadFile] => init_file_db_names.php
)
[1] => Array
(
[autoType] => init_script
[loadFile] => init_database.php
)
[2] => Array
(
[autoType] => class
[loadFile] => observers/class.bookx_observers.php
)
[3] => Array
(
[autoType] => class
[loadFile] => observers/class.tpl_pb.php
)
[4] => Array
(
[autoType] => init_script
[loadFile] => init_tpl_pb.php
)
)
[30] => Array
(
[0] => Array
(
[autoType] => classInstantiate
[className] => cache
[objectName] => zc_cache
)
)
[40] => Array
(
[0] => Array
(
[autoType] => init_script
[loadFile] => init_db_config_read.php
)
)
[50] => Array
(
[0] => Array
(
[autoType] => classInstantiate
[className] => sniffer
[objectName] => sniffer
)
[1] => Array
(
[autoType] => init_script
[loadFile] => init_gzip.php
)
[2] => Array
(
[autoType] => init_script
[loadFile] => init_sefu.php
)
)
[60] => Array
(
[0] => Array
(
[autoType] => init_script
[loadFile] => init_general_funcs.php
)
[1] => Array
(
[autoType] => init_script
[loadFile] => init_tlds.php
)
)
[70] => Array
(
[0] => Array
(
[autoType] => init_script
[loadFile] => init_sessions.php
)
)
[80] => Array
(
[0] => Array
(
[autoType] => classInstantiate
[className] => shoppingCart
[objectName] => cart
[checkInstantiated] => 1
[classSession] => 1
)
)
[90] => Array
(
[0] => Array
(
[autoType] => classInstantiate
[className] => currencies
[objectName] => currencies
)
[1] => Array
(
[autoType] => classInstantiate
[className] => productTypeFilterObserver
[objectName] => productTypeFilterObserver
)
[2] => Array
(
[autoType] => class
[loadFile] => observers/class.reward_points.php
)
[3] => Array
(
[autoType] => classInstantiate
[className] => RewardPoints
[objectName] => RewardPoints
)
[4] => Array
(
[autoType] => classInstantiate
[className] => class_tpl_pb
[objectName] => class_tpl_pb
)
)
[99] => Array
(
[0] => Array
(
[autoType] => classInstantiate
[className] => CeonURIMappingHandler
[objectName] => ceon_uri_mapping
)
)
[100] => Array
(
[0] => Array
(
[autoType] => classInstantiate
[className] => template_func
[objectName] => template
)
[1] => Array
(
[autoType] => init_script
[loadFile] => init_sanitize.php
)
[2] => Array
(
[autoType] => classInstantiate
[className] => navigationHistory
[objectName] => navigation
[checkInstantiated] => 1
[classSession] => 1
)
)
[110] => Array
(
[0] => Array
(
[autoType] => init_script
[loadFile] => init_languages.php
)
[1] => Array
(
[autoType] => init_script
[loadFile] => init_templates.php
)
)
[115] => Array
(
[0] => Array
(
[autoType] => init_script
[loadFile] => init_zca_layout.php
)
)
[120] => Array
(
[0] => Array
(
[autoType] => objectMethod
[objectName] => navigation
[methodName] => add_current_page
)
[1] => Array
(
[autoType] => init_script
[loadFile] => init_currencies.php
)
)
[130] => Array
(
[0] => Array
(
[autoType] => classInstantiate
[className] => messageStack
[objectName] => messageStack
)
[1] => Array
(
[autoType] => init_script
[loadFile] => init_customer_auth.php
)
)
[140] => Array
(
[0] => Array
(
[autoType] => init_script
[loadFile] => init_cart_handler.php
)
)
[150] => Array
(
[0] => Array
(
[autoType] => init_script
[loadFile] => init_special_funcs.php
)
)
[160] => Array
(
[0] => Array
(
[autoType] => classInstantiate
[className] => breadcrumb
[objectName] => breadcrumb
)
[1] => Array
(
[autoType] => init_script
[loadFile] => init_category_path.php
)
)
[161] => Array
(
[0] => Array
(
[autoType] => init_script
[loadFile] => init_canonical.php
)
)
[165] => Array
(
[0] => Array
(
[autoType] => classInstantiate
[className] => CeonUriMappingLinkBuild
[objectName] => ceon_uri_mapping_link_build
)
)
[170] => Array
(
[0] => Array
(
[autoType] => init_script
[loadFile] => init_add_crumbs.php
)
)
[175] => Array
(
[0] => Array
(
[autoType] => init_script
[loadFile] => init_observers.php
)
)
[180] => Array
(
[0] => Array
(
[autoType] => init_script
[loadFile] => init_header.php
)
)
[190] => Array
(
[0] => Array
(
[autoType] => class
[loadFile] => observers/class.google_recaptcha.php
)
[1] => Array
(
[autoType] => classInstantiate
[className] => google_recaptcha
[objectName] => google_recaptcha
)
[2] => Array
(
[autoType] => class
[loadFile] => observers/class.products_viewed_counter.php
)
[3] => Array
(
[autoType] => classInstantiate
[className] => products_viewed_counter
[objectName] => products_viewed_counter
)
)
)
This is atypical of a standard ZC install. What is installed that is "reading" the path parameter? Path on the uri is not a part of ZC code, nor part of Ceon URI Mapping. Glad it works for this install, but some perspective would help others.Quote:
Originally Posted by devlyn
It's unfortunate that having issues; however, it's difficult to identify a solution to a problem that isn't explained, what the issues are, what notifications/errors are reported, etc...Quote:
Originally Posted by mesnitu
The autoLoadConfig array provided identifies that at least the modifications implemented in the software for the breadcrumbs are loaded before attempting to access the breadcrumbs.
As to the modification made in the breadcrumbs file, while not sure what value is returned for bookx from $get_terms->fields['get_term_name'] other than expecting it to begin with bookx_, but the code there appears to handle the situation correctly to support addressing the bookx product type as compared to the ZC default that includes _id on the end of it.
ThanksQuote:
Originally Posted by mc12345678
Yeap... but there's nothing to report. Not errors or logs.
Even if I paste a uri from the database it works on the url.
uri (/romances/romance/o-deserto-dos-tartaros/) main_page(product_bookx_info)
Even the bookx filters are working, categories, etc...
The products listings links are the issue...
This is a different product type but.... The only thing I can report it's I had this working with 155e, php 5.6.3 and the Ceon 4.5.2
I don't remember doing anything for CEON to recognize the product_bookx_info. But... I've done so much stuff in this site , that I be 100% sure
I digging into CEON class.CeonURIMappingHREFLinkBuilder but no luck yet.