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.
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.
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.
If i try to login to the backend the site redirects to the login page. No error is shown.
The issue is similar to this post: Prestashop cant login in admin
But none of the solutions helped and are for an earlier version of Prestashop.
The problem seems to be sort of random or with multiple causes.
1) If i clear all the cookies, some times starts to work again, but then start fail again. Other times i clear the cookies and it doesnt help.
2) Some times it fails for http:, but it works for https. Some times it doesnt work for https neither.
3) Some times it works from IE, but not from chrome. Some times neither by IE. Same happens if i try by Chrome private mode.
Previous to this problem:
1) I updated all the modules. (I didnt reverted this becouse it is complicated)
2) i incremented the memory_limit and the max_time_execution in php configuration. (I reverted this but it didnt help)
Also, maybe is related or maybe not, but previous to this problem when i tried to save a product modification some times it didnt save and redirects to product edit page. This is also random, maybe after 2 attemps work, some times after 3 attemps.
As mentioned by PrestaAlba it is related to a bug caused by an update in recent browsers. Getting Rid of Synchronous XHRs, Synchronous ajax requests are now blocked by a majority of browsers.
You then have 3 choices to solve this:
You can download an older version of your browser
You can upgrade to the latest version of Prestashop (as mentioned by PrestaAlba)
You can apply the modification in this Pull Request to your store without having to upgrade Prestashop.
Update to last 1.6 stable Prestashop version. There is a bug related with web browsers updates that it fixed from Prestashop 1.6.10 version on.
Good luck.
I am running a Joomla 1.6 site, which I recently moved to a new server. I moved the site file system using rsync, and I replicated the MySQL database using MySQL utilities. The previous server has running Ubuntu server 10.10 and the new one is Ubuntu Server 11.10. Everything seems to be working correctly, except one thing...
In the site configuration, a user's session is set to expire after 24 hours. On the previous site it had been working correctly. On this new site, I have found that after a user logs in successfully and uses the site for some time, the user is logged out intermittently (randomly?), well before 24 hours, and then upon logging back in to the site (even in the back-end) the site is completely blank. The main menu is not there and there is no content. The logout button still appears, however, and the main banner. If the user logs out and then logs back in, usually all the content appears again like it should, and the site continues to function properly until the next time the session is booted.
Does anybody have any experience with this? Is there a place a can start debugging to find out why the session is ended abruptly? Why can I log in to the site and still not see any content?
I share the same issue. Being logged out, then logging back in and seeing nothing.
It is very random, and will happen 10 times in a row, or never for two weeks.
This happens on a site that's quite complex (plenty of extensions), and has some traffic (5000 hits/day + 100 admin access / day) on J. 1.7
There is obviously something wrong with the session management.
In an attempt to make the site faster we have tweaked the database and moved the session table to memory, and I believe this may be the key aspect here.
Once we had repeated errors happening and clearing the sessions table solved it (until the next day), so I would guess it's connected to the in-memory sessions table.
If your table is in memory, try moving it to disk; if it's not, try emptying it and see if it happens again, and post back! Good luck
More news.
After long debugging the issue was related by an exception in the core which was not properly handled (related to saving an item with a duplicate alias, i.e. saving a second article in the same category with the same title/alias).
For us it was enough to migrate to J 2.5.3 to solve the issue.
Anyway, as a general comment, such behaviour could be related to an error in some Joomla files, which should leave traces in your error_log (else enable error logging).
It took my customer 3 months to understand what they were doing and describe it so finding an error might speed up the diagnostics.
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.