I wish to be able to do something like:
php --determine-oldest-supported-php-version test.php
And get this output:
7.2
That is, the php binary checks test.php for all function calls or syntax used, and then spits out the oldest version of PHP which would be able to run the script.
The purpose would be for me to create a script which goes through all the .php files in my library/framework and figures out which version of PHP I should consider to be the "oldest supported version".
Currently, I'm doing this manually. Whenever I knowingly use a new feature, function or syntax, I bump up a variable to "7.4" or whatever, and then compare the currently used PHP version against that on runtime. This is not ideal, as you can imagine, and I could very well forget to bump up this value or bump it up too much, or too little, etc.
It would be much nicer to be able to determine this automatically, with such a feature in PHP itself.
I have of course looked through the list of options and PHP has no such feature as far as I can tell. Since I basically answered my own question right away, are there any plans on such a feature in the future?
The only guarantee given is that PHP will remain compatible within the same major version.
You may be interested in looking at the article
Why You Should Be Using Supported PHP Versions.
The tool you are looking for is the GitHub project
PHP_CodeSniffer,
further described in the article
PHPCompatibility update.
You may run it using a command such as:
phpcs --standard=PHPCompatibility --runtime-set testVersion 5.4 <path-of-your-php-files>
I've encountered the oddest thing today and I'm not sure what to make of it.
Here's my code:
<?php
$nf = new \NumberFormatter("en_UK", \NumberFormatter::ORDINAL);
die(var_dump($nf->format(1)));
This code outputs the following in PHP version 5.6.20:
string(3) "1st"
but it outputs the following in PHP version 5.6.14:
string(6) "1ˢᵗ"
I'm not sure what to make of this. The superscripted version is something I was not expecting. I went through the change logs but haven't seen this change documented. Anyone know if this is intended behaviour? Any way to force it back to the first behaviour (because it looks odd when rendering it in forms)?
The PHP 5.6.20 installation is using ICU version 4.8.1.1 while 5.6.14 is using ICU version 4.4.0.1
I'd just upgrade to a newer ICU.
The strange superscript was fixed in CLDR 2.0 It was introduced in this ticket years before. I'm not sure which CLDR version introduced it, but unfortunately my name is on as the reviewer. Maybe it seemed like a good idea at the time.
This is data from CLDR and not code, usually we don't make a changelog entry for each data change.
1) Is a PHP library (as in the GD Library) a compiled DLL (or other appropriate name if that is not used outside of Windows) written in a language such as C, compiled, and then "loaded" and made available to PHP code?
2) If this is the case, where can I find documentation on libraries which, among other things, includes calling, argument passing, and value return standards and protocals, and other information which I can use to get started writing PHP "libraries"? I am not looking for documentation on how to program in C or another language, I am looking only for specific, and detailed, information on creating "libraries" for PHP.
Bob
In the php world I believe it's called an extension and it's behave similar to a windows dll and maybe has something similar when you want to create one.
theserverpages.com/php/manual/en/zend.php. I think its part of the php documentation, the url www.php net may work also.
I've got an external standard, which I got out of Sonar. I specify the standard with the --standard=/path/to/standard.xml methodology. If that isn't a valid file, I get an error. So it is reading and parsing the file.
My problem is in the output it is including several sniffs that my standard isn't telling it to use. I get a ton of false positives going into Jenkins. Sonar at least strips out the ones that aren't in that standard. For instance, I've turned off all of the full stop rules, but they are still showing up in my report.
I am running PHP_CodeSniffer version 1.3.2.
I'm going to be doing some PHP editing for my job this summer, and am looking for an effective Emacs setup for editing it. I'm already heavily invested in Emacs, so switching to another editor is not worthwhile.
Right now, I have nXhtml-mode, which provides a PHP mode with syntax highlighting (there are at least three different ones in the wild) as well as MuMaMo for editing PHP embedded in HTML. I just started using Auto-Complete and Anything for programming and general Emacs stuff, respectively.
What I'm really looking for is an effective way to get Emacs to really understand the project, beyond just highlighting. Etags looks like a good option, but it looks like the process for generating new tags is kind of arduous and manual (or at least not invisible). The nice thing about Etags is that they integrate well with Anything and Auto-Complete. Other potential options are gtags (though I'm hesitant to install non-elisp files, just for the complexity), vtags, or Semantic, which I've messed with before and seems complicated to set up, plus it doesn't look like it has support for PHP.
Another option is Imenu, but it only works for the current buffer, and I would like to be able to jump to function definitions in other files (preferably using Anything for completion of the name).
The projects I will be working on are not that big (about 30,000 lines total), so the overhead of Etags probably won't be that big of an issue, but I'd rather not use it if there is a better solution.
So what is your preferred PHP editing system?
In addition to features you are already familiar with, I suggest you the followings.
ETags
I do not use ETags, but there is a question already on SO How to programmatically create/update a TAGS file with emacs. No good answer was posted, though, but it may be a good entry point to get an idea.
Debugging
Flymake is a mode to get on the fly syntax checking. It has support for PHP as well. It hints at syntax errors immediately as you type. The Flymake version shipped with Emacs 23 contains PHP support. If you have previous version, check Sacha Chua's post on Emacs and PHP: On-the-fly syntax checking with Flymake.
Another useful package is Geben that allows you to debug your scripts interactively. For PHP, you can use XDebug. There is a detailed tutorial on how to do that, see Debug php in emacs with geben.
Documentation lookup
PHP Mode has a nice feature to lookup the function's definition in PHP's manual in your web browser (M-x php-search-documentation or C-c C-f). You can combine it with Emacs-W3M to get the relevant manual page without leaving Emacs.
web-model.el (available on web-mode.org) handles pretty well php blocks embedded in an html document. This major mode will also highlight js and css parts.
As an alternative to ETags, consider GNU Global, aka "GTags". Global is a lot smarter about finding tags tables, and is fairly fast to update. Emacs-fu has a nice post about doing this on-the-fly.
BTW, if you're using the Windows port of GNU Global with a Windows Emacs build, use the DJGPP ("DOS") version. The MinGW ("Win32") build seems to have a problem with path names.
In addition to the answer given on May 28 '09, I think I can add some packages to it which enhanced my PHP experience on Emacs.
Auto-completion
ac-php is in my opinion a good additions to Etags. All references to a tag will be found with etags, but the definition with ac-php. ac-php is also configurable to which directories should be included. For example, while developing a wordpress plugin, you can add a reference to the directory containing the wordpress files in .ac-php-conf.json (which resides in the project root) and it will auto-complete, jump to reference, etc. This package supports company-mode and auto-complete.
Here's an example configuration of ac-php:
(use-package ac-php
:ensure t
:bind (:map
php-mode-map
("M-+" . ac-php-find-symbol-at-point)
("M-]" . ac-php-location-stack-back)
("<menu> r" . ac-php-remake-tags)
("<menu> R" . ac-php-remake-tags-all)))
Another option would be to use phpactor, but the Emacs interface is at the time of writing still in alpha stage, with which I also hardly have any experience - except for the constructor completion, which works pretty well.
Error checking
In addition to syntax errors, Flycheck supports phpMessDetector and phpCodeSniffer out of the box. This enables you to have more enhanced notice/warning/error reporting based on supported coding standard and best practices.
Another package I like for static analysis is PHPStan Emacs interface, which reports potential errors in your code (including incorrect type hints).
Additional formatting
I also use phpcbf (which apparantly is archived). This package formats the buffer into the wanted coding standard.
Semantic
For anyone in the dark, Semantic is a built-in Emacs package and provides IDE like features. Here's an example how to include semantic for php-mode:
(add-hook 'php-mode-hook (lambda ()
(require 'semantic/symref/grep)
(add-to-list 'semantic-symref-filepattern-alist '(php-mode "*.php" "*.inc"))
(semantic-mode)))
Imenu
For including imenu jumping to definitions, another example configuration:
This is the sidebar for jumping to in-file methods and functions.
(use-package imenu-list
:ensure t
:config
(setq imenu-list-focus-after-activation t)
:bind (:map php-map
("<menu> \\" . imenu-list-smart-toggle)))
Example config for helm support in jumping to definitions in all project files:
(use-package imenu-anywhere
:ensure t
:after helm
:bind (:map php-map
("<menu> |" . helm-imenu-anywhere)))
Additional debugging
Besides geben, I like to use psysh, which by dropping in eval(\Psy\sh()); gives a repl on that line of code and gives access to all definitions and whatever else one would have access to (ofcourse, after requiring it in composer).
More generally handy packages
Snippets
Maybe a bit obvious for everyone already experienced with Emacs, but yasnippet is also very handy for writing your own templates. There are also packages that include a lot of predefined templates for all sorts of languages, but I write my own to keep Emacs a little less bloated than my set-up already is, it also helps me remember them more easily.
Project management
Excuse the obviousness again, but Projectile is also a very good package which by default includes git support for scoping the project.
Offline documentation
If you use Zeal for offline documentation browsing, there's also zeal-at-point. Example configuration, if you use, lets say: PHP, CodeIgniter and WordPress:
(use-package zeal-at-point
:ensure t
:bind (("<menu> z" . zeal-at-point))
:config
(add-to-list 'zeal-at-point-mode-alist '(php-mode . ("codeigniter" "wordpress" "php"))))