Why Do Changes to Some PHP Files Take So Long to Show on the Live Site

html.twig file not showing changes on live site

Most likely you need to refresh the caches.

Accessing it via a terminal, you should do:

APP_ENV=prod APP_DEBUG=0 php bin/console cache:clear

More info: https://symfony.com/doc/current/deployment.html#d-clear-your-symfony-cache

If you cannot or do not have any sort of terminal access, possibly you could remove the files located under var/cache/prod/

php not showing changes to files consistently

Answering my own question...

I spent quite awhile doing trials to consistently reproduce the behavior. I had to let the server sit without refresh any page for a few minutes. Then if I change the file before I refresh the page, the change show immediately and all subsequent changes show immediately. If I refresh the page first, then make a change to the file, then no subsequent changes show until I refresh 10-20 times, or so.

BTW, html files show all updates regardless, so it was a php issue.

Before finding the answer, I tried...

• turning off nginx cache
• setting nginx conf to sendfile off;
• setting nginx conf to expires off;

... none of these work. I then found that it was in fact OPcache. I fixed the issue by changing the php.ini file to this (and restarting all services)

opcache.enable=0

Updating PHP files slow on MAMP

Since you're accessing the file via localhost, DNS shouldn't be an issue. If HTML files serve instantaneously, it might be that there is a PHP caching setting. Does this help - http://top-frog.com/2011/03/14/beware-mamps-default-caching-settings/ ?

Why is my PHP file using MAMP not refreshing?

I just ran into this. I found the answer in another thread -- it's the OPcode caching, which you can disable by commenting out some lines in php.ini.

See: https://stackoverflow.com/a/19268769

Trying to work on a client's Drupal site from my local machine

Well, for the basic question, you have to get the correct credentials from your client. There's no alternative, really :D

While you're at it, you'll want a copy of the site's database too.

For the question "how do I host it locally?" Here's how I would go about it.

Get the site into version control.

Given that you were given (S)FTP credentials, I'm guessing the site is not version-controlled. If that's correct, then that is probably the very first thing you want to do. This will allow you to keep track of the changes you've made on your local site that are different to the production version.

1. Create an empty directory on your computer.
2. Navigate to the directory in a terminal and run git init.
3. Add a .gitignore file to that folder (you can create your own, or use one customized for Drupal).
4. Download the site's files into the directory created in step 1.
5. Add the files from the in the directory to the git repository by running this command in a terminal: git commit -am "First commit of Drupal files to repository."

There's a good help page about working with Drupal in git on drupal.org.

Create and populate your database.

1. Get a database dump from the live site.
2. Create a new database and database user on your machine.
3. Import the database dump into your new database.
4. Record the database credentials in settings.php or settings.local.php and store them somewhere safe, preferably in a password manager.

5. Change the database credentials in settings.php or settings.local.php to match the credentials of the database you've just created.

   (For safety and to avoid confusion, I always create local databases with a different name, user, and password than the live site has. This means if your local credentials are compromised, the live site isn't, and it means you can't connect to and change the live site's database by accident.)

Set up the webserver in XAMPP

1. Create a new site in XAMPP called e.g. example.local that points to the directory that contains the file index.php

2. Add the following line the file called /etc/hosts on your computer:

   127.0.0.1 example.local

3. Test that this works in a browser by visiting e.g. http://example.local or http://example.local/robots.txt.

Move your local changes to the Production site

How you will be able to do this depends to some extent on your client's web-hosting infrastructure, and what version of Drupal your client uses. but in any case, you will have three separate concerns for changes you make:

1. Code changes

   You will need to deploy changes you make to the code back to the server. Ideally you would probably do this via Git either by cloning directly into the live site or (far better!) as part of an automated build process. By the sound of it, you may just have to FTP the changes back up.

   Be careful not to re-upload your modified settings.php or settings.local.php file!

2. Content changes

   You probably have to test some/all of your content changes locally and then recreate them on the live site. Because your client may have made changes to the live site while you were working, you can't risk importing your local database into the live site.

3. Configuration changes

   Changes to configuration should be managed in code (i.e. as part of 1. Code changes above) if that's possible. In Drupal 7, the Features module is usually the best way to accomplish this (here's an answer I wrote describing the Features workflow). Drupal 8 has the Configuration Manager. Be aware that these two tools can both be tricky to use well.

---

Related Topics