Has anyone had any luck doing this? When I use an SEO URL on my dev environment (http://localhost:8888/mysite), the URLs always wind up redirecting to the home page.

http://localhost:8888/mysite/category
http://localhost:8888/mysite/category/product

both just go to index.php

I'm hoping for a solution that does not involve virtual hosts.

Using older CEON version: https://www.zen-cart.com/downloads.php?do=file&id=889

I have used it in a sub-directory where there were other resources available from an alternate sub-folder. The question though in seeing "the issue" described above is: are you wanting the site to eventually operate in a sub-directory or is it in a sub-directory out of "development" convenience?

If out of convenience then should use a sub-domain to remove the web-side sub-directory so that the links from the existing store would be relative to your development store.

This change is just needed for development - the live site is at the root.
But what I'm seeing is that when I get into index.php, the URL I have is just "index.php" - no args are passed so it always goes to the home page. $_GET is empty. How do the arguments from http://localhost:8888/mysite/category/product get to Zen Cart?

swguy:

This change is just needed for development - the live site is at the root.
But what I'm seeing is that when I get into index.php, the URL I have is just "index.php" - no args are passed so it always goes to the home page. $_GET is empty. How do the arguments from http://localhost:8888/mysite/category/product get to Zen Cart?

They get there by the uri actually reaching the sub-directory. Meaning, with the current arrangement. As far as the plugin is concerned, all rewritten uris are based off of the current HTTP_SERVER or HTTPS_SERVER where neither of those have a sub-directory in them. When the link is generated, an attempt is made to access the localhost at its root, which in this case is not supporting the catalog.

So a potential solution if the associated database table is not being transferred back or even if it is that the below is undone, then could prepend all of the uris with your sub-directory (considering it is a local host and not really "worried" about the SEO part.)

UPDATE ceon_uri_mappings SET uri= CONCAT('/mysite', uri);

To subsequently remove, I expect (though haven't tested) to work:

UPDATE ceon_uri_mappings SET uri = REPLACE(uri, '/mysite', '');

Note, that this will replace all such occurrences within a given string, so hopefully '/mysite' is unique to just the prefix of the uri. Otherwise a more involved query would be needed.

I can see how your approach would work if I was actually getting arguments, but I'm not. In init_canonical.php, the case $this_is_home_page is triggered because $_GET is empty.

You said, > They get there by the uri actually reaching the sub-directory. but I don't think this is right. I am in the subdirectory, but the URL has been rewritten from wireless/category/product to wireless/index.php - no sign of the category or product.

swguy:

I can see how your approach would work if I was actually getting arguments, but I'm not. In init_canonical.php, the case $this_is_home_page is triggered because $_GET is empty.

You said, but I don't think this is right. I am in the subdirectory, but the URL has been rewritten from wireless/category/product to wireless/index.php - no sign of the category or product.

The arguments are provided by a successful match of the uri to the database record. Would have to see the related htaccess(es) to understand how what is seen was generated. But again, the get arguments are populated by processing of a successfully matched uri.

mc12345678:

The arguments are provided by a successful match of the uri to the database record.

Agreed - but the only calls I get for getURIMappingsResultset() are from the header links and the search box. I don't get one for the main page content.
The calls I get a arising from link creation (login link, home link, footer link, etc.) not for determining what to show on the page.

$ceon_uri_mapping_canonical_uri seems to never get set.

*** Update: UGH this is because of a check in includes/classes/class.CeonURIMappingHandlerBase.php.

    if ($PHP_SELF != (DIR_WS_CATALOG . 'index.php')) {
      return;
    }

OK here's the fix:

• in includes/configure.php, use DIR_WS_CATALOG for the folder name. Don't append the folder name to HTTP_SERVER.
• in .htaccess, you want these changes vs what's recommended in admin:

At the top:

Options +FollowSymLinks -MultiViews

DirectoryIndex index.php
RewriteEngine On
RewriteBase /mysite/

At the bottom:

RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.+) index.php [QSA,L]

PLUS you need MC's suggestion about prepending /mysite to the uris in the table ceon_uri_mappings

I have always had my ZC in a subdirectory. For each/multiple installations, a corresponding block of rewrite code is required in the root .htaccess.
And, the table ceon_uri_mappings uses the subdirectory as part of the path, so you would need to regenerate the urls if the additional shop is not in the same-named directory (on a dev server) as the production site.

swguy:

OK here's the fix:

• in includes/configure.php, use DIR_WS_CATALOG for the folder name. Don't append the folder name to HTTP_SERVER.
• in .htaccess, you want these changes vs what's recommended in admin:

At the top:

Options +FollowSymLinks -MultiViews

DirectoryIndex index.php
RewriteEngine On
RewriteBase /mysite/

At the bottom:

RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.+) index.php [QSA,L]

PLUS you need MC's suggestion about prepending /yourstore to the uris in the table ceon_uri_mappings
I agree with everything except the "necessity" of the revised htaccess to check for the presence file and folder requests.

When HTTP_SERVER contains, as it should, just the server and DIR_WS_CATALOG contains the sub-directory as also is expected I have had success with the provided htaccess in a sub-directory provided that sub-directory didn't also have an htaccess file. If it did, I had to reiterate the rules in that sub-directory based on the server's configuration.

The recommended file/folder check adds additional processing to the process of searching the filesystem as compared to evaluating the provided uri to eliminate those things that are of known concern. Yes, the above recommended revision is more flexible in that the htaccess need not be revisited for future modifications, but at a page-by-page cost and allowance of alternate content to be stored in the file system matching an existing request that would otherwise be handled by index.php.

torvista:

...
And, the table ceon_uri_mappings uses the subdirectory as part of the path, so you would need to regenerate the urls if the additional shop is not in the same-named directory (on a dev server) as the production site.

Wasn't there going to be a mod that did the regeneration? I can't recall what exactly happened with this.

swguy:

Wasn't there going to be a mod that did the regeneration? I can't recall what exactly happened with this.
I thought I saw something recently that the commercial mod that supports generation/regeneration of uris was again available at ceon.net.

I also have something that couples with EP4 to do a sort of intermediate rewrite.

There you go. I knew they were working on it for a long time but it kept getting delayed and I lost track.

For those looking for details:
https://ceon.net/seo-modules/ceon-uri-mapping-manager

Oddly enough too, Ceon's own site has the "lingering zenid" problem that is one of the issues with this mod. :(

I was hoping to avoid changing the ceon_uri_mappings by programatically injecting '/mysite' as a prefix for uri during the query in getURIMappingsResultset() but no joy. Has anyone done this? I was thinking

    if (is_array($columns_to_retrieve)) {
       for ($i = 0; $i < sizeof($columns_to_retrieve); $i++) {
         if ($columns_to_retrieve[$i] == "uri") {
            $columns_to_retrieve[$i] = "concat('/mysite',uri) as uri";
         }
       }
    } else {
      if ($columns_to_retrieve == "uri") {
        $columns_to_retrieve = "concat('/mysite',uri) as uri";
      }
    }

swguy:

Oddly enough too, Ceon's own site has the "lingering zenid" problem that is one of the issues with this mod. :(
I don't know what their configuration is, but I found that php version played a significant factor and it had nothing to do with the mod's presence nor absence. It just wouldn't go away properly...

swguy:

I was hoping to avoid changing the ceon_uri_mappings by programatically injecting '/mysite' as a prefix for uri during the query in getURIMappingsResultset() but no joy. Has anyone done this? I was thinking

if (is_array($columns_to_retrieve)) {
   for ($i = 0; $i < sizeof($columns_to_retrieve); $i++) {
     if ($columns_to_retrieve[$i] == "uri") {
        $columns_to_retrieve[$i] = "concat('/mysite',uri) as uri";
     }
   }
} else {
  if ($columns_to_retrieve == "uri") {
    $columns_to_retrieve = "concat('/mysite',uri) as uri";
  }
}

I haven't tried it, but I think that's only half of the solution... remember to get the data associated with a uri, the database has to be searched on the uri...

If perhaps you tried to reach a destination using your edit and the native uri, perhaps it would come back as expected, but that's a separate search... and even then, would you want to prepend the attempted search with the sub-folder a second time if the existing uri already had that sub-folder?

mc12345678:

I haven't tried it, but I think that's only half of the solution... remember to get the data associated with a uri, the database has to be searched on the uri...
LOL yes you're right. Here's the rest:

    // Remove from selections
    foreach ($selections as $key => &$sel_value) {
         if ($key == "uri") {
            $sel_value = str_replace("/yourstore", '', $sel_value);
         }
    }

OK all in one place for those who wish to copy & paste:

below the global $db in getURIMappingsResultset() in includes/classes/class.CeonURIMappingDBLookup.php add:

    if (DIR_WS_CATALOG != "/") { 
       // Add prefix to data
       $prefix = DIR_WS_CATALOG; 
       $prefix = rtrim($prefix, '/');
   		if (is_array($columns_to_retrieve)) {
          for ($i = 0; $i < sizeof($columns_to_retrieve); $i++) {
            if ($columns_to_retrieve[$i] == "uri") {
               $columns_to_retrieve[$i] = "concat('" . $prefix . "',uri) as uri";
            }
          }
   	  } else {
         if ($columns_to_retrieve == "uri") {
           $columns_to_retrieve = "concat('" . $prefix . "',uri) as uri";
         }
       }
       // Remove from selections
       foreach ($selections as $key => &$sel_value) { 
            if ($key == "uri") {
               $sel_value = str_replace($prefix, '', $sel_value); 
            }
       }
    }