There is an old site on Symfony2.
I edited one of the twig-files.
The content of the page remains the same.
I tried:
Cleared app/cache folder.
Restarted apache server.
Reloaded browser with Ctrl+F5.
How to "rebuild" the site after editing twig files?
The fastest way for Symfony2 then would be:
rm -rf app/cache/*
However, make sure that app/cache is writable. Otherwise you'll have 500's with it not being able to write to cache anymore. You could also get specific with your environments like app/cache/dev or app/cache/prod. The next time your app loads it will take a bit more time, so if you are running a time-sensitive application (hopefully not with Symfony2) then plan that change accordingly.
The problem was that I haven't noticed that the site are hosted from a virtual machine. Thus, files in the standard location were ignored.
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'm using Laravel Homestead (Vagrant) to set up my development environment. Everything works fine, until I try setting up NFS on my Windows following https://laravel.com/docs/8.x/homestead#configuring-shared-folders
As soon as I set up NFS, the vagrant up process goes fine, but trying to access the project website makes it unresponsive, i.e. no reply from the server. Opening vagrant ssh, only the place where the shared folder is present is unresponsive (bash gets unresponsive), otherwise other parts of the shell keep working.
More than a day of debugging later I find that simple files are actually working fine. So if index.php contains phpinfo();, that loads fine. I then copied the Laravel public folder, all good with an error that vendor is missing. Added the vendor folder, still good, says Kernal missing. And finally when I add the app\Http\Kernal.php file, again it gets unresponsive.
Edit: Adding the following mount_options finally gets it working, but instead of being a lot faster, it is actually taking double the time it takes without NFS. My aim here is to improve the app loading speed, which everyone says gets a lot lot faster with NFS.
mount_options: ['vers=3', 'tcp', 'actimeo=1', 'nolock']
Edit 2: After a lot more debugging I noticed realpath() in PHP was coming out empty, after which I realized I'm unable to change file permissions of the shared folder! So the index.php has 644 permissions, and I'm totally unable to change those permissions or owner:group. I tried changing mount_options dmode and fmode, they don't have any effect
Future update: I eventually moved to Docker and later Laravel Sail and its magically fast
Try setting the max rsize and wsize for tcp in your mount options, you would also probably want to set asynchronous mode and force nfs to use fs-cache.
e.g.
mount_options: ['async','fsc','nolock','vers=3','tcp','rsize=65536','wsize=65536','noatime','actimeo=1']
You could also try the mount over udp to see if that resolves the issue, I would also try simplifying the mount options at this point to see if it is something there causing the issue you are having.
mount_options: ['vers=3','udp','rsize=8192','wsize=8192']
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 currently working to make a WordPress plugin of mine compatible with nginx. This plugin requires access to a .conf file in the wp-content/uploads directory, so that it can add in the required rules. Currently, it updates an .htaccess file in the same directory, and the changes take effect immediately without intervention. Because nginx requires service nginx reload to allow configuration changes to take effect, I am looking for a way to do that in my script. I'm not sure that even exec() would work for this, as service nginx reload is required to be run as root or using sudo. I've searched far and wide on StackExchange, Google, and everywhere else that I know of, and I can't even find a starting place.
Security wise, it would be a VERY bad thing to give the user that runs the web server sudo/root access. Rather, you could use a semaphore file and have a cron job run by root that runs every 5 minutes (or higher frequency if required) that looks for the presence of this file. If present, it issues the service nginx reload command and deletes the file.
My Suggestion
Overall I think the best solution would be to have your plugin create specific instructions for the user to edit any Nginx config manually and then reload Nginx themselves.
I believe this because giving PHP the ability to run a command that usually requires sudo requires opening up a large security hole.
On top of that, the methods that a user would have to do in order to allow PHP to run the service nginx reload command is not something you can accomplish in PHP alone, and may be equally, if not more, complex than having them update Nginx config and reloading themselves. The user needs to do extra work regardless!
If you really want to do this:
If you still choose to go down this course of action, I suggest having users of the plugin edit the server's /etc/sudoers file, which can allow user www-data (or any other user) to run that one specific command using sudo without requiring a password. This also means that the user (perhaps www-data) would NOT have permission to run any other command, which is at least a bit more secure.
Use the sudo visudo command to edit the /etc/sudoers file. Don't edit it directly.
Here's the line to add to that file for user www-data:
www-data ALL=(ALL:ALL) NOPASSWD:/usr/sbin/service nginx reload
Here's an example of allowing a user (group) to run similar commands, with some more explanation. Here's more on Sudoers and how /etc/sudoers works.
Lastly, note that user www-data is specific to installing Nginx on Debian/Ubuntu Linux distributions. Other very common distributions (centos, redhat, fedora, arch, etc etc etc) may not be running Nginx/PHP-FPM as user www-data unless the sysadmin creates those users manually.
Short answer: Bad idea. Don't do it.
Long answer: What you try do to cannot be compared with editing a .htaccess file simply because it does not work the same way. .htaccess files are made to be edited and reloaded on the fly and can be created and accessed almost in every directory inside your public directory.
That is not the case for Nginx configurations. Configuration files are made to be loaded when Nginx starts or manually when needed. Their location is related to the configuration defined by the administrator.
Even if you knew where the file was, it could be impossible for you to update it or write in that specific directory.
More than that, you'll have to figure out what user can write and read where the configuration files are located.
In the end, there are so many thing that can go wrong. In my humble opinion, the idea is really bad.
What most plugins do is display the Nginx configuration that should be included so the website administrator can copy and paste it. Or, they create a .conf file that the website administrator must copy somewhere before restarting Nginx.
What you try to achieve is doable. It can be coded. Don't get me wrong. BUT your plugin will become about handling every specificty of every Nginx configuration there is out there. You really don't want that.
As you don't know every configuration (and honestly, you don't want to know), I'd suggest you focus on developing a great plugin and offering the right Nginx configuration via the plugin. The last part (where the website administrator copies it to the right location and reloads the configuration) is his job.
The other answers I read in that question suggest ways of "trying" to achieve what you are asking. I think they will create more problems than they'll help. By changing permissions and running crons, it may work. But you'll also open the door to security vulnerabilities as your www-data user or website user owner will now be considered as root and could run things that should not be run. I would not advise you to do that.
You must add correct permissions to account www-data which is used to execute commands on Linux webservers. You see which account is executing script with PHP by using <?php echo exec("whoami"); ?>
I am very new to php and laravel development. I am working on an existing php+laravel project. and I am trying to understand how it works. the existing application is working fine.. but when I make some changes to the php files in models, controller folder, the changes are not reflected in the output.
what command should I run to build everything?
thanks
I've experienced this a few times myself, and the reason was that my cached view had not been updated. Try emptying the following folders:
/app/storage/cache
/app/storage/views
No need to restart the web-server.
Note! Some of the storage folders may contain a git placeholder, such as a .gitkeep file, it get git to commit "empty" folders. Don't delete that file, if you need the folder to get committed.
Update: You can use the artisan command view:clear to clear the cached views, instead of emptying the folders yourself.
I have encountered this problem on my linux machine.
What I did was restart ngnix (service ngnix restart) and also restart php (service php5-fpm restart) and now the changes are showing again.