Mac doesn't update fast when programming PHP - php

I have this weird problem, and I don't know how to get rid of it.
Example: I put a var_dump('test') in my code at the top of the page. Just to edit something.
Alt-tab to chrome, cmd-R to refresh.
The var_dump('test')is not there. Cmd-R again. Still not there.
Then I wait for a minute, and refresh... And suddenly it's there.
Basically: I will always see code changes, but not immediately.
I have this problem in PhpStorm and Netbeans, so it's probably not an IDE problem.
Edit: I have also tried this in different browsers, and they all have this as well, so it's not a browser-related problem.
Has anyone had this problem before? Does anyone know a solution to this?
It's really difficult to work efficiently if I have to wait to see my edited code live...
EDIT:
I'm working on my localhost. Server setup is with MAMP.
REQUEST HEADERS:
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip,deflate,sdch
Accept-Language:nl-NL,nl;q=0.8,en-US;q=0.6,en;q=0.4
Cache-Control:no-cache
Connection:keep-alive
Cookie:projekktorplayertracking_prkusruuid=D1A39803-4DE3-4C0B-B199-6650CF0F8DE5; Akamai_AnalyticsMetrics_clientId=C355983152DF60151A0C6375798CD52E8F09B995; __atuvc=4%7C47%2C0%7C48%2C0%7C49%2C17%7C50%2C47%7C51; PHPSESSID=885c62f543097973d17820dca7b3a526; __utma=172339134.2012691863.1384502289.1387377512.1387442224.41; __utmb=172339134.1.10.1387442224; __utmc=172339134; __utmz=172339134.1384502289.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)
Host:local.sos
Pragma:no-cache
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36
RESPONSE HEADERS:
Connection:Keep-Alive
Content-Length:681
Content-Type:text/html
Date:Thu, 19 Dec 2013 09:00:54 GMT
Keep-Alive:timeout=5, max=99
Server:Apache/2.2.25 (Unix) mod_ssl/2.2.25 OpenSSL/0.9.8y DAV/2 PHP/5.5.3
X-Pad:avoid browser bug
X-Powered-By:PHP/5.5.3
EDIT:
I was messing around in MAMP's settings. My PHP version was 5.5.3, but then I couldn't set any PHP Extensions.
When I put PHP version on 5.2.17 (my only other option), I was able to set Cache to XCache.
So... Now my page is always up-to-date when reloaded immediately.
Thanks to anyone that replied and helped me with this!

This was the solution:
I was messing around in MAMP's settings. My PHP version was 5.5.3, but then I couldn't set any PHP Extensions.
When I put PHP version on 5.2.17 (my only other option), I was able to set Cache to XCache.
Then it worked.
But then I found this thread.
In your MAMP Dir go to : /bin/php/php5.5.3/conf/php.ini
And comment the Opcahe lines:
[OPcache]
;zend_extension="/Applications/MAMP/bin/php/php5.5.3/lib/php/extensions/no-debug-non-zts-20121212/opcache.so"
; opcache.memory_consumption=128
; opcache.interned_strings_buffer=8
; opcache.max_accelerated_files=4000
; opcache.revalidate_freq=60
; opcache.fast_shutdown=1
; opcache.enable_cli=1
Now I'm programming in PHP 5.5.3, and my pages are immediately updated.

There are three possible causes (I can think of):
Your browser is caching the file, on development sites you can disable your cache (eg in Chrome press F12 and click on the gear in the bottom right, check the checkbox to disable cache while developer tools are open - keep it open in development areas)
Your connection to your server is lagging, this can be caused by delayed uploads by your IDE or by your connection. You can test this by opening a SSH connection and check modified times after saving (eg; repeatedly pressing ls -la or watch -n 1 ls -la in the directory of the file)
In case of some applications another form of caching might exist. This can be APC or Opcache. In order for this to be the possible cause it might be wise to exclude the above first. This step requires you to analyze the headers send by the server as available on the Network tab of the devtools (in case of chrome)

Not sure about NetBeans, but PhpStorm updates the file as you type (there is no need to explicitly save). HOWEVER, the auto-save debounce is OS dependant. Mac might wait for file changes slower to refresh their contents. I'm not sure how to do it on OS X, because I can't recall the name of the feature but another workaround is to explicitly save the file using Command+S.

I had a similar sounding problem working locally with .php and .less files in IE and Chrome. Something was causing the css file to be cached or cookied or something and wouldn't display the changes made to the .less file. We fixed it by creating a php variable of the time stamp and then attaching the variable to the end of the file name and source link. The browser treated it like a new file and would always load it.
I don't have the actual code to do that right now (I'm at home) but will look for it tomorrow at work.
Obviously, this isn't the same problem you're having, but I thought it might give you a new direction to research your issue.

Related

Firefox: connection determined in PHP script

I've set up an Apache Server as localhost in a openSUSE 13.1 64 bit system and I'm currently testing my PHP scripts.
In Konquerer 4.11.5 everything seems fine, but with Firefox 29.0.1 there is a strange phenomenon:
Every 10th time or so the connection fails. Firefox reports: "Connection determined".
The failed connection is listed neither in error_log nor in access_log.
The error must be quite "early". Because my PHP script output.php calls "itself" via
header("Location: output.php?changed_url");
almost immediately, but the Firefox error is BEFORE output.php is opened for the second time.
I have no idea what to do about this. It's a quite annoying issue.
All answers will be appreciated! Thanks in advance!
I guess you are missing
exit;
after the header() location change.
So you have an open script, firefox redirecting to the next (itself) and still having one open, ... I think firefox doesn't like this kind of loop ;)
Do you have any .htaccess file there? Have you tried using firefox from different OS or computer? I bet it's related to your installation of firefox :) (i ain't pro take it as guess)

Xdebug with PhpStorm IDE - detects incoming connection but will not bring up debug console

I have tried to set up Xdebug (2.2.3) with PhpStorm 7.0 and I cannot bring up the step-through debugging console as I have in the past. The guides that I have used to set this up are:
https://www.jetbrains.com/phpstorm/webhelp/configuring-xdebug.html
http://blog.jetbrains.com/webide/2011/02/zero-configuration-debugging-with-xdebug-and-phpstorm-2-0/
I know that the Xdebug extension itself is working as the cachegrind.out.3280 files are being created on page load (with 12Mb litany of all of the scripts required and variables/values). My set up in php.ini (php version 5.4.12) is:
zend_extension="c:/wamp/bin/php/php5.4.12/zend_ext/php_xdebug-2.2.3-5.4-vc9-x86_64.dll"
xdebug.profiler_output_dir="c:/wamp/tmp"
xdebug.profiler_output_name="cachegrind.out.%p"
xdebug.profiler_enable=1
xdebug.remote_enable=1
xdebug.remote_port=9000
xdebug.idekey=xdebug
xdebug.remote_connect_back=1
xdebug.remote_host=dashboard.dev
After setting a break point, turning on Xdebug chrome extension, clicking to listen to Xdebug within PhpStorm and refreshing, I get the Incoming Connection from Xdebug dialogue:
However, when I click Accept, the dialogue disappears and nothing happens.
If I then go to Settings / PHP / Servers in PhpStorm, I see that a new entry has been created:
Only by deleting the entry that was added can I get the Incoming Connection dialogue to show up again when I refresh the page. I notice that the port is set to 80 so wondering if that is right since the Xdebug extension is set to run over port 9000; when I click "Validate remote environment" select deployment server, then "Validate", I get: No debug extension is loaded. So I am assuming that the problem is something related to how this is set up.
The problem was fixed by adding the break points to other parts of the code as it was not working when attached to the try clause. Additionally, here are some other tips that might be useful:
Try using a programmatic breakpoint: xdebug_break();
Check that if your php is 32bit then so is the version of Xdebug (or that they are both 64 bit).
The xdebug remote host setting relates to the server IP address (so 127.0.0.1 for local).
You need to configure the mapping between server path and local path in preferences / server
In your Phpstorm goto File > Settings > Languages & Frameworks > PHP > Debug.
Under External conections section, mark the checkbox saying
Ignore external connections through unregistered server configurations
This was fixed for me.

Dynamic CSS (with php headers) not rendering in Linux (mint) - it works fine in Windows

I have a dynamic CSS (with some values and class/id names provided by php).
the file begins with:
header("Content-type: text/css; charset: UTF-8");
require("../../_Config/config.php");
The directory structure is (to determine the relative position of config.php and css.php files):
ROOT
-[_Config]
-config.php
-[_Viewer]
-[css]
-css.php
I have Linux Mint 15 installed, with apache and (some) mods enabled - I noticed that headers mod wasn't enabled... and I enabled it, but that didn't helped. I get the css file in client, but is plain and empty.
Strange fact is that under Windows XAMPP it works fine.
Any suggestions here? Maybe the relative path is faulty? I tried several combinations, but neither worked (as I have to go up in the parent, to access config.php i thought it may be part of the problem).
I'm just accommodating with linux, so it's possible that solution to be very simple... or not. Anyway, if you need more details that i may have skipped here, please ask.
EDIT:
Just a thought: could be a Linux permissions issue? - if so, what would be the suggested workarounds, considering that my site is located in /var/www/ and php is running under www-data user at this moment. Is it wise to chanve apache ownership?
EDIT 2
Checked header requests in Firebug - this one is for my file
Connection close
Content-Encoding gzip
Content-Length 20
Content-Type text/css; charset: UTF-8
Date Thu, 03 Oct 2013 15:04:54 GMT
Server Apache/2.2.22 (Ubuntu)
Vary Accept-Encoding
X-Powered-By PHP/5.4.9-4ubuntu2.3
Request Headersview source
Accept text/css,*/*;q=0.1
Accept-Encoding gzip, deflate
Accept-Language en-US,en;q=0.5
Connection keep-alive
Cookie PHPSESSID=3ohou7v772o20i72rli3iofdq6
Host 192.168.1.99
Referer http://192.168.1.99/index.php
User-Agent Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:24.0) Gecko/20100101
Firefox/24.0
This can be happened due to cache problems with vagrant, vm and linux. you can add the request parameter in the url
example
<link src="http://www.example.com/abc.php?v=1.0" > instead of <link src="http://www.example.com/abc.php" >.
Solved!
It seems that the require statement was evil. Can't explain why (and, if somebody CAN, please post the answer).What I did, was to replace require with include ... now I won't get any fatal error in case something goes wrong, but at least the css is loaded properly.

Page onload time is very high

I am trying to investigate the cause of slowness on my website.
Here I attach firebug screenshot:
As you can see, all of content is loaded in just 2.92s, but javascript onload event is fired up AFTER 17.67s.
In case you want to see the website itself: http://maylashop.com .
I have tried to use YSlow, I get A grade and it doesn't help.
If anyone have fix or know what caused this, please kindly let me know.
why http://cf.addthis.com ? http://platform.twitter.com, plusone.google.com .... I dont see you use them any where ? if you are using , add them when they are desired
follow the guide lines Yslow , get some matrix and the check what is the bottleneck
You will be happy to follow these rules
This is not a JavaScript problem. Your PHP script is taking that long to execute (see screenshot). All the other resources that page is loading (JS, CSS, images, etc.) are taking less than a second to load. I'm 95% sure this is caused by zlib.output_compression. Try adding the following code to the top of your script to see if disabling it does anything useful:
ini_set('zlib.output_compression', 0);
If that fixes it, then you could consider not using zlib.out_compression or figure out what specific thing in your code is causing problems with it (usually output buffering).
Pretty sure this is not related to javascript. Just to request your main page took about 2 seconds. Ran this on a linux machine:
date ; lynx -source http://maylashop.com/ > /dev/null ; date
Fri Apr 13 22:38:19 CEST 2012
Fri Apr 13 22:38:21 CEST 2012
This is an independent confirmation that the host is either generating the index page too slowly, or there is a network transfer issue.
Doing the same thing with /index.php or /index.html or even a 404 page I created on the fly results with same ~2 second delay.
Edit: checked image download speed, and that one is <1 second. Close to 0.
Something in your PHP code might be creating the problem (inducing a delay.) One of those things could be delay in connecting to a MySQL server (or whatever you're using.) Is the database server on the same exact machine, or remote? Are you connecting to it on each call, or do you have a caching system in place?

Xdebug And Netbeans Problem

Im trying to configure xdebug to work with Netbeans 6.9 and php 5.3
As far as i concern i have setup xdebug properly.
I can see xdebug extension from phpinfo page.
I have read other post and tried their suggestion but up to no avail
When i hit the debug button, it straight open the page in the browser and i can see message 'Waiting for connection' in the bottom pane of netbeans
Here my setting in php.ini
zend_extension = /usr/lib/php5/20090626+lfs/xdebug.so
xdebug.remote_enable=on
xdebug.remote_handler=dbgp
xdebug.remote_host=localhost
xdebug.remote_port=9000
xdebug.idekey="netbeans-xdebug"
Any help would be appreciated
First, check that it isn't actually working for you, and you don't notice. I've done this...convinced it's not working I wasted a chunk of time trying to get it to work, only to find that everything was OK.
Look at your NetBeans status bar. If you see "netbeans-xdebug" and "running" then it is actually working just fine. You probably have the "Stop at first line" option turned off and you didn't hit any breakpoints you set (if any) yet. That would be a reason you are seeing the page with little or no indication that the debugger is actually connected.
If you instead see "Waiting for Connection (netbeans-xdebug)" and the progress bar is cycling, then you are indeed not connected. Open Tools|Options, and go to the PHP page. On the general tab, make sure that the "Debugger port" is 9000 and the "Session ID" is "netbeans-xdebug". You may want to have "Stop at First Line" checked. I don't, as I find it a bit annoying. I would definitely ensure that "Watches and Balloon Evaluation" is not checked. This option causes NetBeans and the debugger to destabilize. If you need a watch, hack a local variable into the PHP code where you need it, and you'll see it on the "Variables" tab when the debugger is running. Also, confirm that file (index.php) is specified in the project's Run Configuration > Index File.
Since you see xdebug in phpinfo(), that end of it is fine. Just make sure that all of the values look reasonable, and that there is some reference to a cookie "XDEBUG_SESSION=netbeans-xdebug" somewhere on that page. (Make sure that you don't have cookies turned off on the browser!)
The only other thing to check is to see if some firewall/security program is running that would be blocking TCP/UDP locally (which would be super-odd, but not out of the realm of possibility), or that port 9000 isn't already used by another application. I am using a different port number in my local setup for some reason. I don't remember changing it, but I am sure that the only reason I would have is if I had hit a port conflict with something else.
One last thing... We've been assuming that you are running NetBeans and the web server on the same computer. That's a common configuration, but not the only one. If your web server is on a different computer, then change the localhost in xdebug.remote_host=localhost to the IP address of the computer on which NetBeans is running.
Another last thing: When cycling through frustrating iterations, until you see xdebug info in phpinfo(), restart apache/php. Once there, still restart NetBeans between iterations. And believe it or not, restart your browser.
For me it was changing
;xdebug.remote_enable = 0 (default value in clean XAMPP installation)
to
xdebug.remote_enable = 1
did the trick
Adding an index.php did the trick for me.
I couldn't figure out why some of my projects would connect to the debugger and others wouldn't. Then I realized that the ones that wouldn't connect started with index.html. Once I renamed these files to index.php, the debugger connected with no problem.
I solved this using a windows -> remote LAMP server config after reading the following post, leaving the link in case anyone finds it handy:
http://stuporglue.org/setting-up-xdebug-with-netbeans-on-windows-with-a-remote-apache-server/comment-page-1/#comment-6227
Having just upgraded to the new Ubuntu 14.4 my NetBeans Xdebug stopped working. I've followed all the answers above to date to no avail.
I found a NetBeans Ubuntu statement that the /etc/php5/cli/conf.d/xdebug.ini file should have xdebug.remote_enable=on. When I checked the /etc/php5/cli/conf.d directory, I found no xdebug.ini file. However there was a link to /etc/php5/mods-available/xdebug.ini there.
Subsequent adding the xdebug.remote_enable=on to that file fixed the problem.
PS - This works on NetBeans 8.0.1
When I tried to debug the Yeoman WebApps powered by PHP backend in Netbeans, the status keep showing 'Waiting for connection'. There's probably because the index.html has nothing to do with php at all. It's only when I've triggered the ajax which needed PHP processing, the connection with xdebug immediately connected and debug as usual. Hope this give another perspective to someone as I have stumbled to 'think' there is a problem and trying to fix the ini.
An alternative is the Dephpugger project. Is like ipdb in python or byebug in Ruby.
https://github.com/tacnoman/dephpugger
Is very easy to use.

Categories