The Problem
In the previous versions of Eclipse PDT, all PHP classes inside a project have been, to my current understanding, included under the default proposals. In Oxygen, however, it would seem as though only files located in directories marked as source folders show up under the default proposals.
All directories except one in my project are marked as source folders, but I believe this is the case since I created them with a previous version of Eclipse (cannot remember; bad memory). The classes inside the directory which is not marked as a source folder does not show up at all under the default proposals, and yield errors when I try to use them in other parts of the code.
TL;DR version
Some classes does not show up under the default proposals, and yield errors if used elsewhere in the code. It is as though they do not exist, at all. It appears as though this is happening because some directories are not marked as source folders, thus making the contents therein as though invisible by Eclipse.
Contemplation
I have been considering what might cause such a thing to occur, and as described above, I believe this problem might have to do with some directories not being marked as source folders. In Eclipse PDT Oxygen, apart from the previous versions of Eclipse, it is not possible to mark directly mark directories as source folders.
Everything from recreating directories, refactoring them, looking through menus, and much more, I have tried. But, no luck from those actions.
Hopefully someone will know what it is I am describing, and thus being able to point me in the right direction!
After quite some exploration of the web, I came across the help reference for the Eclipse platform, and managed to change it to the current release of Eclipse (even though that seemed to change nothing on the page.) The example is for C/C++, but adding source folders is done somewhat similarly in PDT.
Solution
In order to mark a directory as a source folder in Eclipse PDT Oxygen, right click the project you wish to add a source folder for, then:
Properties > PHP > Source Paths > Build Path
On this page, you can press the "Add Folder..." button. Check the folder (or folders) you wish to make source folders, then apply the changes and close the settings window.
Related
I'm using Composer and I don't want PhpStorm to run any error checking or inspections on the vendor folder as it is showing a false positive for some code in the vendor/composer/autoload_static.php file and hence is highlighting the lines in the file, the file itself on the left pane and it's parent folders as well all with a red underline and it's distracting.
According to this question, which is basically the issue I am having, PhpStorm isn't currently smart enough to realize this isn't actually an error.
Here is the issue from the actual file:
I have been trying to work out how to get PhpStorm how to ignore these folders or file and I can't seem to figure it out!?
I have tried clicking on the "little guy with the hat" at the bottom right and changing the inspection levels but it doesn't seem to make any difference.
How can I get PhpStorm to ignore these folders and get rid of the annoying red lines?
I'm using PhpStorm 2017.3
Issues of "Error" severity should NOT be shown in Project View panel for 3rd party code (e.g. Composer packages). The fact that they are showing -- packages are not managed in ideal way by IDE (see below) or project is not fully indexed yet.
In general: if you have Settings/Preferences | Languages & Frameworks | PHP | Composer --> Add packages as libraries option enabled, IDE will mark all your composer packages folders as excluded (Settings/Preferences | Directories) .. and then re-add them back as individual Include paths (Settings/Preferences | Languages & Frameworks | PHP) -- that's when you may see a library root text next to them. This is enough for IDE to stop showing errors for such files in Project View panel (as such files are no longer treated as part of the project code / not your code).
P.S. Even if you still see that red underwave in Project View panel .. it will disappear when you re-open the project (and will not open that file again).
The actual issue with the error highlighting: most likely will be this one: https://youtrack.jetbrains.com/issue/WI-29871 (Closure::bind).
In case if you still want to get rid of those "errors" even in the file itself: just right click it (in Project View) and chose Mark as Plain Text -- this file will no longer be treated as PHP so no syntax checks.
You could also use custom Scope (that will include such unwanted files) and disable particular inspection(s) for that scope in Settings/Preferences | Editor | Inspections .. but it will not work for already excluded files (as Scopes work with project files only). This can be used in other cases though where you want to have file/folder-wide inspection suppression.
phpDocumentor v1.4.4
Fedora 24
Command line: phpdoc -d ./docsrc -t ./output
I am running phpDocumentor on Fedora 24 and have successfully generated documentation for my project one time.
I added a docblock to a function, and ran phpdoc again. But the output has not been updated. I verified the time stamps of the files and they have been regenerated, but do not reflect the changes.
I subsequently made numerous changes, and reran phpdoc after each change, but the generated documentation does not update.
I erased all the output files, renamed the directory of the input files, in short have done all I can to persuade phpdoc to generate new documentation that reflects the changes to my php files to no avail.
It would seem that phpdoc is caching the output somewhere but I cannot find where. I searched every path on my disk containing phpdoc then searched for the word "cache" in each path but it does not occur.
I tried changing the template with the --template directive but it does not recognise this directive.
I have tried using the --force directive but it does not recognise this directive.
Can someone enlighten me?
Cheers,
Peter
This sounds like one of those times where I would just walk through the process from the beginning:
Am I modifying source in the ./docsrc directory tree? Verify by opening the source member in vi/vim/nano/some-other-editor just to be sure the source has changed.
Have I modified the source using the correct syntax? (Please post some code that shows documentation that isn't being updated)
Modify documentation in another file with a simple change and see if that simple change appears when I regenerate my documentation.
Am I explicitly --ignore-ing the file or directory I'm expecting to change? (You don't appear to be)
Do I have a phpdoc.xml or phpdoc.dist.xml file with an <ignore> directive? details
Do I have the necessary permissions to create/update files in the ./output directory?
After I've executed phpdoc -d ./docsrc -t ./output do I see the expected change when using vi/vim/nano/some-other-editor?
Is my browser caching previous versions of the documentation? (I know you've already ruled this out Peter, I'm just trying to make my answer complete)
This is EXACTLY one reason why I created PHPFUI/InstaDoc! The problem with most documentation is that it is static. While that is great for libraries that don't change, if you want to document your own code, guess what? It tends to change every day! With InstaDoc, you can see the documentation instantly on your local machine before you even check it in. InstaDoc creates the documentation when you request the page. It is hands down the fastest documentation system out there. Most documentation systems create static pages and brag about how fast they can create the documentation. But guess what? Who cares? What you want is to see the documentation of your current code base right now. Turns out it only takes a few seconds to scan through all the files of the libraries you are using. InstaDoc caches that information, so you only have a long scan (and then only seconds) the first time, or when ever you add a new library.
Once you have a library scanned, the documentation comes up instantly, since it uses PHP reflection classes to read the file and display the documentation. So that file you just modified, it is completely 100% documented. Don't like the comments, change them, refresh the page. See an issue, correct it, refresh the page. Notice something could be better? Refresh the page. Want to check out the docs on a PR? Easy, just delete the cached index and refresh the page.
InstaDoc is open source and still young. Check it out and submit comments or PR's if it does not meet your needs, but it is the future of documentation. It will also generate static files for high volume sites, but the most important feature is that it gives you an instant reflection of your just edited code, and that is what makes it awesome.
I got a website in Wordpress and recently we discovered that it was infected by several malware scripts that insert scripts using the common base64 and eval functions like this:
We were able to solve most of the infected files but there are still some scripts being injected into the index.html, like these:
All these scripts marked in red make a requests to sites that immediately trigger my computer antivirus.
So question here is, how can I track which file loads these lines? How can I know which file prints them? I can't just search for the string since the code is encrypted like on the first image...
The truth is, it's probably going to be more than one file, and/or it's going to be something hidden deep in a plugin/upload folder.
This is going to be a bit time-consuming, but these are generally the steps I follow when fixing a hacked site to narrow things down and make sure I got all the crap out:
1) Before you do anything else, make sure you have a backup of both the files and db. That way, if you accidentally delete something, it's easy to restore.
2) Delete any unused themes or plugins, and make sure all existing plugins are up-to-date.
3) Update WordPress to the current version. Seriously. Keeping up-to-date is important. If you're more than two major releases behind, you'll want to update incrementally. (https://codex.wordpress.org/Upgrading_WordPress_-_Extended_Instructions)
4) After you've updated, connect via FTP and look for files older than when you updated. Look for extra files that shouldn't be there--this can be tricky, because hacked files are usually named things like wp-shortcode-s.php. I usually have a copy of WP core files open in a window beside my FTP client as a reference.
5) Check the first few lines of code on php and js files in your plugins folder for malicious code. Again, you might want to have a freshly downloaded copy of the plugin to compare files to.
6) Check the uploads folder and subfolders for malicious files.
I also keep checking my hacked site here to see how I'm doing:
http://isithacked.com/
And when you're finished, you might want to read up on how to harden WP to make it more difficult to hack.
Depending on the source of the malware, it's hard to give you a precise hint. There are a few more in-depth walk-through about the topic you can find on Google, here are some good examples which could help:
https://www.wordfence.com/docs/how-to-clean-a-hacked-wordpress-site-using-wordfence/
https://blog.sucuri.net/2011/02/cleaning-up-an-infected-web-site-part-i-wordpress-and-the-pharma-hack.html
Also if you are on a shared host, potentially the issue could be coming from an other compromised user. Hopefully you have a clean version of the site so that potentially moving to an other host (and upgrading) is an option.
I want to standardize coding style accross all the developers computers in my office, I want to export my netbeans configuration and ask the other programmers to import it on their IDEs, do you know where that config file is?
I'm using netbeans 8.02 but if you have found it on another version I can use that information to figure it out. Thanks.
you can export your preferences via Tools|Options and use the "Export..." button on the bottom left corner. Check the "Formatting" checkboxe(s) to export formatting preferences only.
It will export your settings to a ZIP file.
To import these settings on other computers, simply go to Tools|Options and use the "Import..." button ;)
I've come to the conclusion that some settings are stored in hyperspace. So while that makes your efforts (to pass settings files around) futile, on the bright side it does mean interstellar travel is one step closer!
My experimental proof is to use this from inside the ~/.netbeans/ folder:
find . -mtime 1
I then altered some settings, closed netbeans, ran the above command again, and looked for which files changed. Nothing plausible seemed to, and the implausible ones did not contain anything that looked like my changes. I also ran the same test on the Project's nbproject folder (nothing had changed), and also had a poke around inside /etc/ (there seem to be no NetBeans files there). Yet, when I restart NetBeans, and go and look at the Options again (Editor | Formatting | PHP, then "Blank Lines" was where I did my test changes), my changes are still there.
So it is either Hyperspace, or Magic. And being a scientist I am not allowed to believe in magic. QED.
How can I (in the Netbeans IDE) add files as links, or point to existing files, kind of like a shortcut?
Visual Studio 2012 can do this, as shown in the following screenshot (found on Google Images - not mine).
I miss this feature in Netbeans. Copying my files over all the time is not an option, since I constantly improve my PHP library files, that are used across all other projects.
I am using the full version of Netbeans, and in this case, I am doing PHP development.
I am not sure that PHP is supposed to work like that, since its code is not compiled.
I could be completely wrong, and if I am, I'm sure someone else will educate us both.
What I've usually done is put the library in some directory and then add that directory to PHP's include path by adding this to php.ini:
include_path = "dir to your library"
And then I'd make sure that whatever class autoloader I was using was looking through the include path.
That said, I've more recently moved away from this, because a global library that changes often has caused me problems (a change would break something and similar issues).