Ok, I know now it's something related with the product_book_info
If I insert a "regular" product it works fine.
Still don't remember what I've done.
Getting closer.
Thanks
Printable View
Ok, I know now it's something related with the product_book_info
If I insert a "regular" product it works fine.
Still don't remember what I've done.
Getting closer.
Thanks
You should have done what is recommended (I think in the instructions) of updating: includes/extra_datafiles/ceon_uri_mapping_product_pages.phpQuote:
Originally Posted by mesnitu
To reflect the issue. So, there's the problem you were talking about, bookx product uris are not rewritten, but other product type are... easy fix and guiding to that file should help out. :)
:frusty: :frusty: :frusty: :frusty: :frusty: :frusty:
Well, one of those days....what can I say.
I even wrote what to do 2 years ago :laugh:
https://github.com/mesnitu/Ceon-Book...xtra_datafiles
This as to be Karma!
Any pointers for running the Ceon URI Mapping on a localhost installation? I've got an XAMPP installation on my computer and normally access my test installations as http[s]://localhost/store_name.
When I've got a store that uses the URI mappings, any mapping generated discards the store_name portion of the link resulting in 404's. I'm expecting that the generated links should be localhost/store_name/the_link, but they're coming out as simply localhost/the_link.
How is you're HTTP_HOST and/or DIR_WS_CATALOG defined?
How/where is the .htaccess that was recommended by the install and is there one in the sub-directory (if so please provide contents of both omitting/obscuring the admin directory RewriteCond for it and the comment above it.)
Thanks for the prompt response, @mc12345678. The information you requested:
HTTP_SERVER is http://localhost
DIR_WS_CATALOG is /store_name/
.htaccess (located in the root of the /store_name directory):
Code:## 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 admin directory
RewriteCond %{REQUEST_URI} !^/admin [NC]
# Don't rewrite editors directory
RewriteCond %{REQUEST_URI} !^/editors/ [NC]
# Don't rewrite logs directory
RewriteCond %{REQUEST_URI} !^/logs/ [NC]
# Don't rewrite sitemap directory
RewriteCond %{REQUEST_URI} !^/sitemap/ [NC]
# Don't rewrite cgi-bin directory
RewriteCond %{REQUEST_URI} !^/cgi\-bin/ [NC]
# Handle all other URIs using Zen Cart (its index.php)
RewriteRule .* index.php [QSA,L]
## END CEON URI MAPPING REWRITE RULE
What's the plan for any uris generated in the local environment related to an online site? Ie. Will that site have the same sub-folder structure, will it be another directory name, or is neither of that a factor?Ask because can possibly provide a local "only" solution or one that supports moving this htaccess elsewhere. Mind you, the instructions recommend that the htaccess be placed in the root of the domain (paraphrasing) such that it would have been expected to be at localhost not localhost/store_name from the web-facing address.
I'm not totally sure what you're asking. My expectation is that any URIs generated are relative to the site's current installation.Quote:
Originally Posted by mc12345678
That is if the ceon-generated URI is microsoft-intellimouse-pro, my expectation is that the localhost'd version would be http://localhost/store_name/microsoft-intellimouse-pro while the webhosted version would be http://www.store_name.com/microsoft-intellimouse-pro (since the site's hosted version is in the root of the hosted account).
I have this working by setting up my install folder as an apache2 virtual host, then putting the CEON mappings directly in the conf file of /etc/apache2/vhosts.d folder.
So rather than accessing it as http://localhost/myinstall I access it as http://myinstall
Not sure what pointers you need but I have my local dev copies of ZC running on a windows pc (uniformserver), this is the way I've done it and apologies in advance if I'm teaching you to suck eggs:Quote:
Originally Posted by lat9
by editing the windows etc/hosts file I access the dev site just by using example.com - no localhost to worry about and this means my URI's are the same as my live site. Of course this means I can't access the live site on this PC without changing the hosts file, which is fine as I have another PC for live site access.
my CEON htaccess (root) content is the same as yours.
my includes/configure.php is
Code:define('HTTP_SERVER', 'https://example.com');
define('HTTPS_SERVER', 'https://example.com');
define('DIR_WS_CATALOG', '/');
define('DIR_WS_HTTPS_CATALOG', '/');
define('DIR_FS_CATALOG', 'C:/server/UniserverZ/www/example.com/');
Hope this helps.
Thanks for that @paul3648, I'd tried that a couple of years ago but had issues. I'll give it another shot.Quote:
Originally Posted by paul3648
If I had a single test-site, that would work; unfortunately, I've got a bunch of them.Quote:
Originally Posted by simon1066
The other that I have seen to work is to modify the HTTP_SERVER to include the sub-directory (to support transitioning the rewrites from local host to live) and then regarding the .htaccess, since the destination site will not have the store in the same sub-directory, an .htaccess file could be written now that when transferred would still apply to the live site.Quote:
Originally Posted by lat9
So in light of not providing some internal "server/host name" would suggest:
and then in the .htaccess (located in the store_name sub-folder) after RewriteEngine on:Code:define('HTTP_SERVER', 'http://localhost/store_name');
define('HTTPS_SERVER', 'https://localhost/store_name');
define('DIR_WS_CATALOG', '/');
define('DIR_WS_HTTPS_CATALOG', '/');
This should allow and support that the URIs generated in the database will be based off of the HTTP_SERVER/HTTPS_SERVER content (happens to include a sub-folder) and that the htaccess will redirect to the sub-folder in which it currently resides.Code:RewriteEngine on
RewriteCond %{ENV:URI} ^$
RewriteRule ^(.*)$ - [ENV=URI:$1]
RewriteCond %{ENV:BASE} ^$
RewriteCond %{ENV:URI}::%{REQUEST_URI} ^(.*)::(.*?)\1$
RewriteRule ^ - [ENV=BASE:%2]
# All of the RewriteCond's from Ceon URI rewriter with the below modified RewriteRule
# Don't rewrite any URIs ending with a file extension (ending with .[xxxxx])
# ETC....
RewriteRule ^(.*)$ %{ENV:BASE}index.php [L,QSA]
Credit for the additional content or direction of the .htaccess file modification goes to at least Jon Lin on stackoverflow.
although:
May need to be added to the right side of each of the RewriteCond statements since they specifically identify a folder to exclude rather than testing the filesystem to identify that the provided link is to an existing file or not.Code:%{ENV:BASE}
Thanks, @mc12345678; I'll give that a try and report back.
... and reporting back, I am.Quote:
Originally Posted by lat9
With a combination of @mc12345678's comments (prodding my memory), what I did was two-fold:
Updated the configure.php's to contain:
HTTP_SERVER = http://localhost/store_name
HTTPS_SERVER = https://localhost/store_name
DIR_WS_CATALOG = /
The change to the .htaccess file was much simpler, I simply added
RewriteBase /store_name/
just after the RewriteEngine On and before the start of the Ceon URI rules. I'm doing a happy-dance; thanks again, @mc12345678!:clap:
Welcome and that was going to be my suggestion if the local and destination site were to be in the same sub-directory so that it would be consistent (no "update" comment/notes needed)... :) but glad that that issue is addressed, don't party all night! :)
Unfortunately, that was necessary but not sufficient. The redirects are now being pushed to /localhost/store_name/uri but something's still not right.:(
I can get the category links to work, but not the product-specific ones. I'll report back (yet again) when I've figured out what the heck is going on.
Assuming that before clicking on a link to a product that looking at the link generated/to be followed? Or just seeing that after clicking the desired result is not obtained?Quote:
Originally Posted by lat9
i have the latest zen cart and no other modules.
i copied the .htaccess from the output of the installation check, and got
"The requested URL /furniture/folding-butterfly-sakura-bamboo-handheld-vintage-fan-for-beach-s was not found on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request."
same results if i added the slash, i.e. RewriteRule .* /index.php [QSA,L]
the URL comes from clicking the item on my home page https://www.bamboyant.life/
i got most of the files from torvista/CEON-URI-Mapping https://github.com/torvista/CEON-URI-Mapping (for php 7), except for the few files from the latest ceon uri mapping.
Yes. As a virtual host. As recommended to me by Conor RIP. I have been using this setup for years.Quote:
Any pointers for running the Ceon URI Mapping on a localhost installation?
Set up the site to use an url such as
www.mysite.local
NOT 127.0.0.1/whatever nor localhost/whatever.
The use of those two local domains will cause you issues with sll certificates down the road as browsers tighten up access to those addresses.
Here are the steps required.
Make sure a step works before proceeding further or it's a world of pain.
1) This requires the entry in the hosts file:
127.0.0.1 www.mysite.local
Check this works with a static site.
2) Add the corresponding code in the apache config \apache\conf\extra\httpd-vhosts.conf
This is mine with names changed to protect the innocent.
<VirtualHost *:80>
ServerName www.mysite.local
ServerAlias www.mysite.local
DocumentRoot "D:/Documents/PATH TO SITE/public_html"
ErrorLog "logs/vhosts-error.log"
<Directory "D:/Documents/PATH TO SITE/public_html">
AllowOverride All
Require all granted
</Directory>
</VirtualHost>
<VirtualHost *:443>
ServerName www.mysite.local
ServerAlias www.mysite.local
SSLEngine on
SSLCertificateFile conf/ssl.crt/server.crt
SSLCertificateKeyFile conf/ssl.key/server.key
DocumentRoot "D:/Documents/PATH TO SITE/public_html"
ErrorLog "logs/vhosts-error.log"
<Directory "D:/Documents/PATH TO SITE/public_html">
AllowOverride All
Require all granted
</Directory>
</VirtualHost>
#the paths to the certificate may not be as your server...Google is your friend.
Check this works for both http and https on a static site.
3) Local Shop
Change the configs to suit. Check it all works without URI Mapping enabled.
I remember a couple of occasions when it just would not work. Eventually I did a new install using the virtual host url https://www.mysite.local just to get examples of working configs.
4) Set up the URI mapping as usual.
Yep, the link visually looked correct, e.g. localhost/store_name/the_page_link. Here's a dump of the $_SERVER variables on entry:Quote:
Originally Posted by mc12345678
What's happening is that the_page_link, when clicked always returns to the main-page (i.e. without parameters, so no category or product listings).Code:'SERVER_NAME' => 'localhost',
'SERVER_ADDR' => '::1',
'SERVER_PORT' => '80',
'REMOTE_ADDR' => '::1',
'DOCUMENT_ROOT' => 'C:/xampp/htdocs',
'REQUEST_SCHEME' => 'http',
'CONTEXT_PREFIX' => '',
'CONTEXT_DOCUMENT_ROOT' => 'C:/xampp/htdocs',
'SERVER_ADMIN' => 'postmaster@localhost',
'SCRIPT_FILENAME' => 'C:/xampp/htdocs/store_name/index.php',
'REMOTE_PORT' => '56161',
'REDIRECT_URL' => '/store_name/the-page-link',
'GATEWAY_INTERFACE' => 'CGI/1.1',
'SERVER_PROTOCOL' => 'HTTP/1.1',
'REQUEST_METHOD' => 'GET',
'QUERY_STRING' => '',
'REQUEST_URI' => '/store_name/the_page_link',
'SCRIPT_NAME' => '/store_name/index.php',
'PHP_SELF' => '/store_name/index.php',
I'll give that a try, Steve. My hesitancy is that I've got a bunch of test sites locally and don't want to get them (and myself) confused.Quote:
Originally Posted by torvista
I usually create a virtual host for every test / backup site I'm working on.
I don't need no fancy Apache configuration, so it just a matter of copy / paste and add those entries in the hosts file.
I've tried recently to use the vagrant way, using the puphpet config, because it makes more sense when it comes to work in different places and machines, but, all I did was waste a couple of days, and failed miserably! Something related with vbguest plugin and the SMB share. But, on a Mac or Linux perhaps it's easier, and brings a lot of advantages.
Woo-hoo! Thanks a bunch, Steve.Quote:
Originally Posted by lat9
I take it that worked then?!Quote:
Woo-hoo! Thanks a bunch, Steve.
A further plus of the virtual host approach is taking it to the next step of allowing outside access to your local dev Xampp install via a dynamic dns.
Obviously it goes without saying about the security risk and the steps you need to take to mitigate this, and only do it when you need to and not all the time.
But why do such a thing?
Well for mobile testing so you don't have to root the phone to modify the hosts file, and you can also call anyone you like and ask them to check it out and you can fiddle with it there and then, locally.
And also you can use a browser testing site to do mass tests.
And if you are testing a connector with some other application that needs real internet access.
You're correct, I'm up and running (sorry for being obtuse). The test site in question really needed to have the Ceon URI Mappings work, since the hosted site doesn't have space to contain a duplicate/test site.Quote:
Originally Posted by torvista
Sorry if this was discussed already but the search did not return anything.
What is the best solution for having multilingual url's appear as a subdirectory (for ex yourstore.com/fr/abc-item) in conjunctuion with CEON mod?
Bring Up My Post
Quote:
Originally Posted by ShopVille
I have no idea.Quote:
What is the best solution for having multilingual url's appear as a subdirectory (for ex yourstore.com/fr/abc-item)
Hi,
I have a fresh install of 1.5.5f and PHP7. I have a database that was working fine with 1.5.1, and currently I can get everything to jive, accept when I go to Catalog, then Category/Products, select a product, it shows the top of the page down to the populated Product Name field, but fails to finish displaying the rest of the page, showing "TEXT_PRODUCTS_MERKMALE" and that's it.
Has anyone seen this before? It must be in one of the ceon pages but I can't find it. All other pages in /admin, plus the actual site are groovy, it's just page product.php so far.
Thanks,
Eric
Exactly which php7?
TEXT_PRODUCTS_MERKMALE is not a CEON constant. If the page is dying when it can't find that, that is a pointer to the location of the problem or at least where it first goes pear-shaped.
Check your log files to see what's going on.
MERKMALE as Torvista states is definitely not Ceon URI related, I just searched the module fileset, nada.
Thanks guys. This is driving me nuts. Everything else works, with the exception of the product page under admin. It gets down to "Products Name:", displays it in the field to the right, and after that it's a dead page.
When my older mac would attempt to load the product, it would pause at this point of the page render to think about the balance of the page.
Do we know what pages get injected into products.php? BTW TEXT_PRODUCTS_MERKMALE is a value in /includes/languages/english/product.php.
A screenshot may help, and surely there are debug logs to go with this?
Also, list your other modules, TEXT_PRODUCTS_MERKMALE is not part of the default code. And the logs will tell you what is throwing an error. I do not believe the issue is related to this module and once you have looked at the log file you might be able to identify what add-on code has created the break.
I too am having a problem with this. When editing an existing product or entering a new product the page doesn't load fully and reads "TEXT_PRODUCTS_MERKMALE"
"MERKMALE" is located in ADMIN/includes/modules/product/collect_info.php
If I replace the supplied ceon uri mapping collect_info.php with the original collect_info.php the page loads fine again.
This is what is recorded in the error log:Quote:
PHP Fatal error: Uncaught Error: Call to undefined function zen_get_products_merkmale() in C:\xampp\htdocs\zencart155f\ADMIN\includes\modules\product\collect_info.php:329
Stack trace:
#0 C:\xampp\htdocs\zencart155f\ADMIN\product.php(137): require()
#1 {main} thrown in C:\xampp\htdocs\zencart155f\ADMIN\includes\modules\product\collect_info.php on line 329
That is an indication that a function is missing from the load sequence in the admin and as previously stated is not directly a Ceon URI Mapping issue. It is something that presents itself while trying to access the admin product page.Quote:
Originally Posted by Mystery??
There is a leftover of unsuitable code in YOURADMIN/includes/modules/product/collect_info.php
This version was previously written for the German Zen Cart version and I forgot to remove this:
around line 324
Remove this code and everything will be fine. Sorry for the inconvenience, just submitted a new version with this change to the download section.Code:<?php
for ($i=0, $n=sizeof($languages); $i<$n; $i++) {
?>
<tr>
<td class="main"><?php if ($i == 0) echo TEXT_PRODUCTS_MERKMALE; ?></td>
<td class="main"><?php echo zen_image(DIR_WS_CATALOG_LANGUAGES . $languages[$i]['directory'] . '/images/' . $languages[$i]['image'], $languages[$i]['name']) . ' ' . zen_draw_input_field('products_merkmale[' . $languages[$i]['id'] . ']', (isset($products_merkmale[$languages[$i]['id']]) ? htmlspecialchars(stripslashes($products_merkmale[$languages[$i]['id']]), ENT_COMPAT, CHARSET, TRUE) : htmlspecialchars(zen_get_products_merkmale($pInfo->products_id, $languages[$i]['id']), ENT_COMPAT, CHARSET, TRUE)), zen_set_field_length(TABLE_PRODUCTS_DESCRIPTION, 'products_merkmale')); ?></td>
</tr>
<?php
}
?>
The corrected file is attached as well.
Yes! That fixes it. Thanks very much webchills! I thought Merkmale was German. I even changed all the instances of 'merkmale' to 'categories' but it obviously didn't work.
I have installed Ceon URI Mapping ver 4.5.3 in ZC ver 1.5.5f over PHP 7.0
In admin EZpages, entering a new or updating a page there are defined variables TEXT_ALT_PAGE_KEY and TEXT_ALT_PAGE_KEY_EXPLAIN. However I cannot find the define statements for these (I have checked earlier versions of URI Mapping and also ZC and they do not show in ezpages.php). The code is in MODIFIED CORE FILES/admin/ezpages.php from line 480:
Any ideas what this is please?Code:<td class="main" valign="top"><?php echo TEXT_ALT_PAGE_KEY; ?></td>
<td class="main" valign="top"><?php echo zen_draw_input_field('page_key', $ezInfo->page_key, 'size="100"');
echo '<br />' . TEXT_ALT_PAGE_KEY_EXPLAIN;
?></td>
</tr>
<?php // BEGIN CEON URI MAPPING 4 of 4
echo $ceon_uri_mapping_admin->buildEZPageURIMappingFields();
// END CEON URI MAPPING 4 of 4 ?>
Based on that review, it would appear that the other "code" is additional left-over code from some other installation that has been merged into the fileset provided to the Zen Cart site. Note that the files historically only include the additional content needed to implement the plugin as seen in the start/end comments. Anything outside of those comments that is different is generally not related to the plugin(s) originally issued by the late Conor Kerr of Ceon. Also note that there appears to be two sets of the 4.5.3 version which is different between the two. Torvista has/had been maintaining files that are now different than what webchills has uploaded.Quote:
Originally Posted by cheddars
Yes this was in the latest update from webchills. The last update from Torvista is on Github and does not include any changes to ezpages.php.
I shall comment out the spurious lines for the time-being.
Many thanks for your help mc12345678
Just delete the following as it is not needed:
It is coming from the German Zen Cart version which is in many ways different from the american version and I forgot to remove this section when porting the original German version over. This should be the last leftover code, the other one is in collect_info.php as described few posts above. All sections which are added or modified for CEON URI Mapping are always clearly commented.Code:<tr>
<td colspan="2"><?php echo zen_draw_separator('pixel_trans.gif', '1', '10'); ?></td>
</tr>
<tr>
<td class="main" valign="top"><?php echo TEXT_ALT_PAGE_KEY; ?></td>
<td class="main" valign="top"><?php echo zen_draw_input_field('page_key', $ezInfo->page_key, 'size="100"');
echo '<br />' . TEXT_ALT_PAGE_KEY_EXPLAIN;
?></td>
</tr>
It does include changes, but the latest fileset needing changes in it appears to only have been ZC 1.5.5b (it appears that other changes to ZC since then have not affected the files applicable to operation of this plugin.) the associated modified admin files as at one time updated by Torvista to apply to at least ZC 1.5.5b can be seen here: https://github.com/torvista/CEON-URI...5b/ADMIN_YOURSQuote:
Originally Posted by cheddars
I installed CEON URI Mapping 4.5.4 for Zen Cart 1.5.5 in a fresh test installation of 1.5.5f.
I ran the sql update successfully and verified the tables have been created.
I renamed my admin folders to zcadmin in both MODIFIED CORE FILES and NEW FILES and allowed overwrites where prompted.
I followed Step 4:
4)
Log in to Zen Cart Administration and click on any menu item.
You should now have the new menu item CEON URI Mapping (SEO) Configuration under Modules.
Click on it, you should see success messages that the module has been successfully installed
However, when I click on the new menu item, I get a 'Page Isn't Working' error.
I even uploaded the files again just to be sure nothing happened while transferring the first time.
Any thoughts?
See attached screenshots.
Thanks.
Attachment 17918Attachment 17919Attachment 17920
I checked my error logs and found this:
[16-Jun-2018 11:07:29 America/Chicago] PHP Parse error: syntax error, unexpected '?' in /admin/includes/classes/class.CeonURIMappingInstallOrUpgrade.php on line 463
I have no idea what to do.
PHP Code:461 $fallback_defines = array(
462 'product_reviews' =>
463 $default_uri_parts[$default_language_code]['product_reviews'] ?? $default_uri_parts['en']['product_reviews'] ?? 'Reviews',
464 'product_reviews_info' =>
465 $default_uri_parts[$default_language_code]['product_reviews_info'] ?? $default_uri_parts['en']['product_reviews_info'] ?? 'Review',
466 'product_reviews_write' =>
467 $default_uri_parts[$default_language_code]['product_reviews_write'] ?? $default_uri_parts['en']['product_reviews_write'] ?? 'Write a Review'
Change this section to:Quote:
Originally Posted by kavlito
Code:$fallback_defines = array(
'product_reviews' =>
isset($default_uri_parts[$default_language_code]['product_reviews']) ?
$default_uri_parts[$default_language_code]['product_reviews'] :
isset($default_uri_parts['en']['product_reviews']) ?
$default_uri_parts['en']['product_reviews'] : 'Reviews',
'product_reviews_info' =>
isset($default_uri_parts[$default_language_code]['product_reviews_info']) ?
$default_uri_parts[$default_language_code]['product_reviews_info'] :
isset($default_uri_parts['en']['product_reviews_info']) ?
$default_uri_parts['en']['product_reviews_info'] : 'Review',
'product_reviews_write' =>
isset($default_uri_parts[$default_language_code]['product_reviews_write']) ?
$default_uri_parts[$default_language_code]['product_reviews_write'] :
isset($default_uri_parts['en']['product_reviews_write']) ?
$default_uri_parts['en']['product_reviews_write'] : 'Write a Review'
);
Hi there,
We've been using ZC 1.51 with Ceon URI Mapping 4.4.1 for several years, has worked perfectly for us. We wanted to add a new category with new products and decided to "recycle" an existing category on our site that is no longer needed. So we just re-named the old category with the new category name - and then followed suit with product names in that category. We've actually done this before with no issues.
This time however, looks like the old, original URL's (before being recycled) have memory - so even though we update to a new URL for a new product, there are appended characters like "?cpath=100" at the end of the new URL. Since there's no reason for this to be there, looks like the URL is retaining something from its past even after being recycled.
We ended up deleting the new products and the new category created - and just build the new category and products fresh without recycling. But now, it won't give us the new category name we originally wanted - even though that category and products were deleted. An error message states the category already exists and there's a mapping conflict - despite category and products already deleted.
After going through sections of this thread and no clear solution, decided to try finding the category name in the database, to delete, so we can use it and just add the new category and new products, but the category name is nowhere to be found in the Ceon URI section of the db. In fact, the db doesn't show any recent activity of URLs being created.
Would be grateful if anyone has a solution to this problem, many thanks!
Hi there,
We've been using ZC 1.51 with Ceon URI Mapping 4.4.1 for several years, has worked perfectly for us. We wanted to add a new category with new products and decided to "recycle" an existing category on our site that is no longer needed. So we just re-named the old category with the new category name - and then followed suit with product names in that category. We've actually done this before and worked fine.
This time however, looks like the old, original URLs (before being recycled) have memory - so even though we update to a new URL for a new product, there are appended characters like "?cpath=100" at the end of the new URL. Since there's no reason for this to be there, looks like the URL is retaining something from its past even after being recycled.
We ended up deleting the new products and the new category created - and just build the new category and products fresh without recycling. But now, it won't give us the new category name we originally wanted - even though that category and products were deleted. An error message states the category already exists and there's a mapping conflict - despite category and products already deleted.
After going through sections of this thread and no clear solution, decided to try finding the category name in the database, to delete, so we can use it and just add the new category and new products, but the category name is nowhere to be found in the Ceon URI section of the db. In fact, the db doesn't show any recent activity of URLs being created.
Would be grateful if anyone has a solution to this problem, many thanks!
The links are stored in the table DB_PREFIX. ceon_uri_mappings. Searching the uri field should identify the presence of the existing mappings.
As to the issue seen, yes, there is such a "memory" it is one of the strengths of this uri mapping. There is no need to populate an htaccess file with redirects to the items in the store as the software makes every previously existing link one hop to the current and all current links are directly used. The presence of the cPath information which is discussed in the instruction indicates that the product is located outside of its master category and is appended to maintain the canonical link.
Generally speaking a link should point to one location and one location only, which is why the "conflict" is being seen when trying to again add a "new" category/product with the same name as has been stored in the database. A site that has been in operation with that link for a period of time would want users to be able to get to that location again (rather than receiving a broken link notification). However, in this situation where it has been generated but not really existed for long, there is less of an issue as it is less likely to have been indexed or otherwise stored "yet".
mc12345678, I truly appreciate your expertise and the helpful information you've provided. I've been looking for the table DB_PREFIX ceon_uri_mappings - I'm assuming this should be located in the database? Many thanks again!Quote:
Originally Posted by mc12345678
DB_PREFIX is a constant that is assigned in both the includes/configure.php and YOUR_ADMIN/includes/configure.php. It should be the same in both files.Quote:
Originally Posted by luckystu
Whatever the value is ('bob_', 'cart_', 'green_', or even ''), should be prepended to ceon_uri_mappings ('bob_ceon_uri_mappings', 'cart_ceon_uri_mappings', 'green_ceon_uri_mappings', or 'ceon_uri_mappings') to identify the database table that should contain the uris in question.
Our problem remains unsolved, was able to find the proper table in the database and deleted all URLs containing the category name we want to use again. Even took it a step further and deleted the original, previous URLs that we "recycled." After deleting, we attempted to start fresh and create the URL we want to use (again) but it continues to give an error message indicating a mapping conflict. Went over everything with a fine tooth comb and deleted each value necessary. Is there a time factor involved, meaning does it take a certain amount of time for deletions to clear out of the system? I assume they take effect immediately. Is there a location other than the database where the URLs in question are existing? Many thanks for any advice you have!Quote:
Originally Posted by mc12345678
No, there is no timer involved. When the software is trying to create a new uri for a product it attempts to verify it's existence first. If it exists there is a conflict and that means that the occurrences have not been deleted. Don't forget about the "additional" uris such as those about reviews, etc...Quote:
Originally Posted by luckystu
A query to identify duplicate results would include a search of the uri field using the LIKE option, percent symbols at the front and back of the search term and the resulting term for the product. So the query for a product that was referenced as 'blue hat' in the original name my be found with the following query:
Now this query will return every row that has the word blue in it, which could include a category name, manufacturer, etc... the records also would include those that are current and not, but the goal is to narrow down the query to be able to delete just the ones that are causing the mapping clash.Code:SELECT uri FROM ceon_uri_mappings WHERE uri like '%blue%';
Thanks, mc, ran the query and looked for the results in the database but they're not there so I assume we're not looking in the right place - where would the results be located? Many thanks.Quote:
Originally Posted by mc12345678
I've obviously not doing something right in trying to help. So let's take this one step at a time with known information.Quote:
Originally Posted by luckystu
First of all to answer the above question, running the query in tools->install sql patches will not display the results for security reasons. The query needs to be executed in a tool such as phpmyadmin in the cPanel of your site. There are other similar tools.
So, to be sure to offer a query that is likely to target just the desired product uri, please identify the vaUe of DB_PREFIX identified in YOUR_ADMIN/includes/configure.php where YOUR_ADMIN is the renamed admin directory used to access the admin side.
Then what is the product uri that is being attempted and rejected as being a duplicate. Include the -, _ or other separator that is used when generating uris.
We ran the query from phpmyadmin and it says it was successful, however we still can't find the results. Talked with our hosting tech support and they said the results should display right after the query is run but they do not. We used your code from above, mc, inserting the proper DB_PREFIX identified in both configure.php files. So as a hypothetical example, if we want to use "flowers" as a category name, which had been previously created and then deleted but is still not being "released" due to a mapping conflict, this is the query executed:Quote:
Originally Posted by mc12345678
SELECT uri FROM (our DB_PREFIX)_ceon_uri_mappings WHERE uri like '%flowers%';
Is this correct and where would the query results be located? Sorry this is taking much longer than expected, really appreciate your help!
If you have accessed phpmyadmin, on the left side have selected not only the database associated with this site, but also the table (DB_PREFIX)ceon_uri_mappings and then on the right side selected the button/option along the top to run a sql query and entered into the query (let's assume the prefix is 'fun'):Quote:
Originally Posted by luckystu
and then executed the query.Code:SELECT uri FROM funceon_uri_mappings WHERE uri LIKE '%flowers%';
Then I too would expect the results to be provided below the representation of the query. Those results may be a statement of 0 results returned (or something similar) or 1 or more results in a column with the heading of the column being uri and each row showing the full content of the field returned.
If, in this case, the database being viewed is the active database that is reporting the attempt to duplicate mapping, then there should be at least one result that comes back.
Note the minor difference in how I represented the DB_PREFIX being used compared to how it was previously represented. ((DB_PREFIX)ceon_uri_mappings as compared to (DB_PREFIX)_ceon_uri_mappings) While this may not seem to make a difference between you and me, it is important for others that may try to follow this. ZC does not add the underscore between the prefix and the table name. If one is to use a prefix, adding the underscore (_) at the end makes it easier for other database manipulations at some point in the future, but there is no requirement for there to be one. Nor is there a requirement to have/use a value in the DB_PREFIX.
Hi mc, cannot thank you enough for your help and patience, our problem is resolved! Followed your last instructions - of note, upon arriving at the SQL query window, a select command was already there and formatted, so I simply customized it to fit what we were looking for. The query produced multiple results, we deleted possible conflicting values, which finally released the category name we originally wanted to use.Quote:
Originally Posted by mc12345678
May I just say, having the chance to look around the Ceon uri mapping structure at its core, I have a greater appreciation for the function of this program. Hope you'll enjoy a few cups of coffee on us and truly many thanks!
I've installed the latest version of CEON SEO URL's and when I go to the installation check page through the admin it goes to a blank white page. I am running Zen Cart 1.5.5f
Also my domain name is not live, its under the server IP temp url
Any ideas?
What php version is being used?Quote:
Originally Posted by Nick1973
What mydebug log information is available? (please obscure the admin directory name if/when posting here, and press the # button in the toolbar to capture the content in [CODE][/CODE] tags.
PHP 5.6. I'm aware that Zen Cart is supposed to now wok up to 7.1 but when I tried upgrading PHP it broke the site and the homepage wouldn't load. All I got was a 404 error. So I downgraded it back to 5.6
This is the error in the debug files.
Code:PHP Parse error: syntax error, unexpected '?' in /home/MYWEBSITEDIRECTORY/public_html/MYADMIN/includes/classes/class.CeonURIMappingInstallationCheck.php on line 2173
Just following up on my post above. I've just noticed that it appears that the homepage not loading and producing a 404 appears to be when SEO URL's is installed and nothing to do with PHP 5.6 or 7.1
This is what I found in the debug files. I have three duplicate sites with exactly the same template set, the only difference is that CEON SEO URL's is not installed and they are the same colour with different content.
Code:[04-Sep-2018 16:53:54 UTC] Request URI: /~MYWEBSITEDIRECTORY/, IP address: 00.00.00.000
#1 preg_match() called at [/home/MYWEBSITEDIRECTORY/public_html/includes/functions/functions_general.php:1031]
#2 zen_back_link() called at [/home/MYWEBSITEDIRECTORY/public_html/includes/templates/template_default/templates/tpl_page_not_found_default.php:54]
#3 require(/home/MYWEBSITEDIRECTORY/public_html/includes/templates/template_default/templates/tpl_page_not_found_default.php) called at [/home/MYWEBSITEDIRECTORY/public_html/includes/templates/venturezen/common/tpl_main_page.php:179]
#4 require(/home/MYWEBSITEDIRECTORY/public_html/includes/templates/venturezen/common/tpl_main_page.php) called at [/home/vgd/public_html/index.php:97]
[04-Sep-2018 16:53:54 UTC] PHP Warning: preg_match(): Unknown modifier 'v' in /home/MYWEBSITEDIRECTORY/public_html/includes/functions/functions_general.php on line 1031
what's on /includes/functions/functions_general.php on line 1031?
I have a couple of issues.
1) When I edit a product and/or add a product I got half of the page.
2) All my links didn't change even the module is in Enable.
Ok, I am getting this error:
Code:[04-Sep-2018 17:27:34 America/Chicago] PHP Fatal error: Uncaught Error: Call to undefined function zen_get_products_merkmale() in /home1/xxxxxx/public_html/galaxyhomedecor.com/manager/includes/modules/product/collect_info.php:329
Stack trace:
#0 /home1/xxxxxx/public_html/galaxyhomedecor.com/manager/product.php(137): require()
#1 {main}
thrown in /home1/xxxxxx/public_html/galaxyhomedecor.com/manager/includes/modules/product/collect_info.php on line 329
Now I got it working, but now when I mouse over my subcategories on the main store I don't see my products. I get Error: 404 Page Not Found.Quote:
Originally Posted by wmorris
1031 to 1038Quote:
Originally Posted by lankeeyankee
Code:if (isset($_SERVER['HTTP_REFERER']) && preg_match("~^".HTTP_SERVER."~i", $_SERVER['HTTP_REFERER']) ) {
//if (isset($_SERVER['HTTP_REFERER']) && strstr($_SERVER['HTTP_REFERER'], str_replace(array('http://', 'https://'), '', HTTP_SERVER) ) ) {
$link= $_SERVER['HTTP_REFERER'];
} else {
$link = zen_href_link(FILENAME_DEFAULT);
}
$_SESSION['navigation'] = new navigationHistory;
}
One reason to get a 404 error relates to the either newly added or otherwise modified .htaccess file. ZC does not ship (because it does not need) with an htaccess file in the root of the store. This plugin (like other URI Rewriters that have been seen to work properly) requires a properly formatted/sequenced htaccess file. As has been done times before, the entire .htaccess file may need to be provided (though please obscure the admin directory name as it is provided in the template generated by the plugin.)Quote:
Originally Posted by wmorris
Also besides reviewing the instructions about the file and 404 issues, it is important to understand how this store is incorporated into the server with consideration of other stores on the server and any htaccess files in the directories above (before) the current store's root.
Now, all that said, you mentioned that there is a 404 issue when hovering over the images, does that mean you have been able to navigate the site with the rewritten uris, but only the images have an issue?
Is this store hosted on a Windows machine? Does the HTTP_SERVER value found in includes/configure.php use a backslash (\) instead of a forwards slash (/) to identify a sub-directory for the store?Quote:
Originally Posted by Nick1973
It's on a Linux Server however the domain name is not live and uses something like http://00.00.00.000/~MYWEBSITE to get to itQuote:
Originally Posted by mc12345678
And somewhere in ~MYWEBSITE is there a v? Possibly just after the tilde?Quote:
Originally Posted by Nick1973
No there isn'tQuote:
Originally Posted by mc12345678
Because of the use of the tilde in the HTTP_SERVER string, recommend modifying:Quote:
Originally Posted by Nick1973
To:Code:if (isset($_SERVER['HTTP_REFERER']) && preg_match("~^".HTTP_SERVER."~i", $_SERVER['HTTP_REFERER']) ) { //if (isset($_SERVER['HTTP_REFERER']) && strstr($_SERVER['HTTP_REFERER'], str_replace(array('http://', 'https://'), '', HTTP_SERVER) ) ) { $link= $_SERVER['HTTP_REFERER']; } else { $link = zen_href_link(FILENAME_DEFAULT); } $_SESSION['navigation'] = new navigationHistory; }
I don't see any other instance on the catalog side where this style of preg_match is used against that specific string. I didn't look on the admin side. Note, that based on the error log that the page to be loaded was a page not found page. Why that particular direction was chosen I do not know based on what has been provided or what has been performed to generate URIs, but the above would prevent running into a clash. An alternative to adding in the preg_quote function is to modify the two uses of the tilde to say a non-uri like character, perhaps a semi-colon (;) or some other "odd" character.Code:if (isset($_SERVER['HTTP_REFERER']) && preg_match("~^".preg_quote(HTTP_SERVER, "~")."~i", $_SERVER['HTTP_REFERER']) ) { //if (isset($_SERVER['HTTP_REFERER']) && strstr($_SERVER['HTTP_REFERER'], str_replace(array('http://', 'https://'), '', HTTP_SERVER) ) ) { $link= $_SERVER['HTTP_REFERER']; } else { $link = zen_href_link(FILENAME_DEFAULT); } $_SESSION['navigation'] = new navigationHistory; }
I neglected to also state that the specific error encountered in includes/functions/functions_general.php when trying whatever uri on the store was attempted is not directly associated with this plugin as it would have occurred regardless of being installed or not. The cause of getting a page not found error may have been a result of some aspect of its installation (possibly incomplete), incorrect use, or other some other factor, but there has not been sufficient information provided to identify why a page not found response was provided.Quote:
Originally Posted by mc12345678
Generally speaking when using Zen Cart, it is expected that the uri to the store would be a "full" uri, not one using an ip address/temp folder. There are other threads in the forum where this is discussed and it is not necessarily associated with this plugin. I encourage seeking assistance with this aspect in either an existing thread directly related to the issue or by beginning a new one. Note that while this forum contains a lot of useful information that there are many Internet search tools outside of it that may find related discussions better than the forum's search tool. The recent recommendation of others is to add Zen Cart to the end of any such search.
Quote:
Originally Posted by mc12345678
Yes totally understand what you are saying but any professional web developer WILL NOT put a url live until it is absolutely completed, and plus there is the problem of google picking up incorrect url's, especially if the site is large and each url has to be generated manually as in the free version of CEON SEO URL's. This is a situation which could in some cases take more than one day, and in which case by that time the google crawler could have then picked up the standard zen cart url. Which then poses a problem as it then means the zen url may then appear in the google search results instead of the CEON URL. That can then take weeks or even months to fix in some cases.
Most professional Web Developers these days develop locally through tools such as MAMP and run PHP and MYSQL on their local machine. Partly because it is faster and partly because of the issues outlined above. Putting a site under a live url while under development can cause endless headaches with SEO later on, which is why there is a need to develop this way. Hence the requirement for 'SOME' modules to work in those kinds of environments and/or under temp url's on a testing environment.
I already use google to do searches and add Zen Cart in that search request to find answers as you are right, there are other places where answers can be found.
Does the latest release have all the files in it for a complete installation or is there a requirement to have a previous version installed?
I tried your fix and it gave me the same issue, plus it broke the front end.Quote:
Originally Posted by Nick1973
Essentially are you saying it will work once the website is given a live URL?
I cast an eye over this thread but get dizzy with the details.
I would say that back in the day it was this mod that required me to use virtual hosts for local development work as detailed in my previous posts. No other method (alias) would work.
Long ago I updated this code for php7 and other bits, and to keep it alive posted it on Github.
I see someone has posted a "new" version in the plugins.
This I have not compared to mine so I cannot vouch for it.
I know mine works....so maybe you should compare it.
Well I have four domain names on the verge of going live which have exactly the same installations on them. I gave them a look over and have realised one of those can actually go into a live status and it wouldn't take me too long to generate the URL's on that particular domain name, which wouldn't cause too many issues. So I am going to push it live, however if the problem remains I will take it offline again then will have a look at your version.Quote:
Originally Posted by torvista
I've now pushed one of the domain names live and still the problem of a blank installation check page exists. So obviously its nothing to do with the tilde.Quote:
Originally Posted by mc12345678
So you're saying that the error generated is still:Quote:
Originally Posted by Nick1973
Code:[04-Sep-2018 16:53:54 UTC] Request URI: /~MYWEBSITEDIRECTORY/, IP address: 00.00.00.000
#1 preg_match() called at [/home/MYWEBSITEDIRECTORY/public_html/includes/functions/functions_general.php:1031]
#2 zen_back_link() called at [/home/MYWEBSITEDIRECTORY/public_html/includes/templates/template_default/templates/tpl_page_not_found_default.php:54]
#3 require(/home/MYWEBSITEDIRECTORY/public_html/includes/templates/template_default/templates/tpl_page_not_found_default.php) called at [/home/MYWEBSITEDIRECTORY/public_html/includes/templates/venturezen/common/tpl_main_page.php:179]
#4 require(/home/MYWEBSITEDIRECTORY/public_html/includes/templates/venturezen/common/tpl_main_page.php) called at [/home/vgd/public_html/index.php:97]
[04-Sep-2018 16:53:54 UTC] PHP Warning: preg_match(): Unknown modifier 'v' in /home/MYWEBSITEDIRECTORY/public_html/includes/functions/functions_general.php on line 1031
I've managed to try your version and it works!Quote:
Originally Posted by torvista
I know I had compared the two which was where I found that changes had been made that prevented operation in php versions less than 7.x and also that the work done to use the ZC 1.5.5 notifier in zen_href_link and subsequently ensure the bread-crumbs had the rewritten uri were not adopted.Quote:
Originally Posted by torvista
I have a working version sort of which is the main thing. It looks like some modifications appear to be missing though from some files that aren't included unless they are in the installation instructions, so I am going to work through the list in a moment and come back to this thread.Quote:
Originally Posted by mc12345678
Is this important? Its in 1.5.5e/includes/templates/MYTEMPLATE/html_header.phpQuote:
Originally Posted by torvista
Just it breaks my site and I get a white page when I try to load the home page.Code://steve bof CEON uri mapping
//CEON uri mapping produces a canonical link with no extra parameters: so no "?" after the url.
//To create the alternate urls for hreflang use, for all pages (apart from the home page), '&language=' is appended to the canonical url. This gets a page not found (in the Google Search Console) as the "&" needs to be a "?" as there are no other parameters.
//Since the $canonicalLink is already created, it needs to be checked for the presence of a "?". If so, ok, if not use the "?" instead of "&".
//echo '<link rel="alternate" href="' . ($this_is_home_page ? zen_href_link(FILENAME_DEFAULT, 'language=' . $key, $request_type) : $canonicalLink . '&language=' . $key) . '" hreflang="' . $key . '" />' . "\n";
echo '<link rel="alternate" href="' . ($this_is_home_page ? zen_href_link(FILENAME_DEFAULT, 'language=' . $key, $request_type) : $canonicalLink . (strpos($canonicalLink, '?') ? '&' : '?') . 'language=' . $key) . '" hreflang="' . $key . '" />' . "\n";//steve as per https://github.com/zencart/zencart/pull/1314/files
}
// EOF hreflang for multilingual sites
In what way does it break your site? Ie. what is in the error message?Quote:
Originally Posted by Nick1973
It was determined to be important in some way which is why it was added.
The error message likely was the same as identified by wmorris where (at least) the file YOUR_ADMIN/includes/classes/class.CeonURIMappingInstallationCheck.php line 2173 uses the null coalesce operator of ?? (available first in PHP 7.0) in:Quote:
Originally Posted by Nick1973
was used instead of the pre-PHP 7.0 release:Code:$path = $old_file_or_dir['file'] ?? $old_file_or_dir['dir'];
Code:$path = isset($old_file_or_dir['file']) ? $old_file_or_dir['file'] : $old_file_or_dir['dir'];
Ok I have a full working version now. It took a bit of working on but I am there with it. It came together with a mixture of the files submitted for download and the files suggested by torvistaQuote:
Originally Posted by mc12345678
I will try and pull it all together and submit an update for download.
I have just installed 4.5.5 this on my test site running 1.5.5f & if I make any changes using admin/ceon_uri_mapping_config.php I get the following error:
PHP Fatal error: 1366:Incorrect integer value: '' for column 'automatic_version_checking' at row 1 :: update ceon_uri_mapping_configs set autogen_new = '1', whitespace_replacement = '1', capitalisation = '3', remove_words = '-', char_str_replacements = '€=>EUR', mapping_clash_action = 'auto-append', manage_product_reviews_mappings = '0', manage_product_reviews_info_mappings = '0', manage_product_reviews_write_mappings = '0', automatic_version_checking = '' where id = '1'
I have checked the database & ceon_uri_mapping_configs.automatic_version_checking has a value of 1
Both of the installation checks are happy & report no errors.
Does anyone have any idea of what could be causing this or where I should look to find the issue?
Thanks for your help
Pat
It appears that there is/was an attempt to modify the automatic-version-checking option to off or not to be performed; however, it was not handled properly either in the attempt to remove the version checking option or if it was present, but the appropriate posted information did not contain an expected value.Quote:
Originally Posted by PatClay
A solution that appears acceptable is at/around line 507 of admin/includes/classes/class.CeonURIMappingConfigUtility.php to change:
To:Code:$this->_automatic_version_checking = $_POSTt'automatic-version-checking'];
By adding the casting of integer.Code:$this->_automatic_version_checking = (int)$_POSTt'automatic-version-checking'];
I would recommend this regardless of whether version checking returns or remains unavailable to ensure that only an integer value be considered for storage into the database.
Thanks for your speedy response. I found the code at line 477 & made the alteration & the error has gone away.
Just an FYI for anyone following later:
Is a typo & should beCode:$_POSTt'automatic-version-checking']
Code:$_POST['automatic-version-checking']
Well heck. I thought all was good and then not. I am running 1.5.5f. I am not using an "unused" domain, but the store is live. myfurnituretx.com
I am having a problem when updating or adding products to the store. After clicking "preview" upon updating or adding a product, I receive a blank screen (should be insert or update). When I toggle the "Offer Auto-generation of URIs for Categories, Products, Manufacturers and EZ-Pages:" to No, all is good. But when on yes, it does not work. My urls are also not changing when in selecting yes or no. I did an installation check and all checks out good. I copied and pasted the rewrite .htaccess file and loaded to the root.
htaccess file is:
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 admin directory
RewriteCond %{REQUEST_URI} !^/cr_admin [NC]
# Don't rewrite editors directory
RewriteCond %{REQUEST_URI} !^/editors/ [NC]
# Don't rewrite .well-known directory
RewriteCond %{REQUEST_URI} !^/\.well\-known/ [NC]
# Don't rewrite logs directory
RewriteCond %{REQUEST_URI} !^/logs/ [NC]
# Don't rewrite cgi-bin directory
RewriteCond %{REQUEST_URI} !^/cgi\-bin/ [NC]
# Handle all other URIs using Zen Cart (its index.php)
RewriteRule .* index.php [QSA,L]
## END CEON URI MAPPING REWRITE RULE
I did see a couple of the typos mentioned on the class.CeonURIMappingConfigUtility.php file and updated, but still no luck. I have a feeling there is something simple I am missing. Sorry, I couldn't find it in this thread.
Any help would be great!
Ok, so now that perhaps the panic has subsided... Some additional information would help:Quote:
Originally Posted by creyesx6
1. has Ceon URI Mapping been installed against the database of this site before? And if so, what was its operational status?
2. When the blank page was created, a log file should have been generated in the logs directory or if not logged there at least in the server logs (possibly requires help from the host). What did that log identify? (would suggest not posting the admin directory name although that has already been done in posting of the full .htaccess file. (Suggest renaming the admin directory.)
3. Regarding the lack of provided rewritten uris shown on the store front, has the plugin been enabled in the configuration settings?
There is no panic. This is a temporary domain that I use. My hope is to get this working if not, I will simply remove it and move on to something that works for me. However, I would like to get it working. To answer your questions.
1. There was not a pre-existing database. I added a couple of dummy products to test. No luck of course.
2. Yes a log was created, but nothing to do with the admin. Specifically: "PHP Parse error: syntax error, unexpected ':', expecting ';' or '{' in /home/[login]/public_html/includes/classes/class.StringHelper.php on line 68:
3. Yes it was enabled.
Hopefully that is enough information to find help. Regards.
It's a start. Could you please provide the content of line 68 from includes/classes/class.StringHelper.php?Quote:
Originally Posted by creyesx6
What was the source of the fileset installed and if it exists, what version?
line 68
public function setDefaultCharset($charset): void
CEON URI Mapping 4.5.5. downloaded from the plugins. I am using 1.5.5f. I think that is what you are asking for.
Thanks for your time.
I sincerely appreciate your time and for looking into this for me. However, I have decided to move on to a different option. Thanks for contributing to this free plugin. I was privileged enough to have worked with Conor before his passing and I appreciate all his great work as well.