As we all really know, there appears a little problem with Magento 1.8.x and Varnish. Magento team added the support "form_key" for the most the frontend forms and actions. It is really great, everyone should keep safety first. However it causes a problem with FPC systems as Varnish (great article about this is here http://www.supportdesk.nu/blog/110-magento-1-8-form-keys-impact-on-fpc). Many FPC systems on Magento solves it by putting a placeholder and replace "form_key" during loading a page from cache. It's good for PHP systems that are integrated into Magento , but not for external systems as Varnish. So my question is as follows:
Is there a good enough solution for using FPC as Varnish and Magento 1.8.x?
I consider follows
1) prevent using of the "form_key" on frontend, there are many way to do this (e.g: https://bitbucket.org/supportdesk_nl/turpertine-formkey-workaround/src/574ff1851618dc0e76e4274001fbf3efb89c99f6/app/code/community/SupportDesk/CartFormKey/Model/Observer.php?at=master). However this is hack and is not good generaly. Moreover could be a security risk? What do you mean about this?
2) load the "form_key" via AJAX and replace all links and form inputs by JavaScript code. I'm not sure that it is technicaly realizable (e.g: replacing code snippets like onclick="setLocation('....&form_key=XXX');" would be too difficult) and it will causes too many problems and incompatibilities with various extensions.
3) do not use Varnish. Yes it would be a solution, but let's avoid them for now, please.
4) Your suggestions ???
Many thanks for your answers.
Which FPC are you trying to use anyway? We use Lesti FPC (with Redis Cache backends, and session backends) with Varnish and it works fine.
I don't know if you've properly read one of the links you posted, but Lesti FPC is already patched via this commit, 5 months ago.
Related
I installed Sylius on XAMPP (localhost) and pages load very slowly.
I don't know where I can find configuration to solve my problem.
Please help
It will be probably just you environment settings, as well as in this question https://stackoverflow.com/a/17474117/1984346
Try using it with app.dev instead of app_dev.php for a quick check
If it will help, you got you culprit and follow the answers and links bellow.
why is it slow: quote from above answer:
you are by default installing using the config_dev.yml .... When debug is on "cache files are dynamically rebuilt on
each request." This is what is causing the slow speed.
For more information about enviroments: http://symfony.com/doc/current/cookbook/configuration/environments.html
This is a common issue for projects base on symfony framework, sylius out from the box don't take care about the performance.
First is follow the https://symfony.com/doc/3.3/performance.html
Next, more complex is using the Varnish proxy cache.
Also, use elastic search for the catalog, product view pages.
Last one is get rid from the coupled frontend part, but use only API side, where fronted build on top of Angular, React or Vue js frameworks.
difference between create an api using magento
standards and create a php file in the root and
get and send response using simple php code.
is there any security reason we use magento standards ?
any difference in speed of response ?
is there any security reason we use magento standards ?
The standard Magento APIs have been tested significantly more than anything that has yet to be written, so, yes, in terms of security, it's better to avoid writing something custom.
any difference in speed of response ?
Yes, Magento's SOAP APIs are terribly slow. Haven't done much testing with the newer REST API, so I'm not sure if that's any faster.
A third, somewhat obvious, point is that Magento's APIs are already written and can be used on any site out of the box (with minimal configuration). Writing a custom API means that it has to be installed on the site before it can be used.
Also, thinking outside of the box, sometimes it's beneficial to reverse the process. Instead of Foo talking to Magento, let Magento talk to Foo. Of course, this depends on what you're doing, but sometimes this is a much better way of implementing a form of communication between Magento and another system.
I have a lot of experience with YUI2 and I'm getting up to speed on YUI3. The service I'm writing needs HTTPS, but the vanilla YUI experience loads from Yahoo's HTTP-only CDN, which quietly fails in Chrome and loudly fails in modern IE when the browser tries to mix an HTTPS page with HTTP javascript.
My goals are to get all of:
Site uses HTTPS
YUI works in Chrome & IE (so scripts also must be delivered over SSL)
Uses a modern version of YUI 3 (this disqualifies YUI PHP Loader which hasn't been updated to support even YUI 3.4, while 3.8 is "current")
Use roll up combos for speed instead of many JS and CSS files (this disqualifies Google's CDN... if YUI 3 is actually hosted there which I couldn't find.)
Site dynamically loads YUI dependencies (dependencies change regularly as I add functionality, going back to the configurator and saving a new bundle every time is a PITA)
The obvious solution appears to be to give up goal #5 and just self-host combos.
How can I meet all 5 goals?
The easiest way to solve it is to change base URL from
http://yui.yahooapis.com/ to
https://yui-s.yahooapis.com/
Depending upon your server environment, you have a couple of options.
Development
Download the latest YUI library, and upload the yui/build/ folder to your server. The seed file should work fine without modification, though you won't be able to take advantage of combo loading.
Production
Use the YUI Configurator to determine all the files that you will need for each module set, and download them manually from the combo links provided. Rename them to something suitable like yui3.8.0-node-rollup.js and serve these to your users.
Be advised that if you use different module sets for different scripts, you may need to make multiple sets of files from this process, depending upon how you set it up. There is also a question here about concatenating Javascript together, if you are curious.
As an addendum, in my past research, I discovered that pulling external libraries over a secure connection may not be a safe idea.
I have a Magento site using version 1.6.2.0 with which I'm experiencing problems with duplicate orders.
Having researched the subject I have found mostly forum threads explaining that 1.4.x had problems with duplicate orders and the solutions mentioned (even those on SO which I have found) merely suggest the user updates Magento to >1.4.
I have also found a proposed solution here but am reluctant to delete observers which will prevent downloadable purchases working.
I've also spotted the Array Of Death fix mentioned a few times (e.g. here) but this problem isn't present in 1.6.x, Zend appears to have resolved it.
There are a couple of Javascript hacks suggested whereby the Confirm Order button is hidden upon submission but Magento 1.6.x already does this.
I have increased the payment gateway timeout configuration variable to 120 seconds and am as yet to see if it yields results. I can't test it as the problem is intermittent (and probably therefore caused by communication or lack thereof between the payment gateway and Magento).
I am using Sagepay as the payment gateway.
How might I further debug this?
The link you posted is correct, but I wouldn't use their fix, I would just disable the Mage_Rss module.
Mage_Rss has several observers in it that call Mage::app()->cleanCache(...) in the checkout process, which is extremely expensive if your installation is using the default filesystem cache and it's gotten large.
I found the best thing for troubleshooting Magento performance problems is to wire up Xhgui and do some profiling. Reading call stacks will help your understanding of Magento immensely also.
Oh, and I don't know if this is true for Sagepay, but I went and fixed this problem completely for PayflowPro by rewriting the method that generates transaction IDs to use the quoteID instead of generating unique IDs on every invocation. I started down the path of committing this back, but I'm on 1.4.2 still and don't have time to test in later versions and it's a pretty significant rewrite. Guess I could just put it out there for someone else to run pass Moses...
I have a website that uses CakePHP 1.3.10. This CakePHP app it's pretty big, not in the amount of models or controllers (like 5 of each), but in the amount of plugins. I use the plugins as places of the website where users can access (or can't access) depending on if they have logged in already or not (well there's more reasons, but it's not important now, it's how it works). I also use a global Auth component in the app_controller.php
My issue is the following: I've noticed that the website is getting really slow when trying to access any of the pages of a plugin (when accessing the "home" page - which is not in a plugin - all is good).
The thing is that I was going to run some performance tests to figure out what's going on. I decided to create another website, exactly like the one I described, with the only difference that I removed all the plugins with the exception of one.
Amazingly (for me), when I access one of the pages of this plugin that I didn't delete, it goes super fast, like it should normally go.
So my question is: does the number of plugins really have a direct impact on the loading times of a page inside those plugins? Is there any way to "fix" this? Or is it just a coincidence and something else is going on that I missed?
Thanks so much in advance for any advise!
Reducing the amount of files and folders of my application has increased significantly the load times. I don't know what is the relation between amount of files/folders and loading speed in CakePHP, but it's a fact, at least in my website.
I've changed my cake installation to an advanced installation (as it explains in the cakephp boo) to have my files more spread out in different sub-apps, instead of having one huge app, and this has helped a lot!