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?

Code: Select all

[ebuild   R    ] dev-lang/php-7.0.23:7.0::gentoo  USE="acl apache2 berkdb bzip2 calendar cli crypt ctype fileinfo filter gd gdbm hash iconv ipv6 json mysqli nls opcache phar posix readline session simplexml ssl tokenizer truetype unicode xml zlib -bcmath -cdb -cgi -cjk -coverage -curl -debug -embed -enchant -exif (-firebird) -flatfile -fpm -ftp -gmp -imap -inifile -intl -iodbc -kerberos -ldap -ldap-sasl -libedit (-libressl) -mhash -mssql -mysql -oci8-instant-client -odbc -pcntl -pdo -phpdbg -postgres -qdbm -recode (-selinux) -sharedmem -snmp -soap -sockets -spell -sqlite -systemd -sysvipc -threads -tidy -wddx -webp -xmlreader -xmlrpc -xmlwriter -xpm -xslt -zip" 0 KiB

Code: Select all

[ebuild   R    ] www-servers/apache-2.4.27-r1:2::gentoo  USE="ssl -debug -doc -ldap (-libressl) (-selinux) -static -suexec -threads" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_core authn_dbm authn_file authz_core authz_dbm authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir env expires ext_filter file_cache filter headers include info log_config logio mime mime_magic negotiation rewrite setenvif socache_shmcb speling status unique_id unixd userdir usertrack vhost_alias -access_compat -asis -auth_digest -authn_dbd -authz_dbd -cache_disk -cache_socache -cern_meta -charset_lite -dbd -dumpio -http2 -ident -imagemap -lbmethod_bybusyness -lbmethod_byrequests -lbmethod_bytraffic -lbmethod_heartbeat -log_forensic -macro -proxy -proxy_ajp -proxy_balancer -proxy_connect -proxy_fcgi -proxy_ftp -proxy_html -proxy_http -proxy_scgi -proxy_wstunnel -ratelimit -remoteip -reqtimeout -slotmem_shm -substitute -version -xml2enc" APACHE2_MPMS="-event -prefork -worker" 0 KiB

Thanks in advance.

[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.

[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/opcach ... ration.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.

... 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)...

Which browser could be suitable for my needs?

[ZeuZ_NG]

Thanx for answers.

... 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)...

Which browser could be suitable for my needs?

As I understand, it's not really a matter of browser. If its PHP cache, you can allways clean the PHP object files..
If it's the browser, you can always hit CTRL+F5 to force cache clean..

Try the later first and let us know if its related.

[apiaio]

As I understand, it's not really a matter of browser. If its PHP cache, you can allways clean the PHP object files..
If it's the browser, you can always hit CTRL+F5 to force cache clean..

Try the later first and let us know if its related.

OK. I will do.
Just now I am installing gentoo (17.0 profile) at the same box and I don't use KDE, I could change konqueror for another, maybe more convenient browser.
So. If anybody have positive experiences with testing php && js codes in other browsers please, let me know.

[ZeuZ_NG]

As I understand, it's not really a matter of browser. If its PHP cache, you can allways clean the PHP object files..
If it's the browser, you can always hit CTRL+F5 to force cache clean..

Try the later first and let us know if its related.

OK. I will do.
Just now I am installing gentoo (17.0 profile) at the same box and I don't use KDE, I could change konqueror for another, maybe more convenient browser.
So. If anybody have positive experiences with testing php && js codes in other browsers please, let me know.

As for my experience you have to try with as many browsers as possible. A gecko based one a web kit based one and a blink based one.. Also edge or maxthor as the ones compatible with Trident

[miket]

If anybody have positive experiences with testing php && js codes in other browsers please, let me know.

I echo what ZeuZ_NG wrote about needing to test in multiple browsers. As for first-line development, the Javascript debugger in Chromium is really good. In general, I find that it is better in reloading the Javascript being debugged than other browsers are, so that's a second point in its favor.

The thing, though, is that Javascript might work well in one browser and not so well in others--just as the rendering of HTML and CSS also varies among browsers. That's why it's good to test in a wide selection of browsers.

Just be prepared for doing the reload-Javascript dance with those browsers when you make changes. If push comes to shove, clearing the browser cache always works.

[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.