Since about three weeks changes on .phtml files have no effect on our productive magento installation. Therefore the same changes take effect on our test installation which is essentially a copy of it. Changes are made on the test installation. Thereby I'm following the Template Path Hints. Of course we are using our own template like: /app/design/frontend/venedor/mod/ We don't modify core, base or default-files. After everything looks fine the changes are transfered to production. Changes are uploaded successfully and downloading again shows the changes. Have doublechecked the Template Path Hints in production, too. Cache has been cleared about a thousand times.
The same with .php files. But changes in .csv files in /app/design/frontend/venedor/mod/locale/ take effect.
We are running Magento CE 1.9.2.1 on:
Linux 2.6.32-openvz-042stab084.17-amd64 (no root-access, no more information)
nginx 1.9.3
PHP 5.3.27 +PHP-FPM
Google PageSpeed is available but disabled
I have absolutely no clue about this behavior... Maybe some kind of caching effect of nginx or PHP-FPM? Any idea or what kind of information I should add?
Try appending ?abc=def to the url to see if the page changes. If it does then you know it's caching issue. Do you have Varnish cache on your server?
Related
I'm using valet+ and Wordpress 5.9 on a local environment.
I have a simple task of updating some new terms of my payment module.
They are located under wp-content/plugins/my-plugin/languages/my-plugin.* where * represents .pot and -pt_BR.mo and -pt_BR.po files.
Some old terms are still working in the admin, even if I remove everything in this folder and refresh the page. The new terms are not being translated at all.
I already tried to restart valet (php, nginx, etc), and also used wp-cli cache flush command.
Am I missing something here? Or is there any other place to look for translation cache that I am leaving behind?
It turned out that wordpress was loading another file located under wpcontent/languages/plugin/my-plugin.*.
Removing those files solved the problem. No cache cleaning or restart was needed on local environment.
I've been developing a website built on OctoberCMS, using the Laravel Homestead vagrant box as my local development server and have so far been getting along swimmingly. I developed most of a theme this way.
However I've recently started running into a problem wherein requests for assets/vendor.css in the theme assets succeed but receive a text/html response containing HTML for the homepage instead of the proper CSS.
This means vendor CSS for the page doesn't load. However if you repeat the request for vendor.css with "open in new tab" after page load the correct asset is returned, and the Chrome 'sources' tab also shows the correct asset.
This strange behaviour seems to extend to JS assets. I'm currently looking at a request for assets/vendor/jquery.js where the inital response actually contains the contents of assets/theme.css - and this is causing JS errors in the console.
In this case however if I make the request to that URL again I actually still receive the same incorrect CSS, but once again the Chrome 'sources' tab actually shows the correct asset.
Inspecting the files in my code editor I see the correct assets under the correct filenames and locations.
It seems I might have an issue with Homestead's web server. However I'm confused about where it might have come from as I haven't reconfigured anything and this has been working fine previously.
I've confirmed that the problem still persists even after deleting the homestead VM, and then building a brand new one and installing a fresh copy of OctoberCMS, without importing any of my own custom theme files.
I tried having a look into the nginx logs on the VM to see if I could spot anything odd, but it looks like they all have no content, 0 lines.
I'm a bit stumped and haven't found much helpful searching around.
Any suggestions? Help much appreciated.
So I've managed to re-build my project in such a way that this time I didn't reproduce the problem.
I'm pretty sure that ultimately it was caused by the fact that I relocated the homestead VM (and projects therein) by renaming its containing folder.
In previous attempts I had been deleting the VM by running vagrant destroy and then re-creating it by running vagrant up.
Once I completely deleted the homestead repository and re-cloned it from scratch from laravel/homstead on github, then proceeeded to vagrant up and set up OctoberCMS, I no longer experienced the issue.
I suspect perhaps the original path to my VM (before rename) was still in a configuration file somewhere in the laravel/homestead project and the disconnect between this value and the actual filepath was causing the problem.
I've tried to install Magento 2 locally using XAMPP. This works fine, except for the fact that when I alter my CSS, HTML or JS, XAMPP won't get the updated files. It just takes the file I initially created with it's content, but not the updated version.
I think this has something to do with caching of Apache itself? I read something about disable cache using .htaccess (http://httpd.apache.org/docs/2.0/mod/mod_cache.html) but I can't figure out how to implement this.
Anyone knows how I can fix this?
Flushing cache doesn't work. Deploy static content may work, but I don't want to do that every time I make one minor change in the CSS (when I worked remotely, I did not have to do that either)
I think this problem is not Magento related, but rather something with XAMPP (probably Apache).
I have developer mode enabled.
Press Ctrl-F5 to hard refresh the page (to not use Browser's cache).
If you still see the previous pages or changes, then Apache has
mod_cache caching them, or PHP has its opcode cache settings set to
not refresh changes for X amount of time.
Taken from Xampp and Ampps don't reload files when changed
If mod_cache that is causing the problem then this might help you implement the fix How to disable cache of Apache?
This is not a caching issue, but rather the deploy mode you're using.
You are probably in default mode, in which case you will have to deploy static content every time, however you can switch to developer mode.
https://devdocs.magento.com/guides/v2.0/config-guide/cli/config-cli-subcommands-mode.html
This will stop magento having the need to generate the static content as it's done on the fly via the use of symlinks etc.
bin/magento deploy:mode:set developer
Or alternatively you can manually set this inside
app/etc/env.php
If developer mode isn't working it's more than likely down to permissions etc
Delete all files inside pub/static apart from the htaccess file, and make sure it's writable
In developer mode, M2 does not generate static files. It should create symlinks to them from the various modules. If you however have ran setup:static-content:deploy and have those files in place, it won't update them. Try to delete only those files inside pub/static folder on which you've worked and see if Magento links to them. If you delete all contents of pub/static/ folder, pages will take very long to load in browser.
I'm running Grav CMS on a Linode Ubuntu 16.04 server where PHP7 (php-fpm + nginx) returns cached results when listing directory contents. I first encountered the problem with FilesystemIterator, but it isn't limited to that class - the same problem appears when I use scandir.
Basically what happens is that any time I sync new content to the server, whether I use rsync or FTP, PHP will return the old contents of a particular folder.I've tried calling clearstatcache, but it didn't help – even if I called it from the appropriate PHP file, just before I scanned the directory.
touch'ing the files to update their mtime doesn't help either. Restarting the php-fpm service does work, however.
Is it possible that PHP caches the contents of the directory in some other way? Could it be the file system that is fooling PHP somehow?
There is but it's not something I would use in production.
Run sync first: $ sync
This command writes any cache data that hasn't been written to the disk out to the disk.
Free pagecache:echo 1 > /proc/sys/vm/drop_caches
Free dentries and inodes: echo 2 > /proc/sys/vm/drop_caches
Free pagecache, dentries and inodes: echo 3 > /proc/sys/vm/drop_caches
That being said I would also take a look at realpath_cache.
It turns out the problem I was having wasn't due to the OS or PHP, but to the Grav CMS itself – specifically how it caches page objects. It doesn't invalidate cached pages if all that had changed was the associated media files. Turning off the global cache setting for Grav helped this issue, but I've also opened an issue on the Grav repo to see if this is inteded behaviour or not.
I have created a php file and uploaded it to my Magento server but it's being cached. It's a standard .php file, but whenever I amend it, nothing changes. This has only just started happening.
Any ideas how I can stop this from happening?
Sounds like your server hosts have installed APC or another "opcode" cache. I'd start with clearing the APC cache, and if that doesn't help then escalate to your server host's support system. Being able to deploy new code is a reasonable feature to want in a server.