There are two critical issues with PHPEd repeatedly emerging over years almost on daily basis:

1. freezing IDE on tooltip evaluation of deep objects - PhpEd freezes for 30-60 secs
2. inability to exclude specific directories from SEARCH/REPLACE - makes unnecessary search over huge subdirectory. Excluding dir over TODO tab does not work.

These two issues have been reported long ago here:

http://forum.nusphere.com/suggestion-checkbox-to-disallow-tooltips-for-complex-types-t10827.html
http://forum.nusphere.com/freezing-30-60-secs-on-accidental-variable-mouseover-t10700.html
http://forum.nusphere.com/how-to-exclude-vendor-project-directory-from-sea-t10672.html

Will these issues ever be solved/implemented?
I am not going to buy PhpEd licence anymore, if not.

-----------------

Other useful minor suggestions - also not implemented:

memory issues:
http://forum.nusphere.com/stop-warning-about-low-memory-t10816.html

UX minor enhancement:
http://forum.nusphere.com/improving-carbon-theme-in-debug-window-callstack-cols-width-t10810.html

I agree with everything said above.

Reporting an issue is one thing, reproducing the issue is a totally different story.

Freezes on tooltips -- we still don't have any examples that would reproduce issues in v20. I only have Temuri's offer to help on this matter.
In my view it depends on how fast your machine, how much free memory you have, what depth in the object being evaluated, whether your server is local, running on the same machine or it's running in the same network or it's remote across the globe. With local servers I didn't see it taking more than 1-2 seconds with adequate object instances like 1000 members, 1MB in size being serialized. Temuri, I remember you told me that the tooltips worked faster in v19. I wonder if you can reproduce it -- meaning faster in v19 and slower in v20 -- because I'm not expecting any regression here beteween these two versions. If there is a regression, we'll certainly follow your guide on reproducing the issue, if any, and will investigate it if we get this reproduced with your help.

As of search/replace -- it works with 3 different scopes -- selected directory, all the project directories and all the open files. If you exclude some directories in your project, search/replace won't go into them while searching for files in the project. It's fair.

Re UX minor enhancement -- you can see color was changed to much lighter version of red since that post, so the contrast is a way higher now


Columns "autocollapse" -- if you or Temuri provide some steps on how to reproduce this issue, we'll do our best to fix this. If this happens frequently enough for you, I hope you'll figure out what preceded this problem. On the other hand, adding constraints for all the columns for all the Tree view components through the project sources is not what we're normally going to do anyway. If something works wrong, we'll fix it, but not the other way around.

Re memory issues -- silencing the problem is not the best approach. I'd say it's not even acceptable approach. Technically there are 3 possible solutions, not mutually exclusive, so you can combine them. 1) afford more memory. 32GB these days is good to have to say at least 2) make sure the applications consuming so much memory do not do that. For instance, recently Google released an update for Chrome browser that saves memory. It's not a surprise that some web sites allocate hundred megabytes in browser memory. Check memory save option and tune the browser. 3) switch to 64bit version of PhpED, exclude from the project all the directories with duplicated/minimized code or with code that is not directly used in your project or in your current scope of work. Exclude as much js as possible. JS files are the top contributor to CodeInsight database growth.
If you followed these steps and you still have this popup showing up, please post details. We'll certainly look into the problem.

Re Excluding dir over TODO tab does not work -- I'm not 100% sure what relation is between search/replace and TODO. TODO has filter that works for me in current version. Can you double check and provide details if you still have problems?


I totally understand. This is your decision. It's free world. Probably I'd do the same -- as you already have 20030 build which is good enough.

First, the problem with session recovery after a crash. I agree with the previous comments that it may be related to the server settings. It may be worth checking to see if the "session.save_path" parameter is set to the correct value on the server and if there is enough space to save sessions. It may also be useful to check the web server settings, especially if Apache is being used. Second, there is an encoding issue. I agree that using UTF-8 is a good practice and should solve many encoding problems. However, if that doesn't help, you can try adding the line "AddDefaultCharset UTF-8" to the .htaccess file on the server.

Freezes on tooltips -
Whatfor you need to emulate the error? Of course it depends on hardware and of course many developers have less powerful machine than you do. Will you try to emulate error from everybody that will report it? You do not need that. This is multiple times reported issue so it's confirmed and really exists, even though you may not be able to emulate it directly on your powerful machine. But should you wish, here are steps to emulate typical situation when freezing occurs:

1. create virtual machine with poor/average hardware, such as low memory e.g. 4 GB RAM
2. install Windows 10
3. install devel environment - WAMP server (apache, mysql, PHP ..) and install NuSphere's DBG server extension to PHP (I am not using PHPEd's local server, because need to switch between multiple PHP versions)
4. install NuSphere (64 bit)
5. create some PHP project with composer - e.g. Laravel create project or Yii2 basic app
6. open chrome with 10 tabs, open firefox with 10 tabs - most developers need to search info during debug session, that is very common
7. start debug session and have some breakpoint to stop it
8. now - having running debug session on breakpoint - move the mouse over some object in the code, typically "$this" - which would refer to a large application object - and the tooltip will start rendering for 5-30 secs or so.

I think emulating the freezing by following steps above may take you much longer time than adding one checkbox into Settings

BTW - I checked whether are tooltips freezing on large objects in VSCode they do not dump objects into tooltips, only scalar/primitive values (integers, strings). As for objects VSCode shows something like "Object \app\models\User".

The "tooltips freezing" solution might be:
1. either stop dumping objects into tooltips like VSC, or
2. add into Setting checkbox "tooltip simple mode" (= meaning no dumping complex objects, only scalars) or
3. add into Settings configurable dump depth e.g. 1-10


Search / replace -
Excluding directories in project will also exclude from intellisense / code hints and will make files unavailable in project. It's not the same as "excluding from find/replace" - it has already been discussed in the link above. If that worked I would not mention it here, of course. I need to stop searching inside directory "app/vendor/*", but still have codehints working on files inside it. VSCode allows excluding from Find/Replace "search.exclude" directive, which may contain list of paths or relative patterns. PhpEd could have added one text field into dialog:




UX minor enhancement
I have not noticed the difference, since it is not that notable and was not mentioned in changelog, but now when you said - yes, the color is slightly better. Though still not really lucky choice, since the red color usually invokes feeling of an error.


Columns autocollapse -
I do not know exactly when or why it happens. It seems that usually on first time-ever debugged file with breakpoint could be the case.
When that happens and I stretch columns by mouse - next time it is already OK and remembers the width set by me, or will adjust according to column content.
But again - would that be a problem to ensure minimum column width like 1-2 cms? Do you really need to emulate the error?

so, in other words, we're supposed to create an environment that wouldn't work and make sure it's not working? I'm not getting the point.

Let's break the problem with RAM down into the following areas:
* Hardware RAM size: recommended RAM for Win10 is 8GB. If you have less than what Win10 has as a recommendation - don't install Win10 or upgrade RAM. You can't expect anything working good under an OS if you don't follow their recommendations.
* 3rd party RAM demanding applications like Chrome and Firefox. Ten tabs in Chrome and ten tabs in Firefox may consume a lot of RAM or may not consume too much at all. It depends on what web sites you oipen and what they are running in their JS scripts. Some sites are constantly running something or they leak a lot and eventually consume all the memory. Chrome (google) has started fighting with such aggressively demanding web applications, but it looks like it has some leverage only for the tabs in background and not immediately. So it's still an issue. Why don't you stop opening such webs? There is something you can tune up too.
* RAM consumption in PhpED. You can reduce memory consumption if you limit number of JS files in your projects you have open in PhpED. In some cases it may free up a gigabyte or so. You can reduce number of projects in your workspace that you open at once.

As of tooltips. "Laravel create project or Yii2 basic app". Sorry if I wasn't clear. We were there. We have Laravel, Yii2 and many other frameworks. We run them and see no issues. May be we don't have enough objects created, may be our objects don't have enough members, may be these members don't have enough submembers. There are many ifs. If you really want to help us, I hope unlike us you can reproduce the problem easily and it's right before your eyes (you called it critical, right?) - you can follow steps below -- it won't take too much time but would make it clearer where the culprit:
* reach to the point where you encountered the problem with tooltip in debugger
* check how much time it took for the tooltip to show up
* serialize this object into a string using serialize() php function. You can call it in the Immediate window, for instance, or in the script in place.
* save this string into a file
* write a simple script that will read this string and unserialize() it back into a variable
* run this script in debugger and check if tooltip for this variable works with the same or similar slow timing
* then you can send me the string, script and let me know the timing
This way we'll eliminate possibility of any mistakes on our side. Don't you agree? I hope you can invest some 30-40 minutes of your precious time to help us reproduce and fix a problem that you called critical. I'll highly appreciate that.
After that we'll consider the ways on how to resolve the issue. Your suggestions are valued, but we also have some ideas.


yes, sure, it would be a problem because a) we have a lot of tree view components and configuring them all can't be trivial. b) some columns are not intended to be like 1-2cms. they are 16 pixels c) some people may want to collapse the columns. By adding constraints we won't let them doing so and they will be upset. d) hiding the problem this way is by far not optimal solution. I'd prefer to know why it collapses in the first place and fix this issue and not create the other issues to fix this one.

BTW regarding tooltip and the IDE lockup issue -- I think it may be caused by races rather than structure of the object being evaluated or resources like CPU and RAM. Can you try to cut the object by half in either how deep it is or how many members it has? If it's a race, you'll see the _same_ lockup timing, I mean freezing time in seconds -- 30 or 60, but you'll reproduce it in less number of attempts. If it improves performance with cutting the object, it's not a race.
Race is harder to capture and it would explain why we are not able to reproduce up to the moment. We tried all conditions you suggested -- no freeze.



BTW 1. what exact WAMP are you using? 2. Did you make any changes to the components like replacing php or apache version? 3. What version of the debugger you have installed and from which folder in the package?

you can reply here or cut are ticket using Contact Us form and we'll proceed from here.

Rechecked after few months - still nothing implemented.
Using phped only for legacy project, but still it's a pain sometime.
Excluding dirs from search/replace 2/ would greatly speed up search and save memory, possibly partially fix 1/.
Searching uselessly over "vendor" directory takes 50-70% of search time depending on large projects.
I dont know how else to reason up this widely useful & common feature, confirmed also by others.

Actually no new IDE feature has been implemented since years. Shame.

First of all - we haven't reproduced issue with tooltips. It may not be related to displaying objects or memory usage at all. Temuri said that when switching back to default look&feel it resolved the issue. Can you confirm that?
I tried dark theme here, still worked fast for me, but you may see difference. It still hard to say why this is happening for you. Since we can't reproduce in our environment, we need volunteers who will help -- by running debug builds, collecting logs etc. It would require a lot more work on both sides.
As of the 2nd bullet point, clearly it's a new feature request and we added it to our plans.

Forget about 1/. That's difficult to reproduce. And no, it is not theme related, I experienced it with any theme, incl. default one. It needs to be tested on large project with few thousands files, not a project with 10 files like you probably do. I may record video to demonstrate. But running debug builds .. come on man, should I learn C and compilers? I suggested simple solution - optional checkbox in settings to prevent deep-objects recursion - you confirmed that it's interesting suggestion and that was the end of your implementation.

So when can be 2/ implemented if was added to plans? With next release or in 2-3 years? You always provide such vague answers and then nothing happens for a looooong time. No trust here.

It's about just installing and running special build that just produces lot more info in the log. No special knowledge is needed at all. Just reproduce the issue in the IDE, quit, pack logs, submit with your comments on what was evaluated at what approx time and how much time (approx) it took and that's it.

Allright - here's the deal - if you will implement 2/, then I will dedicate 1-2 days for running special build or collecting logs/dumps .. whatever you need. Even though my opinion is that it is not really necessary.