We have a problem in that modrewrite only works until the product page and then we get a blank screen when clicking on the product. See for yourself at www.kwabble.com. Any help would be appreciated. Thanks.
Hi,
Just following up this query by email; the first question is to confirm that everything works without the .htaccess in place.
If there is a product index being displayed then registration will have completed OK; this does look like a specific .htaccess problem.
Let me know if the normal product search works OK; and i'll get looking into why the product page doesn't work under rewrite rules!
Cheers,
David.
Hi
I have the same problem.
Products are displayed at the search page but pages are blank at de products pages. So it must be a problem on de products page ore .htaccess?
Greets,
arno
Hi Arno,
Can you let me know version of Apache you are running, and what version of PHP....
Thanks,
David.
Voila
Apache/1.3.33 (Unix) mod_ssl/2.8.22 OpenSSL/0.9.7d PHP/4.3.11 mod_perl/1.29
Having just installed this it would appear that this occurs with any .htaccess file installed - is there a section in the script which says the equivalent of "if there is an htaccess present, display links as mod rewrite links"??
Have had to delete alternative .htaccess (which only set the 404 page) for the script to work again.
V. rushed for time, but would also love to see the following:
1. The ability to set "Merchant Name" from a single feed - this would allow the import of combined feeds (e.g. Affiliate Window feeds containing several merchants) meaning the process would be much quicker
2. The ability to import a feed from a URL
3. Several other things, but must dash to pick up the daughter!
Hi madstock,
Yes - the script does check for .htaccess and use search engine friendly ULRs if it exists. Perhaps a better idea would be to make this a config setting. The only thing I am worried about there is people turning on search engine friendly URLs without making the necessary changes to .htaccess. I'll have a think about this.
> The ability to import a feed from a URL
This is high on the "to-do" list. I'm going to write a module to retreive a feed from a URL and do any unzipping, unrar'ing etc. as necessary.
Would somebody that is having the product page rewrite problem be prepared to let me login to their server for a few minutes to try and solve the problem?
I can't recreate the problem on any of my servers, but if I can work on a box where the problem does occur I can probably figure out the cause in a few minutes.
I would need to be able to:
i) Login via SSH or Telnet (I would suggest that you change your password temporarily)
ii) Edit .htaccess using vi
iii) Edit product.php using vi
Do not post any server address or access details to the forum!
If you're happy for me to do this could you drop me an email by reply to your Magic Parser registration code email and i'll see if I can sort it....!
Thanks,
David.
Many thanks to Arnu, I have been able to work out the solution to this problem by logging in to his server.
What is happening, is that either something specific to Apache 1.3, or a configuration option set by your web hosting company; is automatically serving foo.php for a request for /foo or even /foo/. Because the rewrite rule for the product page (product.php) is based on /product/, web servers using this particular configuration will never execute the rewrite rule.
At first, I thought this might be mod_spelling; but i've checked the docs for that module and it doesn't seem to automatically look for missed out .php extensions.
Anyway the fix is to rename product.php to something else, and then edit .htaccess to use the new filename for product.php. For example, if you rename product.php to productpage.php; your new .htaccess rule would look like this:
RewriteRule ^product/(.*).html$ productpage.php?q=$1&rewrite=1&%{QUERY_STRING} [L]Note: you must make sure that product.php no longer exists in your Price Tapestry directory; so rename rather than copy the file in order to get it to work.
I will look at updating the distribution to use a new filename for product.php that does not conflict with the base name in the rewrite rule, which should stop other users from having this problem.
On further investigation, it turns out that this problem is caused by having content negotiation enabled in Apache. It can be disabled by adding the following line to .htaccess:
Options -MultiViews
This line is now included in htaccess.txt in the Price Tapestry distribution.
register your products in admin