Running CEON URI Mapping in a subfolder

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

[mc12345678]

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.