Changes of php file does not reflect

[apiaio]

This makes me angry sometimes. Using konqueror an firefox for developing php-html-mysql-js pages. Too much changes in short time does not reflect code changes. Next day it works. Is it matter of config files or use flags or something else?

[kitsunenokenja]

It's hard to determine the nature of your question. If you rebuild PHP or even edit php.ini, you need to restart Apache to ensure your changes take effect. Changing PHP source files is all you need to run new code immediately. I'm not familiar with any caching paradigm that could invalidate that statement. It may be necessary to produce sample code to prove quick subsequent executions do not reflect new changes to source. As far as I know that's not the case. It's more likely you are mistaken about what is or is not really running in your tests.
_________________
ProtonMail - Free encrypted e-mail from Switzerland
Let's Encrypt - Free SSL cert organisation

[Ant P.]

PHP has a built in compilation cache since a few years ago; by default it checks for file changes every 2 seconds: https://secure.php.net/manual/en/opcache.configuration.php

[miket]

PHP indeed has an instruction-cache mechanism as Ant P. describes--and yes indeed, is sometimes not invalidated as quickly as it might be. It can get to be really annoying that way. They've gotten better over the years, though.

(Part of the problem, I suspect, is that PHP is targeted to multiple platforms. Symlinks used to confuse the cache mechanism a lot.)

The other thing that might be tripping you up is not PHP at all but the browser cache. What is supposed to happen in the browser when encountering a URL for a Javascript file already in the cache is to request a copy of the file with the If-Modified-Since header set to the file time from the previous fetch. If the file was changed, the server sends a new copy; if not, the server sends the 304 status code (for "not modified"). It's a great system but browser vendors, in their rush to show how fast their browsers are, are reluctant to use it. What this means is that it's really easy to end up with a stale copy of the Javascript in the browser. This leaves it to web page authors to use the awful workaround of adding some random element to the URL so as to defeat the cache. Not only does this make for a whole lot of needless complication when generating pages, it also causes needless increase in all the browser caches that use the site (all these multiple versions of the Javascript have separate URL's now and therefore separate entries in the cache.)

In short, its a reprehensible practice on the part of browser vendors. The sad part for you, though, is that you'll have to do a special refresh in Konqueror or Firefox (two blameworthy browsers in this regard) generally by tricks like holding down Control while pressing F5 to do the refresh whenever you make changes to your Javascript.

[apiaio]

Thanx for answers.

[ZeuZ_NG]

[apiaio]

[ZeuZ_NG]

[miket]

[Hu]

If you're frequently changing resources that the browser doesn't auto-detect, you could temporarily disable the browser cache via its settings dialog. This has the happy side effect of making round trips generally more painful (especially if you mix in artificial latency to simulate WAN use), exposing places that you're doing extra server calls that should be checked for necessity.

[Ant P.]

There's an option in the browser dev tools to disable caching while their window's kept open, that's probably the best answer here. For a production website you'd usually want to minify your JS/CSS and use a hash as the filename to prevent other users getting stale cached info.
I've just checked and it looks like php.ini still sets nocache by default, so at least we know PHP shouldn't be hurting things by itself.