Running CEON URI Mapping in a subfolder

[swguy]

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

[mc12345678]

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.

[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?

[mc12345678]

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.

[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,

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.

[mc12345678]

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.

[swguy]

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.

[swguy]

$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;
    }

[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 /mysite to the uris in the table ceon_uri_mappings

[torvista]

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.