Bug 219542

More project part, isn't it? And probably HTML5 component? Not sure...

Well, this is definitely planned for PHP projects but currently only static files (HTML, JS, CSS) are supported.

(In reply to comment #2)
> Well, this is definitely planned for PHP projects but currently only static
> files (HTML, JS, CSS) are supported.

That's great to hear Tomas. I was very excited to see the Chrome integration but was disappointed when I couldn't use it in my PHP projects, several of which are essentially HTML5 Apps. I have tried a couple other Chrome extensions that tried to do similar things as far as updating the browser when it detected a change to a file and one that allowed editing CSS directly in the Chrome Inspector and then would update the CSS file, but usually it seemed kind of clunky.

I think it would be nice with the PHP files to at least provide an opportunity to automatically refresh the browser page on save.

Thanks for continuing to advance Netbeans!

It would be nice to have it in the next version of NetBeans.

I'm waiting for the javascript debugger in php projects too...

I was just about to log a similar request when I saw this one.

I really like the new HTML5 project features but I would really like to see them added to the PHP Project as well. 

We really need these great HTML5 debugging features in our PHP projects. 

Please try and add this in Netbeans 7.3

Keep up the good work

Created attachment 128507 [details]
proposed patch

Have you guys also considered to include a drop down with a list of browsers to preview with for PHP projects? It's a feature that's currently only available in HTML5 projects as well.

*** Bug 156323 has been marked as a duplicate of this bug. ***

I would really like to see the new html5 project features merged with the php project features - it makes no sense to have them so separate.

I think the key feature is that it should be possible to debug both javascript and php at the same time, using the same "built-in" or external web server.

(In reply to comment #10)
> I think the key feature is that it should be possible to debug both javascript
> and php at the same time, using the same "built-in" or external web server.

I tried it with the patch and it works for me but - the PHP debugger cannot be ended via the button in the main toolbar, I had to cancel it in the status bar (the progress). So adding Ondra and Martin to CC, not sure where the problem could be and what needs to be done. Please let me know if I should file a bug once I push my changes to trunk.

Exact steps:
- have a PHP project
- put breakpoint in a PHP file as well as in a JS file
- debug application [1]
- NB stops on PHP breakpoint -> continue
- NB stops on JS breakpoint -> continue

-> now, there is no standard way (via main toolbar) to stop the PHP debugger.

Thanks.
[1] Not sure if it makes any difference - I am "attaching" PHP debugger, it means that the browser is not run once I click the Debug Project icon.

Sorry, but I really don't understand the lifecycle of 2 participating debuggers and I think that I don't want to. Probably Martin will know what to do :)

(In reply to comment #11)
> -> now, there is no standard way (via main toolbar) to stop the PHP debugger.

You have two debugging sessions running and buttons in toolbar correspond to your *active* debugging session. And because of JS breakpoint was hit the active session is currently the "JS" one. Hence disabled stop button. Open view from debugging section named like "sessions" and have a look there - if you active "PHP" debugging session the stop button will be available again.

Thanks Davide, I will try it. Still, seems to me to be a bit usability issue.

Fixed, a combo with browsers added to the Project Properties dialog.

http://hg.netbeans.org/web-main/rev/0b854bf6d86d
http://hg.netbeans.org/web-main/rev/65c3c1f9e35c

Please notice that the default preselected browser is the external one with NetBeans integration.

Thanks.

http://hg.netbeans.org/web-main/rev/8b391821da00

BTW I just added "reload browser on save" functionality - enabled only for browsers with NB integration. Maybe we could/should add checkbox for it? Not sure, waiting for the feedback from our users...

Thanks.
http://hg.netbeans.org/web-main/rev/643a4da91960

(In reply to comment #3)
> I think it would be nice with the PHP files to at least provide an opportunity
> to automatically refresh the browser page on save.

This should now work, see my last comment.

Thanks.

Integrated into 'main-golden', will be available in build *201302082300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/0b854bf6d86d
User: Tomas Mysik <tmysik@netbeans.org>
Log: #219542 - Request: HTML5 integration in PHP Projects

shame this hasn't made it into the 7.3 release, will there be an incremental update with this patch or is it going to have to wait till 7.4?

I got OutOfMemory when using inspection together with upload on save after quite intense changing font-size property (I admit I just wanted to see how it behaves in such case), please look at issue 226901. I'm not sure if this should be somehow resolved together with this enhancement

Carefully verifying. I tried combination of PHP & JS debuggers and inspection features and it seems generally fine (apart from missing new "DOM" HTML Navigator and Document|Selection switcher in CSS Styles window for PHP files).

Issue 226901 is rather fabricated use case so I think it may not be a blocker for this.

> Carefully verifying.

So can this enhancement be used in isolation without fix for bug 226383, or is that one required too?

I guess that at least Honza's changeset [1] or its "part" will be necessary (or at least "text/x-php5" - perhaps "text/x-jsp" should be omitted?). I don't know about [2] if it's used by PHP?


[1] http://hg.netbeans.org/web-main/rev/eedff2058f80
[2] http://hg.netbeans.org/web-main/rev/6e18240fcf97

Just for the record, JS debugger works in JS file linked to PHP via <script>, so for instance this works:

index.php

<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    </head>
    <body>
        <?php
       include 'aa.php';
        ?>
    </body></html>


aa.php:
<script src="linebp.js"></script>




While JS generated by PHP or embedded in aa.php will stop on incorrect line (in case for instance XHR breakpoint) or not at all in case of line breakpoint. But this imho is kind of expected (just like you cannot create line breakpoints in tpl or twig files)

As for templates, let's say I have Smarty tpl file somewhere and it contains  something like

<script type="text/javascript" src="scripts/aa.js"></script>

and this file is being displayed ("generated") in index.php which is in different folder. Now line breakpoints are hit in aa.js (sometimes file is opened read-only but I have no idea why and it seems random). I'm attaching simple project to test it.

Created attachment 132502 [details]
sample project with Smarty framework

(In reply to comment #25)
> [...] Now line breakpoints are hit in aa.js (sometimes file is
> opened read-only but I have no idea why and it seems random).

Readonly JS file indicates that JS Debugger did not find project source file for server JS file URL and instead of opening project source debugger treats the file as remote JS file. Hence the file is readonly and was downloaded into IDE's userdir. If it happens randomly and sometimes it works and other times not then file an issue for js debugger/MartinE. Thx.

This is NetBeans 7.3 Patch 1 candidate, we handled it this way for long time and it met all the criteria for integration according to any possible processes we are having and following.

Users are requesting full Easel functionality in projects that use server-side templating. The fix in this issue, as far as I understand, only allows you to set Chrome with NetBeans Integration as the target and thereby enable Easel styling of HTML pages - not PHP pages or fragments - and debugging of JavaScript and PHP. So we feel this isn't going to match people's expectations and that rather than introduce incomplete functionality in a path release we want to think the workflow through for server-side templating and include a full solution in the next release. Thus removing 73patch1-candidate keyword.