I have Magento site running with 20000 plus products. Sometimes it does not show the products in the frontend. It says "There are no products matching the selection", but the products are still there in the backend site.
I know I have to run re-indexing process, and whenever I complete the re-indexing process all products are there in the frontend.
So now, my question is: Why this is happening again and again? This is now fourth time I faced this problem. I want to know the real causes of this issue. I am very afraid.
Thanks
The two most likely cuplrits are caching and indexing problems (unless of course you are using a clustered database, in which case that is probably the culprit). If it's feasible on your site (or on a dev environment, which I am sure you had the foresight to create), disable Magento's caching temporarily and see if that alleviates the issue. Also try disabling the flat_catalog settings to see if that is having an effect.
Also make sure that your browser cache is set to always refresh from the server.
Hope that helps!
Thanks,
Joe
It sounds like you need to setup your cronjobs to re-run the indexes. Certainly with prices, the custom price indexes are only valid for a set period of time, then the cronjob extends those periods if the Catalog Price Rule is still active.
Here is a wiki post on the process of setting up your cronjobs.
Note that cron itself can cause problems, so as Joseph suggests, make sure you have a dev and staging environment setup that mirrors production so that you can check the configuration.
Related
I'm a bit of an amateur so I'm sure I've missed something.
I'm running Divi on Wordpress. When i go to update a page, I get the "Your updates couldn't be saved" error. My Wordpress site, as well as it's CPanel, also are loading unusually slowly, which I think is related to the issue. After working on this for a bit, both my site and it's CPanel will fail to load, giving me a "can't establish a secure connection to the server" error. The third symptom, which I can't make heads nor tails of, when I click "update" in the page editor, my browser will often (but not always) launch another tab/pop-up either displaying a preview of the edits or the "pages" page on the WP admin side. All of these issues are new (although I've had similar loading speed issues in the past with this site).
Thinking it may be an overload on my server (which happened due to an attack a few months ago), I let it sit for a few days with no luck. Then, thinking it may be a caching issue on my end, I changed my DNS servers, cleared my browser cache, tried private browsing, used my phone, used different wifi and cellular networks. All to no avail. I briefly had slight luck using my phone as a hotspot, but it only temporarily improved the loading speeds.
I also tried disabling plugins. I made sure everything was up to date. No help.
I went into my wp-config.php file and increased the memory limit to 128M and the WP-max memory limit to 256M. This helped briefly–I could update and save one page but when I tried to change the next, I was back to base 1. I've also increased the memory limits in my .htaccess file. I don't have access to my PHP.init file (there are often delays reaching my host so I'm trying to avoid relying on them when possible).
My last guess (which I have yet to implement) is to update my PHP. That said, I'm running 7.3.6 and had no issue updating the site a few days ago so I'm not sure that's the problem, unless divi's newest update has compatibility issues with 7.3 versions of PHP...
Any further ideas would be greatly appreciated! I'm partway through a cosmetic update (which, I know should be done on a staging site but sometimes best practices are best learnt through mistakes like this) so my site looks somewhat half-finished. That is, I'm anxious to be able to edit it again.
Many thanks in advance
Whenever you try to save something, Divi will make a request through admin-ajax.php, it often happens that a security firewall detects that as a threat (which is obviously not), thus giving you the failed save message. Can you ask you host to check the rules that are triggered and whitelist that action? It can also come from plugins like Wordfence, make sure to whitelist it there too.
You can also attach that layout as JSON here, I can test it on my own server and if I can save changes, we should be on the right path.
I have a website (wordpress) published and it works perfectly, but from time to time it gets stuck. You try to enter the page and the server is like blocked, processing, and then for some minutes the website doesn't load.
I even added a cache system and performance optimizations, and the website is much faster now, but that keeps happening, from time to time (several times per day) the web is white, blank, loading for a long time.
I don't know what it is: a plugin? my code? it doesn't happen at a specific moment or action. So I can't identify when or where or why it happens.
So, can I somehow log the php code to know what is being executed at that moment? Where is the code stuck?
BTW, I already disabled the wp-cron. That's not it. And the web is huge so I can't start looking into every file for a loop or something, I need something faster.
I recommend checking on some query monitor which plugins / themes are responsible for the bottleneck. You can use GoDaddy's P3 Profiler plugin, which although it is not having updates, remains one of the best options for profiling a WordPress.
If you use cPanel, check the resource usage and try to identify patterns. For example, is the site slow at a specific time? On specific days of the week?
If you have access to Awstats or similar, you can check if there is any bot that accesses your site at some specific time.
If you treat only the symptom (slowness) you will continue to have the same problem. You need to find the source and then solve it at once.
Also check the access logs for detecting anomalies:
https://www.tecmint.com/find-top-ip-address-accessing-apache-web-server/
Looking on Google, I found some services that I think can help:
https://goupcloud.com [complete optimization and identification of bottlenecks (treatment in the cause and not symptom)]
https://www.wpfaster.org/ [full optimization]
https://www.wpspeedfix.com/ [full optimization]
We have Magento EE 1.14.0.1. recently we moved to new AWS EC2 server and ElasticCache Redis server. then some random products start disappearing in the frontend. They exist on backend and configured correctly ( visible , enabled , in stock , etc .... ). And only after you save the product in backend it will show up again in frontend even without flushing any cache.
Is this issue related to Redis cache ?
and if its how to fix it ?
Any input would be appreciated to direct me to a solution.
Thanks
Update: I marked everything under Index Management to Update on Save. so I revert that back to update on schedule. and I think that fixed the issue. but still I want to keep my store inventory up to date.
"It's an index issue, every time you update data (product, stock) from database, you have to manually re-index Magento."
That is true for Community Edition, not Enterprise Edition. In addition, there can be some extra issues when migrating to AWS. After 4 months of troubleshooting on an inherited server migrated into AWS I found a number of issues/solutions.
EE issues
Enterprise Edition indexing is asynchronous for many of the indexes. In addition, not all EE indexes are configured in the typical place.
On the Admin menu, select System > Configuration. In the panel on the left, under Advanced, select Index Management.
http://docs.magento.com/m1/ee/user_guide/system-operations/index-configuration.html
Even when set to "update on save" in my experience it frequently does not update on save.
AsyncIndexing was unstable in versions prior to 1.14.3.x .
Upgrade! It was possible for the partial process to break in such a way as to make it impossible for indexing to proceed. One way this will occur is if you are running PHP for the website[typically via PHPFPM] with a different userid and group then you run the cronjobs[shell access]. Indexing depends on the creation of a file to 'lock' the process - the file may only be written/deleted by the user which creates it.
I have found that for performance reasons, it is best to set ALL indexes to "update manually". Do not schedule a periodic reindex all process, it is useless due to async indexing. Just make sure your cron is running and everything should be fine.
The AsyncIndex process uses MySQL triggers...which have an issue when trying to migrate a magento database from one server to another. The way they are created initially, they can ONLY be used by the database user that when the triggers where first created. If you change the database user for the new server, the triggers will not migrate. Even worse, there is almost no indication that this occurred and everything except indexing runs perfectly so how can you tell?
Lastly, "reindex all" does not always reindex all. Thanks to various posts on the internet, I created a shell script to make Magento think all the products were updated and the index needs to be rebuilt:
https://gist.github.com/gamort/5dc5e16bdec00a8bb3b922fc463af17c
AWS issues
Using AWS Elasticache Redis has a hidden gotcha - the default zone it is launched in may be different then your server zone. In my case, the server was in USEAST-1a while Redis defaulted to USEAST-1b. This resulted in occasional timeouts when looking up data from the cache. While the website code can usually recover, the indexing code does not. This leads to the index cron process being in a broken state.
Almost as importantly, you will pay a trivial amount per GB for data transfer from zone 1a to 1b. But when your cache is working, this "trivial" amount can amount to a lot! We had a recurring $10+/day [$500-$600 a month] intrazone data transfer fee! Launch a new redis server in your actual zone, use the redis cli on your web server to make sure you can connect[we had firewall configuration issues] and then only THEN update your configuration.
AWS RDS server also have a hidden gotcha[hope your not too overwhelmed yet]. Migrating the database from another server to Amazon RDS has issues where there was an extremely slight change in what MySQL considers valid SQL for a specific function...which Magento EE just happens to use. :-) . I ended up installing a new copy of Magento EE and using Navicat to sync the database structures.
Solr issues
Suffice to say, there are Solr issues as well. Mostly due to the schema, but I also found that wiping the solr database and letting it reindex helped.
Magento Rewrite/Form issues
This issue occurs when you upgrade to 1.14.3 - which of course you should do since it fixes so many indexing issues. Version 1.14.3.x added form keys to a number of forms, including the customer sign up form. So if you created your own custom phtml templates for the logon they will not work! You need to add that form key field to your customization. Not a big deal though, since you documented what template file you copied it from initially right?
All in all, I would estimate going through the checklist for migration to be a good 20 hours, and possibly up to 80 depending on what issues you run into. And at the end of the day, since the fixes are mainly in cron jobs which are not easily visible the website owner will be hard pressed to tell how they benefitted from all that work. In my case, disappearing products had already been an issue for over a year before we inherited the site the client was understanding about the difficulties.
It's an index issue, every time you update data (product, stock) from database, you have to manually re-index Magento. If you don't do that, you'll have corrupted data on index and you'll lose SQL join on product request list.
We have Magento running on an eCommerce website an the last few days it seems that some really important pages are simply not loading!
Majority of the pageson the site load fine however if a user is "logged in" and they try to access the cart checkout page, by far the most important page, they receive this very nasty message shown below in the image...
As far as I know, no changes to code have been made the last few days so I do not even know where to look at this point for a solution.
A Google search shows that many people had had this problem before, mostly on WOrdPress sites but there never is a solution posted!
I am hoping someone can point us in the right direction as this is a major problem on this site right now if a user cannot checkout.
The other page that i noticed it is happening on is the page to create a new user account, once you fill the form out and hit submit, it shows the page shown in image as well.
We are running Apache on Ubuntu 12 believe. We also have Varnish Cache if that means anything.
Please help!
Also here is what I get for the same page in FireFox...
As mentioned by others, try flushing the APC Opcode cache.
You can do that by adding the following lines to your magento/index.php right at the top of the file to clear the cache
apc_clear_cache();
apc_clear_cache('user');
WARNING
As one cause of the problem can be a corrupted Opcode cache you should only use this once (add the code, then call the page) and comment it out afterwards, otherwise you won't have any performance improvements by the APC, maybe even a degrading performance as the cache will be filled with every page call.
So, add the code, call the page, then comment the code out. (if it didn't work, comment it out and search for another solution, DON'T leave the code in the index.php)
If you Google for this problem, you will find 100 different answers as it seems many different things can cause this error.
We got ours fixed now and our problem was corruption in PHP's APC Cache.
Flushing APC Cache solved all our problems, perhaps this will help someone someday, it;s another of the 100 things to check!
Clearing the APC Opcode cache resolved this error for me
Experiencing an issue with an Ubercart 2 store that is now running on nginx.
Authenticated users can checkout and order products without an issue.
Anonymous users can put items in the cart, and when they hit the Review Order page, all the information is cleared out.
Boost is also enabled but ignoring the Store section of the website. Memcache is also enabled. SecurePages is directing users to secure connection as soon as any store page is visited.
Any ideas on why this is happening? Everything worked fine until we implemented nginx and reverse proxies for the website to handle additional traffic. No Drupal configuration has changed.
Which version of Ubercart are you using? There is an issue with the current version. I actually created a patch for it, but there are a few issues.
Here is the one I made... http://drupal.org/node/862348
It later got merged into this one... http://drupal.org/node/858816
It's still up for debate, but one thing you can try (if you can) is to rollback to the version right before the current one, as the current one is the one that broke.