We have noticed that the shopping cart banners seem to frequently loose the link to the related promotion without anyone making this change within admin. Is there a setting that only allows a certain number of customers to see this banner and then it would be removed? I can’t think of another reason it might just drop the link. It isn’t dropping all the links, and it has usually been the lower value ones.
You need to setup cron.php to be accessed in a cronjob. Verify by hitting cron.php manually and see if that resolves your issue.
Related
I have a site, 1.5 magento, and the cart functionality (and the customer account functionality) seem to be disabled. When i attempt to go to the url 'checkout/cart', just the homepage displays.
Ive checked all the usual suspects..including:
checked the url_rewrites table (there is one entry in their referencing checkout/cart...but goes from checkout/cart to checkout/cart, so dont see this is an issue, but did edit it just to rule it out)
enabling/disabling of the module itself, looking at both the etc/modules files and removing, and checking the module listing in system->config->advanced area.
trying to step through the code..try detect where the change over of pagedata occurs - struggling here.
looking for certain terms in the codebase...and database SQL file.
the htaccess file, looking for a rewrite
local/community modules..and any rewriting of the checkout
Im starting to think a hack is in place here to show the homepage when visiting checkout url. The url : www.mysite.co.uk/checkout/cart remains in the address bar, but i see homepage data.
Anyone know where else i can check...or easily locate the cause of this issue?
Many thanks
S
Did you look in backend under Configuration -> Sales -> Checkout ?
There is a field called "Enable One-Page Checkout" which has to be enabled. If you disable it, your store will just run fine but neither registered customers nor guests can check out anymore.
Turns out this was rewrites added to the rewrite table manually. Didnt find them at first.
John goes to bestwidgets.com and puts 5 red widgets in his cart, logs in then decides not to purchase red widgets and logs out.
John comes back the following day (to the same machine) and decides what he needs are blue widgets. He adds 5 blue widgets to his cart and proceeds to checkout. He then logs in and keeps on trucking thru the one page checkout. Only AFTER he finishes his purchase he realizes that 5 red widgets got automatically added to his cart (when he logged in, though most people wont even realize that).
John now thinks bestwidgets.com are crooks, cancels his order and never comes back.
Am I missing something here or is this magento’s default behavior!??
Magento Community 1.5.1.0
This is the default behavior in Magento, but this has nothing to do with the "Persistent Shopping" feature but with "Quote Life Time". As usual with Magento we left the decision how the store should work to the merchants running the store as they know their market best and what is the best way to configure their store. If you go to System->Configurations under Sales->Checkout in the Shopping Cart tab you should be able to set the number of days the quote (or shopping cart) is remembered (Quote Lifetime (days)). Setting it to 0 should not remember the cart between each login of the customer.
If your using Enterprise: Enterprise_Persistent and/or Community Mage_Persistent disable them via app/etc/modules in the corresponding XML to disable this functionality if your worried about customers not realizing their previous added products are in their cart during checkout.
Am I missing something here or is this magento’s default behavior!??
Yes it is Magento's default behavior. I get your opinion about the crookishness feeling on this, however, I believe most would say it's to help the customers remember what they were looking at and help them spend money. Subtle difference...
I have installed full release Magento on localhost from http://www.magentocommerce.com/download. Before doing installation I have created a database and import Magento sample database (downloaded from Magento site).
After that continue installation process. When I checked fronted its shows Best Selling Products when I clicked any of the product it gives error given below:
Whoops, our bad...
The page you requested was not found, and we have a fine guess why.
* If you typed the URL directly, please make sure the spelling is correct.
* If you clicked on a link to get here, the link is outdated.
What can you do?
Have no fear, help is near! There are many ways you can get back on track with Magento Demo Store.
* Go back to the previous page.
* Use the search bar at the top of the page to search for your products.
* Follow these links to get you back on track!
Store Home
My Account
I am new to Magento.
I've experienced this too. In the admin go to System > Index Management and rebuild the various catalog indexes, especially the URL rewrites.
This is because the sample data doesn't have it's paths stored to begin with, it needs to be calculated, and the Best Selling Products section doesn't read the actual paths in use, instead it is a Static CMS Block with it's HREFs fixed. This will probably never occur for products you enter yourself so it's nothing to worry about.
I had the same problem in Wamp. I had my folder named Magento, renaming it to magento, fixed the problem. (Lower case)
I had a similar issue, I was transferring Magento from a Unix server to a Windows server. My issue was to do with links looking like this (not working)
http://www.magentoshop.com.au/shop/product01.html
instead of
http://www.magentoshop.com.au/shop/index.php/product01.html
Haven't worked out how to fix all links yet, but just adding it tells me where the issue lies. Hope it helps someone else.
I've imported 6K categories and 16K products to magento using a custom import profile.
When I'm trying to reindex everything works except for 'Catalog URL Rewrites' that keep showing PROCESSING but never completes.
log and exceptions files don't show anything.
Is there something I can do to make the index work?
Can I just ignore this index and not use it? (I don't know what it does).
Thanks
You can sort of ignore this index if you do not care about pretty, search engine "friendly" URL's. The products will still appear in the catalog but will have their default "Zend Framework" type URL (/catalog/product/view/id/123)
My store has 150,000+ SKUs in two store views. On my development environment it took almost two weeks to complete.
The best way to determine how fast it is running is to look at the core_url_rewrite database table. It appears that the process starts at product ID 1 in store ID 1 and looks to make sure all of its URLs exist and creates the ones that do not yet exist.
For me the reason it took so long was that it had to go through my entire catalog twice to make all the URLs. One thing I did notice was that this process creates a ton of URLs that are completely unnecessary. In our store easily 90% of our products belong to a configurable product so their visibility is set to "Not Visible Individually" so they never would need to have a URL. This index creates those URLs anyways.
Hopefully this will shed some light on to how this URL works. I would keep an eye on that database table so you sorta know how far the process has come. I would also seriously consider running the reindex process for the command line. I have included a link that explains how to do this (disclosure: it's from my blog)
http://overlycaffeinated.com/2011/02/when-reindexing-in-magento-fails-use-the-command-line/
My own attempt of reindexing URL rewrites was with 10,000 products and it took me like an Hour and Half to finish up.
this link will help you do it from Command Line , which is preferable than doing it from the same Magento admin panel.
http://www.yireo.com/tutorials/magento/magento-administration/340-magento-14-cronjobs
Make sure you read the part about skipping some basic configuration when facing memory limits , this is the one i usually use.
You need catalog URL rewrites to make your catalog work properly. How long are you letting it run for? There's a really substantial amount of data to be written to it...
If you cannot make it work programmatically, it may be possible to shove the data into the table manually and force the index to feel refreshed? Caveat emptor, I have not tried this.
I was encountering the same problem, the server that I am running this on is a FreeBSD server. With the help of the sample of the above code I was able to get the issue to resolve buy running the following command in the shell.
/usr/local/bin/php /usr/local/www/magento/shell/indexer.php --reindex catalog_url
It runs very quickly and resolved my issue. I then created a cron for this to run every 6 hours on my server.
You can reindex using command line it will reduce 75% of load and your magento admin panel working as normal while reindexing.
I am having a weird situation. I worked on a magneto ecommerce website. My friends and I can see the products on the website, but only my client can't see any of them.
I suspected magento cache, so I refreshed and disabled all the caches. My client still can't see all the products. I made him to clear browser cache. It didn't work as well. I also let him use FF or Safari. He still can't see the products.
What is the problem??? I can't try any other things now...
In addition to checking multiple websites, are you logged in or do you have a specific customer group? Magento allows you to show products only to certain customers. Check to make sure that as a logged-out, anonymous user, you can see the products.
Hope that helps,
Joe
Have you configured multiple stores, websites or store views in your Magento instance? Whether or not Magento displays a product depends on a lot of settings, but if one user can, and another user cannot see them, it's most likely related to which store view they are accessing.
The store view Magento is showing isn't always determined by the URL alone, there is also a setting which is stored in the cookie and can be changed via a dropdown (in the default templates anyway).
Stores are configured via System > Manage Stores. If you have multiple rows in there you have multiple store views (or websites or stores).