Printable View
Because Zen Cart always adds the "cPath" to product pages. Therefore the "cPath" query parameter is left on the URL to avoid breaking any third party modules which (lazily) rely upon the presence of the "cPath" query parameter in the URL.Quote:
Originally Posted by 100asa
You may find this post of interest: Details on how settings affect product URLs.
What is your business case for needing the "cPath" query parameter removed?
If it better to remain the cpath in the url, I can left it .Quote:
Originally Posted by lhungil
I tought it was better seo remove cpath from url
Better how??? SEO is not negatively impacted by the presence of the cPath in the URL..Quote:
Originally Posted by 100asa
just what I wanted to hear. Thank you
So yeah... I was REAL careful, I'm not an idiot... followed every step. Obviously I missed something anyway because all I get are error 404 with each and every link. Where do I start?
edit: Well, almost every link. The My Account link works, but I see that's because it was never rewritten. It still says /index.php?main_page=login Others are rewritten... and don't work. They LOOK fine to me, but all are 404.
Oops. It helps to check permissions before whining that something doesn't work :)
.htacess was not writeable so on upload nothing happened.
Sorry for false alarm. Links appear to work. I'll go play now.
I do have two questions though:
1) login/my account links aren't friendly url. They are https... is that just the way it is? or can links to secure pages be re-written too?
2) links I have within my product descriptions or CMS pages are not rewritten. Is there anything I can do about that (other than going through and manually changing them to the friendly link if I feel so inclined)? Is it perhaps an absolute vs. relative issue?
Thanks.
my logs tell:
when I try to send email by recover cart sale https://www.zen-cart.com/downloads.php?do=file&id=25PHP Code:PHP Fatal error: Call to undefined function zen_get_info_page() in /var/www/vhosts/100asa.it/httpdocs/includes/classes/usu.php on line 324
Where is the issue?
If these are hardcoded links in your product descriptions or CMS pages, you will have to manually change them..Quote:
Originally Posted by s_mack
You may be interested in this post (many pages back now): Ultimate URLs 2.215: Ticket #28.Quote:
Originally Posted by 100asa
Thank you so much!!!Quote:
Originally Posted by lhungil
Have you checked the Ultimate URL configuration? In particular the "Limit alternate URLS to the following pages" option?Quote:
Originally Posted by s_mack
The variable found in "main_page=" (stock Zen Cart URLs) is the name of the Zen Cart "page".
Hi guys
I just installed Ultimate SEO Url plugin and it doesn't seem to show up on my admin panel.
Can anyone help me with this?
Thank you.
Zen Cart debug logs?Quote:
Originally Posted by Awalji
Version of Zen Cart?
Version of PHP (as shown in Zen Cart admin -> version)?
List of other modifications to Zen Cart?
Ultimate URLs version (installing)?
How did you obtain Ultimate URLs?
Upgrade from Ultimate SEO URLs?
If upgrading, what was previous version?
Configured Zen Cart admin default language?
Did you double check uploaded files (and locations) to verify?
What was the result of installation step 4c?
Hi
I've got USU 2.215 installed on zen cart 1.5.4 upgrading from zen cart 1.5.1. The live site has urls formatted this way
madonnahardcandyvinyllpcoloredvinyl-p-6588.html
On upgrade site they are being formatted this way
madonna-hard-candy-vinyl-lp-colored-vinyl-p-6588.html
The urls look nicer with the dashes but I'm concerned the dashes will pose a problem in search results if the urls are not formatted the same as on the live site. How can the dashes be removed between words?
thank you
On the live site (Zen Cart 1.5.1) which module (and version) was installed to alter URLs?Quote:
Originally Posted by buildingblocks
Just curious as Ultimate URLs (at least since version 2.200 - possibly farther back) replaces whitespace with a dash (does not strip whitespace - unless a filter was configured).
As long as your Zen Cart template correctly supports canonicals (if it was designed for Zen Cart >= 1.3.9h it should), I would not lose sleep over this. If the template does not, it should be corrected ASAP (just to be on the safe side).Quote:
Originally Posted by buildingblocks
Why? Because your product (and categories, ez-pages, etc) remain accessible from the original Zen Cart URLs, past URLs generated by Ultimate URLs, and the currently generated URL. The canonical essentially tells Search Engines "this URL and the URL listed as canonical should be treated as the same URL". More detailed information is available from Bing and Google regarding the nitty gritty of canonicals.
One can also opt to enable the "automatic redirect" feature of Ultimate URLs to force a 301 to the currently generated URL instead. However some third party modules do not play well with this option enabled under Ultimate URLs <= 2.215 (3rd party modules directly calling application_top instead of integrating as a Zen Cart page). Again more detailed information is available from Bing and Google regarding the nitty gritty of 301 redirects (including pros and cons).
If you really, really, really want to strip spaces (and more closely match the existing site)... You can! Custom string and character replacement is what the "PCRE filter" is for.Quote:
Originally Posted by buildingblocks
The following PCRE filter should remove all whitespace (space, tab, new line, carriage return, etc):
Be aware on some servers you may need to add an extra slash (if after saving the value in the configuration, the configuration does not show the first slash):Code:\s+=>
Code:\\s+=>
P.S. Don't forget to apply the known bugfixes for Zen Cart 1.5.4 and the bugfixes for Ultimate URLs 2.215 (posted earlier in this thread).
Hi. Have ZC 1.54 and Ultimate SEO 2.215 installed. Been working fine.
Just added a NEW product, which I want the OLD product URL to 301 redirect to.
However, after inserting following rules to the very end of my htaccess, the browser still directs to the OLD product page.
RewriteCond %{HTTP_HOST} ^domain\.com$ [OR]
RewriteCond %{HTTP_HOST} ^www\.domain\.com$
RewriteRule ^acct\/documents\-c\-90\/old\-product\-p\-392\.html$ "http\:\/\/www\.domain\.com\/acct\/documents\-c\-90\/new\-product\-p\-394\.html" [R=301,L]
I also tried inserting the same rules ABOVE the "Start Ultimate SEO URLs" section in htaccess, with same result.
I've reset the "Reset URL cache".
Do I have to write a rule to redirect the stock URL for the OLD product to the stock URL for the NEW product? And insert the rule ABOVE the "Start Ultimate SEO URLs" section in htaccess?
Or is my logic failing and/or such a redirect is not possible with Ultimate SEO URLs installed?
Thank you for any pointers.
On the live site the USU version is not identified. I didn't install it so can say for sure which version. The file
admin/includes/reset_seo_cache.php
is still in use and shows this credit info
/*
* Script name: admin/includes/seo_cache_reset.php
* Contribution: Ultimate SEO URLs v2.1
* Version: 2.0
* Date: 30 January 2005
* Copyright (C) 2005 Bobby Easland
* Internet moniker: Chemo
* Contact: [email protected]
* Commercial Site: g i g a b y t e - h o s t i n g . c o m
* GPL Dev Server: m e s o i m p a c t . c o m
*/
Yes, the template supports canonicals. Yes, I really, really, reeeally want to match the live site. lol. This is the one that worked for me, \\s+=>
I will go over the bug fix lists
Thanks a bunch! :)
Inserted into htaccess (in www root)Quote:
Originally Posted by Woodymon
Redirect 301 /shop/index.php?main_page=product_info&products_id=392 http://www.domain.com/shop/index.php...roducts_id=394
but it did not redirect.
And tried putting the same in the htaccess (in the shop directory) with same issue.
I figure I have to do a Rewrite Match to make a redirect workwith query strings, but I don't remember enough about regular expressions to make this happen.
Or maybe I can't do this with Ultimate SEO URLs installed?
Suggestions?
IMHO the best approach for an e-commerce website in regards to the customer experience would be to never redirect from one product to another product. I'm am however, not going to turn this support thread into a discussion on the topic. There are numerous other threads here on the Zen Cart forums and on the internet in general regarding WHY and alternative methods of handling products when they are: discontinued, no longer carried, or replaced by a newer version.Quote:
Originally Posted by Woodymon
Just a warning (not targeted to the OP specifically), one should never adjust web server directives without thorough knowledge of the directives (and the implications of using the directives). Just placing directives without understanding the directives and how the server processes the directives can result in a major headache (and potentially unanticipated downtime). To properly place and use web server directives it is imperative one know if there are any server-wide directives, vhost directives, or other directives in .htaccess files (or parent folders) and how those directives will (or will not) impact any new directives being added.
If it is absolutely necessary to redirect one product to another product there are a few different methods. The first is to rewrite the request using a mod_rewrite directive (changing the product_id), and let Ultimate URLs issue the 301 redirect. The second is to use mod_rewrite to tell Apache to issue the 301 redirect. I would recommend the first method, letting Ultimate URLs handle the 301 redirect unless there is a very compelling reason to do otherwise.
One should place any custom 301 redirects in the section of the .htaccess labeled "Add any custom 301 redirects". This is also the correct place to add any custom mod_rewrite directives such as folder exclusions (for example when a test environment is located at /test-zencart/).
The following examples assume no other modifications to the supplied .htaccess files, no .htaccess files in parent folders, and no conflicting server / vhost directives.
Method #1 (Recommended):
Method #2 (Not Recommended):Code:###############################################################################
# Add any custom 301 redirects
###############################################################################
# Notes:
#
# In general these should be few and far between. If you use a RewriteRule
# be sure to add the L flag to let Apache mod_rewrite know to stop processing
# and skip any RewriteRules defined later in the .htaccess file.
###############################################################################
# Rewrite the request internally. Will catch all requests to the old page (stock Zen Cart and Ultimate URLs).
# This option will not result in "redirect loops" (even if the product name or URL is changed in the future).
# Enable automatic redirects in the Ultimate URLs configuration to issue a 301 to the alternative URL.
RewriteCond %{QUERY_STRING} main_page=product_info
RewriteCond %{QUERY_STRING} products_id=392
RewriteRule ^(.*)$ index.php?main_page=product_info&products_id=394
All changes should be vetted in a non-production environment (testing website) before being applied to a production environment (live website).Code:###############################################################################
# Add any custom 301 redirects
###############################################################################
# Notes:
#
# In general these should be few and far between. If you use a RewriteRule
# be sure to add the L flag to let Apache mod_rewrite know to stop processing
# and skip any RewriteRules defined later in the .htaccess file.
###############################################################################
# Redirect the requests via Apache. Will require multiple entries and updating every time the URL changes.
# This option can result in "redirect loops" (especially if the product name or URL changes in the future).
# Apache issues the redirect and does not use Ultimate URLs to determine the correct alternative URL.
RewriteCond %{QUERY_STRING} main_page=product_info
RewriteCond %{QUERY_STRING} products_id=392
RewriteRule ^(.*)$ http://www.example.com/actual-url-to-the-new-product-p-394.html [R=301,L]
RewriteRule ^actual-url-to-the-old-product-p-392\.html$ http://www.example.com/actual-url-to-the-new-product-p-394.html [R=301,L]
NOTE: Without knowing the specific old and the specific new URL, no optimizations can be safely added to the second method (and one will be required to repeat the second RewriteRule for each possible alternative URL for the old product). If they were known some could possibly be applied. Not going to spend alot of time on these as using the first method is a better long term approach with Ultimate URLs.
Just for future reference (and readers) the version of older copies of Ultimate URLs downloaded from zen-cart.com can usually be identified by reviewing the file "/includes/classes/seo.url.php" and "/includes/classes/seo.install.php".Quote:
Originally Posted by buildingblocks
The header posted does not the match the one in the versions of Ultimate SEO URLs available on zen-cart.com.
Appears the version previously installed may not have been specifically for Zen Cart or downloaded from an alternative source (and may contain other modifications). You may wish to double check all URLs on the site (and check through all of the configuration settings for Ultimate URLs).Code:/*=======================================================================*\
|| #################### //-- SCRIPT INFO --// ########################## ||
|| # Script name: admin/includes/seo_cache_reset.php
|| # Contribution: Ultimate SEO URLs v2.1
|| # Version: 2.0
|| # Date: 30 January 2005
|| # ------------------------------------------------------------------ # ||
|| #################### //-- COPYRIGHT INFO --// ######################## ||
|| # Copyright (C) 2005 Bobby Easland # ||
|| # Internet moniker: Chemo # ||
|| # Contact: [email protected] # ||
|| # Commercial Site: http://gigabyte-hosting.com/ # ||
|| # GPL Dev Server: http://mesoimpact.com/ # ||
Glad it worked for you!Quote:
Originally Posted by buildingblocks
Interesting (and maybe a little amusing in retrospect), we have seen at least one server where double escaping was required (for example "\\\\s+=>"). Took way too long for us to identify the cause. Eventually saw a screen shot of the configuration page not showing the correct value and a screen shot of the PHP configuration (and groaned loudly when we noted a much older version of PHP and "magic quotes" enabled).
ok, /includes/classes/seo.url.php has thisQuote:
Just for future reference (and readers) the version of older copies of Ultimate URLs downloaded from zen-cart.com can usually be identified by reviewing the file "/includes/classes/seo.url.php" and "/includes/classes/seo.install.php".
Ultimate SEO URLs For Zen Cart, version 2.150 / JardaR
Weird, I'll have to look at the stock code for 2.150 (2.200 was a branch off 2.109). Thank You for the information!
Thank you for your very informative response and your recommendations. I've numerous redirects and rewrites in htaccess already and all are working well. Indeed, under normal circumstances I would not redirect an old product to a new product. But after reviewing the pros and cons (specific to Google policy/algorithm) as far as I understand them, in the short term it appears a redirect is the way to go. I've already disabled the old product in Zen Cart. Once I see enough external links to the new URL, I'll kill the redirect.Quote:
Originally Posted by lhungil
Thanks again for your most excellent response. I bow in appreciation.
Couldn't edit my above post.
Not sure why I was thinking redirect, when rewrite was clearly the way to go.
Implemented your recommendation #1, and works just as desired, for both the stock URL and for the SEO URL.
Thanks again for the assist!
Quote:
Originally Posted by Woodymon
Quote:
Originally Posted by Woodymon
You are welcome. Glad the provided example worked in your server environment!Quote:
Originally Posted by Woodymon
Ahh, found it (now that I have switched from my phone to my notebook). You are right, in versions prior to 2.200 if "Remove all non-alphanumeric characters?" was enabled whitespace was stripped (and the whitespace to dash code was still called, just never did anything). Of course if the filter was not enabled (default setting), whitespace was not stripped (and the whitespace was replaced with a dash).Quote:
Originally Posted by buildingblocks
Versions >= 2.200 perform detection and add support for the Unicode Character Set (not just ASCII) and do not strip whitespace when the alpha-numeric filter is enabled (letting the later code block replace whitespace with a dash). As previously noted, this results in easier to read URLs (and historically search engines treat a dash as a word boundary).
With the use of canonicals (present in modern versions of Zen Cart and Zen Cart templates), the major search engines will not penalize for the content being accessible from both the older URLs (words mashed together) and the new URLs (now containing a "-" between words). So not a big concern, but for those expecting the exact same behavior as previous versions, adding a PCRE filter will be necessary.
Thank You for catching this change, if I find some time I'll add a note to the installer or in the readme.
I have the latest version of Ultimate SEO and Zen Cart 1.5.4, but coming from my previous 2.210 I get a glitch. I am likely overlooking something, but I searched this thread and could not find it specifically mentioned. When a user is in a category and clicks on an item in that category it merely redirects them back to the category, not the product. Under 2.210 it would redirect to the product URL like yoursite.com/product-name-p-91.html. Any help would be greatly appreciated.
Please verify: all of the files were uploaded to the correct location, the new .htaccess file was installed and edited per contained instructions, all of the paths in both configure.php files are correct, and the installer was completed successfully. After verifying (easiest way is to walk through the installation again one step at a time), reset your browser cache and the Ultimate URLs cache.Quote:
Originally Posted by faithofgod
What settings do you have configured for "Admin" -> "Configuration" -> "My Store" -> "Missing Page Check"? What are the contents of both of your "configure.php" files (obscure the db password and admin folder name if present)? What is the full contents of the .htaccess file in the store root (and any .htaccess files in parent folders)? What is the URL of a website were we can observe the behavior (can PM - but hard for people reading the forums to help without being able to observe the behavior - including full requests and responses between the web server and web browser)? What other modifications have been made to the store?
Please do not just copy / paste the contents of files, instead use a CODE block. This can be done by clicking the "#" in the editor when replying. Example: [CODE]pasted contents of file[/CODE]. This will make the file contents easier to read and avoid potential "cleaning" of the pasted code by the editor.
Thank you for your response.Quote:
Originally Posted by lhungil
The .htaccess file is the default one that comes with Ultimate SEO, with the only change being that the shop is changed from /shop/ to /.
"Admin" -> "Configuration" -> "My Store" -> "Missing Page Check" is set to on.
I tried running the uninstaller and commenting out the install in the file, but it does not seem to remove everything from the database. Is there specific tables that need to be deleted that I can do manually to try from scratch?
I really appreciate the help.
The above is an example of the error log.Code:============================================================
===== URL Generation Log Started 2015-Aug-29T00:22:19
============================================================
Real URI: index.php?main_page=product_info&products_id=50
Request URI: /product-name-p-50.html
Canonical URI:
============================================================
===== Redirect Check Requested.
============================================================
Params from $_GET: products_id=50
Request sent to href_link('product_info', 'products_id=50', 'NONSSL', false, true, false, true)
Parsing Parameters for product_info
array (
0 => 'products_id=50',
)
Generated URL: http://www.websitename.com/product-name-p-50.html
NO REDIRECT: Alternative URI matched the requested URI.
============================================================
===== Generated Alternative URLs
============================================================
Request sent to href_link('product_info', 'products_id=50', 'NONSSL', false, false, true, true)
Parsing Parameters for product_info
array (
0 => 'products_id=50',
)
Generated URL: http://www.websitename.com/product_info.html?products_id=50
Request sent to href_link('index', '', 'NONSSL', true, false, true, true)
Generated URL: http://www.websitename.com/
Request sent to href_link('index', 'cPath=1', 'NONSSL', true, false, true, true)
Parsing Parameters for index
array (
0 => 'cPath=1',
)
Generated URL: http://www.websitename.com/product-name-c-1.html
Request sent to href_link('_info', 'cPath=1&products_id=50', 'NONSSL', true, false, true, true)
Page was not in the list of pages to rewrite, URI not generated!
What version of Ultimate URLs are you trying to install? The current version does not require any "commenting out of the install in the file". The current version also removes stuff from previous versions during installation and when uninstalled will remove stuff from the current version. Please make sure you use and reference the readme supplied with the current version of Ultimate URLs.Quote:
Originally Posted by faithofgod
I am unable to duplicate the behavior you are experiencing with a clean install of Zen Cart 1.5.4 and the latest version of Ultimate URLs. So the question is: "How is your store different"? Unless you are willing to supply the other information requested it will be difficult for us to attempt to help you further via the Zen Cart forums.
As a reminder here is what we need to know:
- What is the URL of a website were we can observe the behavior?
- What are the full contents of "/includes/configure.php" (obscure the db password)?
- What are the full contents of "/your_admin_folder/includes/configure.php" (obscure the db password and admin folder name if present)?
- What are the full contents of the .htaccess file at "/user/abc5/"?
- What are the full contents of the .htaccess file at "/user/abc5/public_html/"?
- What are the full contents of the .htaccess file at "/user/abc5/public_html/shop/"?
- What other modifications have been made to the store?
- What version of PHP is being used for Zen Cart ("admin" -> "version")?
- What process was used to upgrade Zen Cart to 1.5.4?
- When you change to the stock "classic" Zen Cart template, does the issue continue?
- What "Product Type" is being used for products in your store ("Product - General", "Document - General", "Product - Free Shipping", etc)?
Thank You for supplying an example copy of the Ultimate URLs debug log. The above log shows Ultimate URLs working correctly (and not issuing a 301 redirect). It also shows some code on your site passing an invalid Zen Cart page name (_info) to Ultimate URLs (which is correctly ignored by Ultimate URLs and passed back to Zen Cart to handle). Based upon the limited information provided so far, the problem is more likely with a server configuration (such as not quite correct directives in a .htaccess file) or with other modifications to Zen Cart 1.5.4 present on your site (such as the theme templates or product types).Quote:
Originally Posted by faithofgod
A client with an existing store has requested that USU be installed on his site. Once installed and enabled, will USU perform a 301-redirect from the "old style" links to the new, USU-style, ones? I'm concerned that this change might adversely affect his products' rankings and I don't want him to get dinged for any duplicate content.
If you enable "automatic redirects" it will perform 301s. If not enabled, it still will correctly use canonicals with the configured URIs (to avoid duplicate content penalties among other reasons).
Perfect, thanks for the detailed answer!
I just installed this plugin on our test site, www4. carmo.nl. It's been updated to zen-cart 1.5.4 before installing this plugin.
Most of the plugin does work for me, but I found that if I select another language while on the homepage, I get a Not found. The requested URL /index was not found on this server.
The link it goes to is www4. carmo.nl/index?language=fr (or one of the other languages we have on our site).
If I select another language whilst on any other page, the page loads in the selected language, just like I expect it to do.
The .htaccess file is in the root of the site.
The version of Ultimate URLs is 2.215
Enable alternate URLs is true
Generate cPath parameters is auto
Alternate URLs end with is empty (no text here)
Enable SEO cache to save queries is true
Format of alternative URLs is parent
Display categories as directories is off
All the enable ... cache are true
Remove problematic characters is punctuation
Filter rules is empty
Filter short words is 0
Enable automatic redirects is false
It happens both with the original setting for Limit alternate URLS to the following pages and with this being empty.
Is there something I did wrong or a setting I should change? It would be great if people could choose another language on our homepage.
Forgot to add this to my post (the one above this one):
No info in the debug logs, the ones in /logs/ the ones in /logs/ultimate_urls/ after saying in the admin interface I want the ultimate urls debug logs turned on, and also nothing in the regular error logs elsewhere on the server.
Just fo verification, how does the line read in your includes/confgure.php fle that has DIR_FS_LOGS defined in it?Quote:
Originally Posted by Siem
It looks like there are "typos" in your header, see
which should beCode:<!-- Language Container -->
<div class="language-switcher">
<label>Language : </label>
<a href="http://www4.carmo.nl/index?language=en">en</a><a href="http://www4.carmo.nl/index?language=fr">fr</a><a href="http://www4.carmo.nl/index?language=sp">sp</a> </div>
<!-- Language Container ends -->
Not an issue with USU.Code:<!-- Language Container -->
<div class="language-switcher">
<label>Language : </label>
<a href="http://www4.carmo.nl/index.php?language=en">en</a><a href="http://www4.carmo.nl/index.php?language=fr">fr</a><a href="http://www4.carmo.nl/index.php?language=sp">sp</a> </div>
<!-- Language Container ends -->
It says:Quote:
Originally Posted by mc12345678
define('DIR_FS_LOGS', '/var/www/edify/logs');
Lat9:
When I use a backup of the site, made just before installing this plugin, the links work correctly and do have a .php in it. Only when I use this plugin does the link generated for the language buttons make it without .php in it.
Maybe you're right and there is another reason why the buttons have an incorrect link in them with this plugin, but I don't know yet why the links are correct without the plugin.
Thanks for trying to help
@Siem, I've modeled your settings in a local test site, setting Alternate URLs end with to blank like you have. With that setting, the default .htaccess file and enabling the language sidebox, I get a link that looks like http://localhost/testsite/index?language=en which properly displays, when clicked, the main page.
Perhaps there's a setting in your .htaccess that's a bit off; if you'd post its contents wrapped by the CODE tags (the big # above the post-writing textbox), perhaps that would provide a clue.
The contents of the .htaccess:
I believe it is identical to the .htaccess file included in the plugin? Maybe I didn't understand everything in it and there is something here which I should change to match some other setting?Code:###############################################################################
# Add custom headers and options
###############################################################################
# Notes:
#
# Examples: Adding IE compatibility / edge flags, language and encoding flags,
# php or suphp directives, configure other Apache modules such as page_speed,
# and enable or disable Apache httpd options.
#
# Do NOT configure anything directly relating to physical or virtual resources
# in this section. These should be addressed later on in this file.
###############################################################################
#Options -Indexes
###############################################################################
# Enable mod_rewrite processing using the rules in this .htaccess file
###############################################################################
# Notes:
#
# <IfModule> should be avoided at all costs. If mod_rewrite is not available
# it is almost always better to return HTTP 500 status. This way we see there
# is an issue as soon as the .htaccess file is uploaded.
#
# For mod_rewrite to work, the Apache server option to allow symbolic links to
# be followed must be enabled. Most providers supporting mod_rewrite will
# already have it enabled for you, but if your rewrite rules are not working
# you can un-comment the first directive below to manually enable the option.
#
# Don't forget, mod_rewrite directives are processed in order until a matching
# RewriteRule with the [L] flag is encountered. So the more specific a rule is
# the closer it should appear to the top of this file.
###############################################################################
#Options +FollowSymLinks
RewriteEngine on
###############################################################################
# Tell mod_rewrite where this file is relative to the server document_root
###############################################################################
# Notes:
#
# This directive should only be enabled if this .htaccess file is not placed
# in the document_root (usually public_html, www, or web) of the (sub)domain.
#
# An easy way to determine the location relative to the server document_root is
# to look at the URL used to access a file in this folder. For example if you
# access a "page" in the same folder as this file by typing in the URL
# "www.mydomain.com/myfolder/index.html" then "myfolder" will be the location
# of this file relative to the server document_root.
#
# Another quick and easy way to determine the correct setting for this is to
# look at the defined value for DIR_WS_CATALOG and DIR_WS_HTTPS_CATALOG in
# Zen Cart's configure.php files. All three values should match.
#
# Don't forget the leading and trailing /. This directive requires both!
###############################################################################
#RewriteBase /shop/
###############################################################################
# Redirect if request was for index.php (no query)
###############################################################################
# Notes:
#
# This is only required if the site generates references to index.php with no
# parameters. This rule will force a 301 redirect to the site root when a
# request is made for "/index.php" with no query terms (?key=value).
###############################################################################
#RewriteCond %{QUERY_STRING} ^$
#RewriteRule ^index\.php$ / [R=301,L]
###############################################################################
# Add any custom 301 redirects
###############################################################################
# Notes:
#
# In general these should be few and far between. If you use a RewriteRule
# be sure to add the L flag to let Apache mod_rewrite know to stop processing
# and skip any RewriteRules defined later in the .htaccess file.
###############################################################################
###############################################################################
# Redirect if request was for index.php (with or without query)
###############################################################################
# Notes:
#
# This is a performance optimization. If the request is for index.php simply
# pass the request on and do not process any other mod_rewrite directives in
# this file.
#
# Basically this avoids the overhead of checking if index.php is a real file
# or directory (used in subsequent mod_rewrite rules) before sending the
# request to index.php.
###############################################################################
RewriteRule ^index\.php$ - [L]
###############################################################################
# Start Ultimate (SEO) URLs
###############################################################################
# Notes:
#
# You should not make any changes in this section unless you really understand
# how it will impact your web site. Mistakes can break things.
###############################################################################
# Handles the new URL formats
RewriteRule ^(.*)-c-([0-9_]+)/(.*)-p-([0-9]+)(.*)$ index\.php?main_page=product_info&products_id=$4&cPath=$2&%{QUERY_STRING} [L]
RewriteRule ^(.*)-c-([0-9_]+)/(.*)-pi-([0-9]+)(.*)$ index\.php?main_page=popup_image&pID=$4&cPath=$2&%{QUERY_STRING} [L]
RewriteRule ^(.*)-c-([0-9_]+)/(.*)-pr-([0-9]+)(.*)$ index\.php?main_page=product_reviews&products_id=$4&cPath=$2&%{QUERY_STRING} [L]
RewriteRule ^(.*)-c-([0-9_]+)/(.*)-pri-([0-9]+)(.*)$ index\.php?main_page=product_reviews_info&products_id=$4&cPath=$2&%{QUERY_STRING} [L]
# Original (unchanged) URL formats
RewriteRule ^(.*)-p-([0-9]+)(.*)$ index\.php?main_page=product_info&products_id=$2&%{QUERY_STRING} [L]
RewriteRule ^(.*)-m-([0-9]+)(.*)$ index\.php?main_page=index&manufacturers_id=$2&%{QUERY_STRING} [L]
RewriteRule ^(.*)-pi-([0-9]+)(.*)$ index\.php?main_page=popup_image&pID=$2&%{QUERY_STRING} [L]
RewriteRule ^(.*)-pr-([0-9]+)(.*)$ index\.php?main_page=product_reviews&products_id=$2&%{QUERY_STRING} [L]
RewriteRule ^(.*)-pri-([0-9]+)(.*)$ index\.php?main_page=product_reviews_info&products_id=$2&%{QUERY_STRING} [L]
RewriteRule ^(.*)-ezp-([0-9]+)(.*)$ index\.php?main_page=page&id=$2&%{QUERY_STRING} [L]
RewriteRule ^(.*)-c-([0-9_]+)(.*)$ index\.php?main_page=index&cPath=$2&%{QUERY_STRING} [L]
# Rewrite all other requests (if the file / directory does not exist)
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index\.php?main_page=$1&%{QUERY_STRING} [L]
###############################################################################
# Add any other directives relating to the handling of physical files
###############################################################################
# Notes:
#
# If processing makes it this far, the request was for a real file or folder.
# Example: Adding further processing related to browser caching or security.
###############################################################################
Thanks for trying to help.
Is your Zen Cart installed in the root directory of your hosted file-system? I'm just punting here, it's lhungil that knows this stuff left, right and upside down!
It's installed in the documentroot? The config in ......../apache2/sites-enabled/ has the directory the store is in as the root directory. I think that's what you meant?Quote:
Originally Posted by lat9
Yes, that's what I meant. I'm all out of questions and suggestions; let's wait for lhungil to get back as I'm sure that he'll know straight-away what's up.
This is very disconcerting. Can you verify the user your web server runs as has access to write to "/logs/" (usually www-data on Debian)? Can you verify the user you are using to access the web server's filesystem has read access to "/logs/" (and sub-directories and files)?Quote:
Originally Posted by Siem
What version of PHP is in use on the web server (Zen Cart Admin -> Version)? What bridge is being used to communicate between Apache2 <==> PHP (libapache2-mod-php5, libapache2-mod-php5filter, libapache2-mod-suphp, libapache2-mod-fcgid, libapache2-mod-scgi, etc)? Is the filesystem local or accessed over a network (NFS, SMB, etc)?
Same in all of my test environments. The following snippet found at the end of the ".htaccess" file you supplied tells mod_rewrite (Apache2) to send a request for "/index?language=en" internally to "/index.php?main_page=index&language=en".Quote:
Originally Posted by lat9
It appears your server is not processing this mod_rewrite directive for some reason when the URI "/index" is requested...Code:RewriteRule ^(.*)$ index\.php?main_page=$1&%{QUERY_STRING}
Can you check your server configuration (and VirtualHost configurations) to ensure no other directives are interfering? Do you have mod_security or mod_pagespeed installed / enabled? Can you verify there are no .htaccess files in parent directories (for example if the root is set to "/var/www/www4/", check "/var/www/.htaccess"). It is not uncommon for the "default" site to cause some issues if left enabled when serving multiple name based virtual hosts from on the same server (and nesting roots).
If your server has "mod_negotiation" enabled (usually the default on Debian) and you have a directory or file starting with "index" in the root folder (other than "index.php" - rare as none are included with a stock install of Zen Cart), this can also cause issues (delete the file / folder or disable "mod_negotiation" in the first section of the .htaccess file using "Options -MultiViews").
@lhungil: Welcome back!
Hi lhungil,
It's only when I try to select another language on the homepage that there are no logs even with log enabled. For all the other pages the standard? logs are created in /logs/ultimate_urls/
Permission for /logs/ is root, permission for /logs/ultimate_urls/ is www-data. This one does have access, hence the files which are created in all other cases.
The PHP version is: 5.4.36-0+deb7u3 (Zend: 2.4.0)
The bridge between PHP and Apache2 is libapache2-mod-php5 I think? By the loaded modules is a mod_php5 which is one of the ones you mentioned?
The filesystem is local.
mod_security and mod_pagespeed are not loaded.
There are no .htaccess files in the parent directories.
mod_negotiation is enabled, but there is no other file or directory in the root directory which starts with index (other than index.php which is supposed to be there).
Changing Alternate URLS end with from nothing to .php does work. So for now I just let it stay that way.
Hope the answers make any sense to you, and thanks everyone for trying to help.
Thank you for clarifying. Previously you said no logs at all (which would be very disconcerting). However no logs only when "/index" is requested (plus seeing an Apache default 404 page) indicates the request never reached Zen Cart (or Ultimate URLs).
The issue is not with Ultimate URLs. Something in your server setup is intercepting requests for "/index" BEFORE the RewriteRule in the .htaccess is triggered (or is overriding the rules AFTER). This will most likely be an issue caused by something in your web server's Apache configuration (or some sort of "security" or "proxying" configuration).
The csuse could be an Apache server-wide or virtualhost directive (some occur AFTER rules in .htaccess files), issues caused by nested virtual host roots, something like mod_negotiation which triggers BEFORE .htaccess rules in a .htaccess file (try disabling MultiViews as suggested), an errant DirectoryIndex configuration, some sort of proxy / security software (and configuration), and the list goes on...
As long as you are okay with it, telling Ultimate URLs to add a suffix avoids the server configuration issue (something intercepting calls to "/index" and returning a 404) should work. If you are not okay with it and need further hekp, you may want to contact the hosting provider to troubleshoot and correct the underlying cause.
NOTE 1:It appears the server is running Debian. I've been unable to duplicate the issue with a stock VM running Debian 7 or Debian 8 (Apache2 default site disabled, multiple NameVirtualHosts with unnested document roots enabled, mod_php5 or mod_fcgi).
Thank you for helping and the clear questions. That helped a lot for me.
The server we use does indeed run Debian.
I think we'll just stick to using a suffix to make everything work. Maybe some other time when I actually have time to spare I'll try to look further into what may cause our problem, what setting elsewhere on the server is stopping Ultimate URLs to work. If I do find what caused it I will tell so here, maybe that would someday help someone else.
Thank you.
Sounds like a plan, would be interested if you do at some point determine exactly what is causing the conflict.Quote:
Originally Posted by Siem
Just wanted to confirm that I CAN upgrade from this version without having to uninstall..
If you are upgrading from Zen Cart <1.5.0 as well (without a clean Zen Cart file set), I would recommend uninstalling first (and checking the DB). If already on Zen Cart >= 1.5.0 and all files from previous versions have been removed, should be able to upgrade w/o uninstalling first.
Would recommend taking a screenshot of the configuration before starting wither way. Some settings may need to be hand adjusted after the upgrade - for example converting any "character conversions" into "PCRE filters".
Got it!!Quote:
Originally Posted by lhungil
I want to submit my problem
using the plugin I have split-url as an example:
----
/interni-c-83/complementi-darredo-c-83_97/porta-biancheria-c-83_97_180/
/interni-c-83/complementi-darredo-c-83_97/porta-biancheria-c-83_97_180/?pg=store
/idee-regalo-c-86/
/idee-regalo-c-86/?pg=store
....
how can I fix !! ?
thanks
What modification have you installed to add the "pg=store"? It is not part of a stock Zen Cart installation. What BUSINESS result is achieved by adding "pg=store" to the query string?
yes the string is at:
/httpdocs/includes/classes/categories_ul_generator.php a file integrated of ########## template source !!!
and i have a problem similar an other website
i have duplicate of indexing page of google
the ulr rewrite:
http://ww.site.com/gancio-traino-nis...amc-p-731.html
and this
<link rel="canonical" href="http://ww.site.com/index.php?main_page=product_info&products_id=731" />
in this mode i have a canonical error every page of website!!
very thanks for ypur support
Recommend removing this string from the 3rd party code if it serves no business purpose.Quote:
Originally Posted by salvo72
If it does serve a business purpose, you will need to tell Zen Cart to ignore the query string when generating the canonical link. This can be sone by adding "pg" to the list in "/includes/init_includes/overrides/init_canonical.php".
If the template / plugin author does not mention making this change (and does not include their own override file - to reference and merge during install), would recommend asking them politely to include the change in their documentation
Double check the installation of Ultimate URLs and all files. Make sure the latest version is installed (and no files are left over from really old versions). Make sure the installed Zen Cart theme correctly utilizes without modification the variables added by "init_canonical.php".Quote:
Originally Posted by salvo72
For further support, please provide andwers to ALL of the questions in the forum "Posting Tips". Answers to these are essential to help us help you. The "Posting Tips" can be found by: Using a desktop or laptop to access the forums, clicking the reply button, and scrolling up (they appear above the textarea where you type).
I've got a client running USU 2.212 on Zen Cart v1.5.0. The site is fairly customized, notably using the Multi-Site Module running on a Windows Server and has been getting logs similar to the following:
The logs are usually accompanied by a server lock-up. The site's seo_cache table is 358.3 KiB in size.Code:[12-Oct-2015 14:09:29 America/New_York] PHP Fatal error: Out of memory (allocated 13107200) (tried to allocate 25165824 bytes) in C:\Websites\test\includes\classes\seo.url.php(1196) : eval()'d code on line 10923
[12-Oct-2015 14:09:29 America/New_York] PHP Stack trace:
[12-Oct-2015 14:09:29 America/New_York] PHP 1. {main}() C:\Websites\test\index.php:0
[12-Oct-2015 14:09:29 America/New_York] PHP 2. require() C:\Websites\test\index.php:26
[12-Oct-2015 14:09:29 America/New_York] PHP 3. require() C:\Websites\test\includes\application_top.php:162
[12-Oct-2015 14:09:29 America/New_York] PHP 4. SEO_URL->__construct() C:\Websites\test\includes\autoload_func.php:82
[12-Oct-2015 14:09:29 America/New_York] PHP 5. SEO_URL->generate_products_cache() C:\Websites\test\includes\classes\seo.url.php:83
[12-Oct-2015 14:09:29 America/New_York] PHP 6. SEO_URL->get_cache() C:\Websites\test\includes\classes\seo.url.php:1025
Are there any configuration settings that I can look at/modify to possibly circumvent this out-of-memory condition?
Hmm, isn't 13107200 bytes ~ 13Mb? And the products cache is loading 25Mb of product URLs into memory on that line.... Seems a bit low for a PHP to complain at 13 + 25 = 38Mb... Typos? One may want to verify the amount of memory the hosting plan includes for PHP... And check the configured limit in php.ini...
If there are alot of products and limited memory on the server (25Mb of URL data is a fair amount), one can disable the product cache to save memory. When the product cache is enabled, all product URLs are preloaded into memory. When disabled, the generated URLs for products are added on demand into the global cache. When the global cache is disabled, no generated URLs are cached in memory.
lhungil, thanks for the quick response (and other than some URL editing, the numbers were all as present in the log itself)! It's a self-hosted site and I'll check with the owner on the settings.
When I go to the site's Configuration->Ultimate SEOs, there are many radio-button selections ... where none of the radio buttons are selected! Have you seen this before?
Are any Numinex modules installed (which may have altered Zen Cart's stock "/admin/configuration.php")?Quote:
Originally Posted by lat9
There sure are! It's the Numinix-branded Configuration menu that I'm presented with.
Numinex (at the time Ultimate URLs 2.215 was released) alters the workflow of the standard Zen Cart configuration options. This breaks any 3rd party module (such as Ultimate URLS) relying upon the standard Zen Cart workflow for configuration options.Quote:
Originally Posted by lat9
I would recommend starting by upgrading to the latest version of Ultimate URLs (2.215 at the time of writing). Make sure to review the "Recommended Patches" in the readme. There are instructions for Numinex users on how to patch the Numinex version of "/admin/configuration.php". Once applied, the patches will restore the stock Zen Cart workflow for Zen Cart configuration options (leaving the Numinex functionality intact).
Finally, be sure to apply the previously posted bugfix for Ultimate URLs 2.215.
One more question (right now): Is there a "good" way to flush the contents of the seo_cache table? I think (?) that what I want to do is null-out the products' entries to reduce the size of the database (cache_name = 'seo_urls_vs_products'), besides disabling the products' cache.
I think I found it: Is that what the Configuration->Ultimate SEO->Reset SEO Cache does?
That is correct (was added to allow manual clearing of the DB cache via the Zen Cart administrative interface). The DB cache entries are also cleared automatically (when older than 30 days, when products / categories change, and when some settings are changed).
Hey, guys, I installed Ultimate URLs today successfully, I thought. It's version 2.215 and I'm using zen cart version 1.5.1. The problem is now that NOTHING is showing up when i go to my website. Did I overlook something? Is there a section of this thread anyone can point me to for assistance?
what would be causing this
?http://killerbeehobby.com/shopshopsh...pshopshopshop/
When I visit your website I am seeing a a "HTTP 500 - Internal Server Error".Quote:
Originally Posted by fcutler4
Most common causes:
- The .htaccess file was placed in the wrong location
- The .htaccess file was not modified to match the store configuration / location
- Errors in one (or both) of the Zen Cart "/includes/configure.php" files
- Files contained in this module were uploaded to the wrong location on the server
- An error occurred when uploading the files to the server
- The Hosting Provider does not allow mod_rewrite on their server
- The Hosting Provider does not allow one or more of the directives required for mod_rewrite in a .htaccess file (such as follow symbolic links, rewrite base, etc)
- The Hosting Provider is using some sort of internal REWRITE to access the web root (sign of a cheap host / host not following best practice)
Please review the link in my signature for troubleshooting "HTTP 500 - Internal Server Error". You may need to work with your hosting provider to gain access to the Apache (or other webserver) error logs for your domain. You may also want to check the Zen Cart "debug" logs for any PHP error messages.
Is your Zen Cart store installed at "/shop/"? If so, was the .htaccess file modified to reflect the store location ("/shop/")? If so, was the .htaccess file uploaded to the correct location ("/shop/")?
Are all of the paths 100% correct in both "/includes/configure.php" and "/your-admin-folder/includes/configure.php"? Can you post (wrap in code tags - press the # button) the lines from those files with: HTTP_*, HTTPS_*, DIR_WS_CATALOG, DIR_WS_HTTPS_CATALOG, DIR_FS_CATALOG, and DIR_FS_LOGS?
Have you tried uploading the module a second time? Ensured all files are placed in the correct location when uploaded? Verified each file was uploaded successfully (and not corrupted)?
I've installed this for a client after upgrading from 1.3.9. The issue is an existing directory for a point of sale system resulting in a 404. The path is www.STORE.com/pos/index.php
Disabling Ultimate URL does not work. But removing the htaccess file does. There is nothing else in the htaccess except this plugin info. I know it's supposed to ignore real files and directories, but it's not.
Does this file (or any other file in the 3rd party "pos" code), require or include Zen Cart's "application_top.php"? In versions of Ultimate URLs <= 2.215, Zen Cart "frankenpages" placed inside sub-directories will trigger the "automatic redirects" feature. The temporary workaround is to disable "automatic redirects". This has been corrected in an upstream version (by adding code to detect and exclude "frankenpages" from the "automatic redirect" processing).Quote:
Originally Posted by jeking
Does a file exist named "/pos.php", "/pos.html", "/pos.jpg", or anything else matching "/pos.*"? This is probably not the issue, but if a file does exist, you may need to disable Apache "MultiViews" by adding the following to your ".htaccess" file.
Code:Options -MultiViews
The last generic "catch all" rule in the .htaccess will ignore directories and files which do not physically exist. This is handled by Apache directly, not Zen Cart or Ultimate URLs. Issues here would point to a server configuration issue (or issues with other Apache server directives).Quote:
Originally Posted by jeking
However if the 3rd party "pos" code uses the same URL schemes (ending with the same "anchors" - ex: -p-123, -c-123, -ezp-123, etc), the preceding rules are applied (including to physically existing resources). If for some reason the 3rd party "pos" code does use URLs matching the same format as Ultimate URLs, you can exempt the "pos" folder from the rules added by Ultimate URLs.
Code:###############################################################################
# Start Ultimate (SEO) URLs
###############################################################################
# Notes:
#
# You should not make any changes in this section unless you really understand
# how it will impact your web site. Mistakes can break things.
###############################################################################
# Skip Ultimate URLs directives for specific requests
RewriteCond %{REQUEST_URI} ^/pos/
RewriteRule .* - [S=12]
# Handles the new URL formats
RewriteRule ^(.*)-c-([0-9_]+)/(.*)-p-([0-9]+)(.*)$ index\.php?main_page=product_info&products_id=$4&cPath=$2&%{QUERY_STRING} [L]
RewriteRule ^(.*)-c-([0-9_]+)/(.*)-pi-([0-9]+)(.*)$ index\.php?main_page=popup_image&pID=$4&cPath=$2&%{QUERY_STRING} [L]
RewriteRule ^(.*)-c-([0-9_]+)/(.*)-pr-([0-9]+)(.*)$ index\.php?main_page=product_reviews&products_id=$4&cPath=$2&%{QUERY_STRING} [L]
RewriteRule ^(.*)-c-([0-9_]+)/(.*)-pri-([0-9]+)(.*)$ index\.php?main_page=product_reviews_info&products_id=$4&cPath=$2&%{QUERY_STRING} [L]
# Original (unchanged) URL formats
RewriteRule ^(.*)-p-([0-9]+)(.*)$ index\.php?main_page=product_info&products_id=$2&%{QUERY_STRING} [L]
RewriteRule ^(.*)-m-([0-9]+)(.*)$ index\.php?main_page=index&manufacturers_id=$2&%{QUERY_STRING} [L]
RewriteRule ^(.*)-pi-([0-9]+)(.*)$ index\.php?main_page=popup_image&pID=$2&%{QUERY_STRING} [L]
RewriteRule ^(.*)-pr-([0-9]+)(.*)$ index\.php?main_page=product_reviews&products_id=$2&%{QUERY_STRING} [L]
RewriteRule ^(.*)-pri-([0-9]+)(.*)$ index\.php?main_page=product_reviews_info&products_id=$2&%{QUERY_STRING} [L]
RewriteRule ^(.*)-ezp-([0-9]+)(.*)$ index\.php?main_page=page&id=$2&%{QUERY_STRING} [L]
RewriteRule ^(.*)-c-([0-9_]+)(.*)$ index\.php?main_page=index&cPath=$2&%{QUERY_STRING} [L]
# Rewrite all other requests (if the file / directory does not exist)
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index\.php?main_page=$1&%{QUERY_STRING} [L]
NOTE: The above examples are intended for the ".htaccess" file provided with Ultimate URLs 2.215. If you are running a different version, you may need to adjust the rules to correctly skip the correct number of RewriteRule directives in your ".htaccess" file.
This is version 2.215. But I overlooked an obvious cause. The htaccess on the /pos/ folder was the cause of the problem. The folder is password protected and even though it looked good, commenting out those lines fixed the problem. I'll figure out why, but the problem is not Ultimate URL.
Please update this mod with the new copy of includes/functions/html_output.php
from the November 2015 patches
https://www.zen-cart.com/showthread....-November-2015
For those installing Ultimate URLs on a patched copy of Zen Cart, the installer will leave the patches alone and automatically handle merging only the required changes to "/includes/functions/html_output.php".
If one overwrites their copy of "/includes/functions/html_output.php" with a patched copy, be sure to run the Ultimate URLs installer again (to add the required changes).
For those who choose to manually merge the changes required for Ultimate URLs (not recommended), be sure to also incorporate the above security bugfix kindly posted by swguy in this thread.
There is a search Bug in Ultimate Seo 2.15
I have added Advanced_search_result in the pages to have Seo urls. It works fine if we search for one word but if we search for 2 words the search page 1 works fine but on clicking page 2 we are taken to advanced search page. On checking the url difference I found this:
First page url: advanced_search_result.html?search_in_description=1&keyword=kelvin clean
Search page 2 url: index.php?main_page=advanced_search&search_in_description=1&keyword=kelvin clean&inc_subcat=0&sort=20a&page=2
The problem is advance_search_result has changed to advanced_search
If we disable ultimate seo everything works fine
Correct. There are a number of things at play here, but the root cause is a double encoding of the URLs on the "search pages".Quote:
Originally Posted by manishanirula
The quickest fix is to just disable generating alternative URLs for "advanced_search_result".
Upon initial installation Ultimate URLs enabled generation of alternate URLs for "index, product_info, product_music_info, document_general_info, document_product_info, product_free_shipping_info, products_new, products_all, shopping_cart, featured_products, specials, contact_us, conditions, privacy, reviews, shippinginfo, faqs_all, site_map, gv_faq, discount_coupon, page, page_2, page_3, page_4". This is the recommended setting for most sites.
A slightly more complex fix (allowing generation of alternative URLs for the search result pages) involves making changes to "/includes/classes/usu.php".
Replace:
With:Code:/**
* Convert an array of query parameters to a URI query string. This is safe
* for use under 5.2+ with optimizations for PHP 5.4+.
*
* @param array the array of query parameters
*/
protected function build_query($parameters) {
if(version_compare(PHP_VERSION, '5.4.0') >= 0) {
$parameters = http_build_query($parameters, '', '&', PHP_QUERY_RFC3986);
}
else {
$compile = array();
foreach($parameters as $key => $value) {
if($key !== null && $key != '') {
// Prior to PHP 5.3, tildes might be encoded per RFC 1738
// This should not impact functionality for 99% of users.
$compile[] = rawurlencode($key) . '=' . rawurlencode($value);
}
}
$parameters = implode('&', $compile);
unset($compile);
}
return $parameters;
}
Code:/**
* Convert an array of query parameters to a URI query string. This requires
* the code calling zen_href_link() to ensure all parameters passed to the
* function to be already encoded when applicable.
*
* @param array the array of query parameters
*/
protected function build_query($parameters) {
$compile = array();
foreach($parameters as $key => $value) {
if($key !== null && $key != '') {
$compile[] = $key . '=' . $value;
}
}
return implode('&', $compile);
}
NOTE: Those with third party code assigning arrays (as the value) for a key in the URL parameters (not recommended) will need to apply additional changes to the function.
Thanks...Its working fine now but would you suggest making the above changes. Will it impact anything else on website.
Also is there a way to remove the query string "advanced_search_result.html?search_in_description=1&keyword=" from the url of search. This will be really helpful in SEO
No. Zen Cart requires the information be passed in the URL (and they are not always the same). In a stock Zen Cart the "Search Results Page" is flagged as noindex and nofollow. The big SEs frown upon "search result spam". So no real "SEO" benefit to be found by messing with the URL of the "Search Results Page".Quote:
Originally Posted by manishanirula
Thank You for Explaining
I am working with a new installation of 1.5.4, with winchester responsive templates.
I just installed the latest version of Ultimate SEO URLS (2.215).
I am seeing an issue with the built-in manufacturers sidebox, which displays a pulldown list of all the manufacturers, and when you choose one of the manufacturers, it submits a form, and goes to that manufacturers page. With SEO URLS installed and turned on, it is going to:
All the other pages are generating appropriate seo urls.Code:?main_page=index&manufacturers_id=2
I searched through this thread, and found a report of a similar issue, and the response was:
Like I said, I am using the built-in 1.5.4 manufacturers sidebox, so presumably it should be updated with the latest code.Quote:
Originally Posted by lhungil
I saw this later response, where someone said that they were able to fix this problem:
However, I'm not sure if they were referring to the same sidebox module.Quote:
Originally Posted by bwlinux
The sidebox module template file I am referring to is in
It doesn't contain just a link, but a form that gets submitted when you choose one of the manufacturers in the list.Code:includes/templates/template_default/sideboxes/tpl_manufacturers_select.php
Here is the contents of the sidebox template file:
It does appear not to have been modified since 2010.Code:<?php
/**
* Side Box Template
*
* @package templateSystem
* @copyright Copyright 2003-2010 Zen Cart Development Team
* @copyright Portions Copyright 2003 osCommerce
* @license http://www.zen-cart.com/license/2_0.txt GNU Public License V2.0
* @version $Id: tpl_manufacturers_select.php 15882 2010-04-11 16:37:54Z wilt $
*/
$content = "";
$content .= '<div id="' . str_replace('_', '-', $box_id . 'Content') . '" class="sideBoxContent centeredContent">';
$content.= zen_draw_form('manufacturers_form', zen_href_link(FILENAME_DEFAULT,
'', $request_type, false), 'get');
$content .= zen_draw_hidden_field('main_page', FILENAME_DEFAULT);
$content .= zen_draw_pull_down_menu('manufacturers_id', $manufacturer_sidebox_array, (isset($_GET['manufacturers_id']) ? $_GET['manufacturers_id'] : ''), 'onchange="this.form.submit();" size="' . MAX_MANUFACTURERS_LIST . '" style="width:
90%; margin: auto;"') . zen_hide_session_id();
$content .= '</form>';
$content .= '</div>';
?>
Does anyone have any suggestions on how I can fix this issue? I apologize if I missed a post on this, but I tried to do a very thorough search on this.
Thanks in advance for any help!
ok I have been searching this thread for hours and not finding anything on this. I have 1.5.4 loaded and trying to install this module. I have triple checked all of my install files and everything seems to be right but I am getting the following messages... can anyone help or shed light on to what might possibly be wrong? the X's are replacing my admin section and user name...
Error Filesystem Error: Unable to delete '/home/xxxxx/public_html/xxxxxxxxx/includes/reset_seo_cache.php'. Verify your web server has access to delete this file. Installation will not continue until the web server is granted access to remove the file.
Error Filesystem Error: Unable to delete '/home/xxxxx/public_html/xxxxxxxxx/includes/auto_loaders/config.seo.php'. Verify your web server has access to delete this file. Installation will not continue until the web server is granted access to remove the file.
Error Filesystem Error: Unable to delete '/home/xxxxx/public_html/xxxxxxxxx/includes/extra_datafiles/seo.php'. Verify your web server has access to delete this file. Installation will not continue until the web server is granted access to remove the file.
Error Filesystem Error: Unable to delete '/home/xxxxx/public_html/xxxxxxxxx/includes/init_includes/init_seo_config.php'. Verify your web server has access to delete this file. Installation will not continue until the web server is granted access to remove the file.
Error Filesystem Error: Unable to delete '/home/xxxxx/public_html/xxxxxxxxx/includes/functions/extra_functions/seo.php'. Verify your web server has access to delete this file. Installation will not continue until the web server is granted access to remove the file.
Error Filesystem Error: Unable to delete '/home/xxxxx/public_html/xxxxxxxxx/includes/languages/english/extra_definitions/seo.php'. Verify your web server has access to delete this file. Installation will not continue until the web server is granted access to remove the file.
Error Filesystem Error: Unable to delete '/home/xxxxx/public_html/includes/auto_loaders/config.ultimate_seo.php'. Verify your web server has access to delete this file. Installation will not continue until the web server is granted access to remove the file.
Error Filesystem Error: Unable to delete '/home/xxxxx/public_html/includes/extra_datafiles/seo.php'. Verify your web server has access to delete this file. Installation will not continue until the web server is granted access to remove the file.
Error Filesystem Error: Unable to delete '/home/xxxxx/public_html/includes/auto_loaders/config.seo.php'. Verify your web server has access to delete this file. Installation will not continue until the web server is granted access to remove the file.
Error Filesystem Error: Unable to delete '/home/xxxxx/public_html/includes/init_includes/init_seo_config.php'. Verify your web server has access to delete this file. Installation will not continue until the web server is granted access to remove the file.
Error Filesystem Error: Unable to delete '/home/xxxxx/public_html/includes/classes/seo.url.php'. Verify your web server has access to delete this file. Installation will not continue until the web server is granted access to remove the file.
Error Filesystem Error: Unable to delete '/home/xxxxx/public_html/includes/classes/seo.install.php'. Verify your web server has access to delete this file. Installation will not continue until the web server is granted access to remove the file.
Error Ultimate URLs installation / upgrade failed!
That message indicates the user (the HTTP server or PHP runs as) does not have write / delete permissions for those files.
What permissions are assigned to those files? What user is the HTTP server running as? If PHP runs as a seperate process, what user are the scripts run as?
Answers to the above depend upon your hosting provider and their server configuration. Your hosting provider should be able to help identify the above information. They should also be able to identify the neccessary changes (needed on their server) you need to make to file permissions to allow write / delete access for PHP scripts.
Was afraid you were gonna ask and say those things. I did change the permissions on those files to 777 and had tried it again but still didn't work. As far as the rest of your questions, they are a little bit greek to me so I will contact the hosting provider and ask them for assistance and see where it goes from there. Thanks for your quick reply!
Quote:
Originally Posted by lhungil
Hmm... Can you also verify the path to those files is correct (and web server software)? One can check the path by looking at the output from clicking "version" in the Zen Cart admin.
ok got it, turns out that mod_ruid2 was not running on my server. That was enabled by my host and all is working fine now it appears! Thank you so much for the help!!
Quote:
Originally Posted by lhungil
Thank You for letting us know the host was able to come to your aid :)Quote:
Originally Posted by foilman
Hi - if I change the name of a category will existing links (internal and external) still resolve to the newly renamed category?
cheers,
Mike
They will still result in the same category page being shown (old and new URLs will both work). The canonical on the page will point to the new name / URL. If "automatic redirects" are enabled, a 301 redirect to the new URL will be returned.Quote:
Originally Posted by shags38
Thanks for that Larry :)Quote:
Originally Posted by lhungil
hi,
i had a "small" problem. lets say you did a search for 2 words:
red or blue
zc will now search for either or of these 2 terms. now, lets say your search results came up with more than 1 page. if you clicked on the 2nd page of your paginator, zen will no longer find your search terms.
i have isolated this down to double encoding of the keyword search terms. in my example i was able to solve this problem by changing line 424 in includes/classes/usu.php as below
it seems that this fix might be needed in other places where there are multiple words being used as part of a key in the url.PHP Code:// original
default:
$container[$p2[0]] = ($p2[1]);
break;
}
//changed
default:
$container[$p2[0]] = urldecode($p2[1]);
break;
}
I noticed the same problem and added this to my htaccess file:Quote:
Originally Posted by carlwhat
RewriteCond %{QUERY_STRING} (.*?)%(25)+20(.*?%(25)+20.*)
RewriteRule ^ %{REQUEST_URI}?%1+%3 [N]
RewriteCond %{QUERY_STRING} (.*?)%(25)+20(.*)
RewriteRule ^ %{REQUEST_URI}?%1+%3 [L,R=301]
Does this work on v1.55?
i have version 2.212 running on v1.55 with no problems.Quote:
Originally Posted by ravynw34
Great thanks. I will go ahead and put it on our dev.
Appreciate the response.
Carl,
Would you be able to send a link to a site you have it working on.
Hope you don't mind.
thanks
what?
www.vinsrare.com
Thanks Carl. I just wanted to see it on a working v1.55 site.
Sorry didn't mean to confuse you.