I've been tasked to migrate an old PHP4.3 site (using CVS version control) to a more modern 5.2 install (lower version number for compatibility issues) on a shared GoDaddy server. I've gotten through most of the issues, but this particular one is a tough nut.
Inside the administration view, there is an export to excel function which uses the Spreadsheet_Excel_Writer (0.9.3) PEAR package. However, this line keeps throwing a fatal error:
aggregate( $sheet, 'Spreadsheet_Excel_Writer_Sheet_Patch' );
where $sheet is defined by
$sheet =& $xls->addWorksheet( 'Customer Data' );
My issue is that aggregate no longer exists in PHP5, and I cannot install runkit as I do not have root permission to execute the pecl install command on the server.
I'd rather not have to rewrite the existing functionality, so is there a drop-in replacement for aggregate that I can install without requiring root permissions?
With regard to the Excel library you're using, you will need to upgrade that to a version that supports PHP5, or else migrate to an alternative library. There are several Excel libraries available which do support recent PHP versions, so you should probably investigate those.
I won't recommend any specific library now, as I haven't worked with any of them for a little while and so my recommendation may not be the best. And in any case, your needs may be different to mine. Instead, simply googling for 'php excel' will give you plenty of results to help you find a library to suit you. You will obviously need to rewrite your code where it uses the old library so make it work with whatever new library you choose, but that will be infinitely easier than trying to make the old library itself work. (also, newer libraries will support newer excel versions, which is probably quite important; things do move on)
I certainly wouldn't recommend trying to keep using the existing library; it's clearly written for PHP4, and would likely be a very difficult task to bring it up to date.
You mention runkit: that wouldn't likely be a good solution here even if you were able to use it. For something closer to what the aggregate() function does, you might want to investigate the Reflection class, which allows some similar class- and object-level trickery, but in general well-written code shouldn't need that kind of thing anyway (it may have done in PHP4 days, but much less so today).
Another alternative to aggregate() might be the Traits feature in PHP 5.4 and up. This can give some of the multi-inheritance functionality that aggregate() was sometimes used to simulate. Obviously, you'd need to upgrade to 5.4 for this though, and the actual code you'd write would be quite different.
Related
Let's say I publish a new library Foo v1.0.0 which requires php 5.6 as a dependency.
Now I would like to use some of the newer language constructs in php 7.0 internally within some of the method implementations. However, my entire public API (method names, parameters, returns, etc.) remain unchanged.
Following semver, what version number should I now release?
It seems to me that requiring a new major platform dependency will break backwards compatibility for existing users running php 5.6 who will not be able to simply upgrade with composer update so it should now be v2.0.0. On the other hand, because nothing has changed about my exposed API, I feel like this should instead just be a patch v1.0.1
No, you got wrong what backward compatibility means. If your library's API remains unchanged then it may be just new major version but it is still backward compatible, which means upgrading does not require changes in code using your library. Requiring PHP 7 is just requirement but it got nothing with compatibility.
Other projects I saw usually do major number bump but that's mostly because they only changed requirements but also did some changes to benefit from i.e. new PHP functionalities. So ask yourself if you will really benefit from just requiring PHP 7 or it will be sort of cosmetic change or code cleanup. It also depends how many users your change would really affect.
EDIT
Requiring PHP 7 is sometimes huge change as many people are still on 5.x and don't want or can't upgrade yet and while it is not the backward compatibility issue here, I'd make it 2.0.0 to clearly indicate this change as major.
I'm writing a Wordpress plugin, so it's going to be used by different users and different PHP versions. The problem is that I found that some of the functions (like json_encode) are available in PHP 5.3 and not in PHP 5.2 or less. This creates a big issue, as most users don't have the latest version.
I want now, after getting the plugin 99% done, to do the following
Test my code with some kind of an app. where I can put the minimum PHP version. That App. or program would find out functions like json_encode. Not sure if that is possible, but would probably solve most of my problem.
Is it possible to get the native code of the PHP functions in PHP. I'm not sure if they are written in PHP or not, if so where can I get them. If not, what's the best option to find replacement for these functions. Certainly, I don't want to be re-coding them from scratch
What's the best methodology to implement the functions. I found some developers that check for the PHP version, while others check if the functions exist. Which one is best and why?
Would love also to read about your deployment strategies and how you dealt with that particular problem.
2.Nope. They're provided by compiled extensions written in C. For json_encode (which BTW is available since 5.2 not 5.3) you can use Zend_Json as an alternative
3.Checking if function exist is the best if you want to be 100% sure. After all, one can be running a self compiled version of PHP with not all core functions available. Check PHP version number, to know if features like namespaces, exception chaining etc are available.
You can use PEAR's
PHP_Compat to provide missing functionality for older versions of PHP and
PHP_CompatInfo to find out the minimum version and the extensions required for a piece of code to run
If you want to provide your own userland implementations of functions or classes, you are good advised to provide them wrapped into function_exists or class_existsblocks, so they dont interfere with PHP versions providing those methods.
I don't really know how Wordpress plugins work but except if you really want your to be able to run on old PHP version, you'll need to check for available function and provide an alternative, which can lead you code to be messy.
If you can, and want to educate your users, you can simply version_compare() function to compare version against a well tested and fully functionnal PHP version and throw a educationnal and explicative message to your end users.
if (version_compare(PHP_VERSION, '5.3.0') <= 0) {
echo 'You need to run PHP 5.3.0 to use this plugin';
}
Re 1.) there may be such an application, but there also may be not. What you usually want to do is to keep close tabs on each function you use in the manual, which states what PHP version(s) are needed.
Re 2.) if a function is PHP 5.3 or 5.2 only, you will usually find a replacement suggestion in the User Contributed Notes or on Stack Overflow. (Be careful what you use though, a lot of the code in the UCN is bad - but in that case, there is usually at least one comment saying so.)
Re. 3.) it probably doesn't matter, but checking for whether a function exists is surely the safest way.
I am developing a php application which my customers will download and install on their own servers. I know the base requirements for my application (like min. php version) but is there a way to generate a list of requirements that needed to run my application on windows or unix systems?
Thanks.
You mean, generate a list of requirements based on an analysis of your source code?
While in theory, that might be possible, I don't think such a solution exists. I think there is no way than analyzing your code by hand, with the PHP manual very close by.
Do you use GD? Then you need PHP with the GD module. Do you need to create GIF images with GD? Then you need GD, but not between versions 1.6 and (I think) 1.8. Do you use PDO? Then you need PHP > 5.1.0. And so on and so on.
In short, I'm afraid think this is going to be a manual process. Manual also as in "PHP manual" - the User Contributed Notes to each function and method are a gem, and any common cross-platform problems are usually noted there somewhere.
While you can trust that PHP x.y.z has a defined set of functions and behaviour, be sure to test well before you declare something suitable to run on a different server. IIS's support of PHP is way better now, I'm told, but the last time a ported a big PHP application over to IIS, it took me three days to work around all the mysterious bugs.
Just be aware of what you are using. For example, you should clearly communicate if you need something like .. a special database binding ( other then mysql ), xml libraries etc.., or even better, create an installer that is bundled with your software that checks that kind of stuff.
Other than that, there should be no problems concerning different servers ( apache / iis / fastcgi.. ). So to answer your question: you have to generate that list all by yourself.
As others have said, you'll need to manually keep track of special libraries and functions you're using. If you need PHP4 compatibility then you won't be able to use the built-in XML libraries for example. You can also check the list of functions added to PHP 5.
One thing I would recommend is installing WampServer if you have access to a Windows machine. Aside from being good for local development, you can download modules for most Apache/PHP/MySQL versions and test combinations.
I'm trying to accomplish a task and turns out that the code I need is packaged as a PHP extension, which according to what I've been told means I have to have root access to install it (I'm on shared hosting so that's a bit of a problem.
I'll solve this problem later, but for now I'm trying to understand the difference between an extension, a library, and a class. Is it more of a packaging thing that could be overridden and repackaged a different way, or is there a valid architectural reasoning behind it?
Also when releasing your own code, what makes you decide to release as library vs. class vs. extension? or do you go with whichever sounds better?
thanks in advance.
P.S. If you must know which extension I'm talking about, it's Libpuzzle, but that's really beside the point, my question is more general.
An extension is a pice of code programmed in C which will be included into the PHP core when PHP starts. Normally you have some more native functions available after including a extension. For example a zip functionality.
A class is a abstract pice of PHP code which solves common tasks. For example sending emails. You can find some common classes at pear.php.net.
A library is a collection of PHP classes wich solve more generic tasks for example buliding HTML forms AND sending emails. The Zend Framework is a framework which consists of many, many PHP classes.
Normally extension features can be programmed in PHP. For example the PEAR::Compat class. Often you will find the functionality you need as a PHP class available. I'm sure the stackoverflow readers will supply you with ideas where to find a specific PHP class.
Extensions are low-level. Usually written in C/C++, and compiled into native-code shared libraries, they interact with the Zend Engine directly. It has pros and cons, main advantages being the speed and more control; and main disadvantages - they are harder to install, and require compilation (and that requires a compiler and PHP headers); it's not true they require root access though - you only need ability to use custom php.ini (or dl() function, but I see they deprecated it for some reason).
Libraries/classes are high-level and interpreted. If you don't know if you need to write extension, then you probably don't. About what classes are - read about OOP. A library is a reusable collection of code (most commonly in form of functions/classes).
Some libraries (including libpuzzle) also include a command-line tool. So if you're unable to use the PHP library due to your shared hosting environment, maybe you can compile the command-line tool. Then you can run it from PHP using something like exec. It will be slower and require more memory than a library, but it might get the job done. Of course, many hosts also have restrictions on commands like exec, so this might not work either.
When building some of my PHP apps, a lot of the functionality could be coded using PEAR/PECL modules, however, the fact that some people using it may not have the access to install things, It poses a puzzler for me.
Should I forsake some users to use PEAR/PECL for functionality, where these will allow me to have a system coded up quicker than if I wrote my own functionality, but eans that it will exclude certain people from using it.
It partly depends on how much time you have, and the purpose of the project. If you're just trying to make something that works, go with PEAR/PECL. If you're trying to learn to be a better programmer, and you have the time, then I'd recommend taking the effort to write your own versions. Once you understand the innards of whatever you're trying to replace, you may want to switch to the PEAR/PECL version so that you're not wasting time reimplementing what has already been implemented...
...but on the other hand, preexisting tools don't always do exactly what you need, and sometimes have overhead that doesn't do you any good. This is why Unix command-line tools are so small and narrow of purpose; nobody really needs a version of 'ls' that can do anything besides what 'ls' can currently do. Your version of whatever PEAR library will, by virtue of being written by you, do exactly what you need doing. It requires some careful thought...
...but on the gripping hand, don't spend too much time thinking about it. Spend five minutes, make a decision, and start coding. Even if you make the wrong decision, you'll at least have gotten more practice coding. :-)
Save on development time by developing with the pear libraries, and provide the libraries bundled in what you distribute (though you'll have to make sure it obeys licensing requirements)
I would not depend on certain PECL extensions being installed unless you're doing something particularly related to one (say an XDebug web-frontend or something), the majority of installs will be carrying a fairly vanilla set of extensions.
My suggestion is to start with assuming PEAR/PECL modules, and get the rest of the code done. Then, once you've got most of your code working the way you want, you can evaluate going back and piece by piece replacing the outside code with your own. Plus, by then you'll have a better idea of the impact using those has on your userbase.
Code it initially using PEAR/PECL and if you get people asking for a non PEAR/PECL version, start coding your own alternatives then for such a version.
The initial development will go much faster with this, and you may find that no-one cares about requiring 3rd party libraries once you have started releasing apps.
Use PEAR but allow for including the PEAR packages inside your project. All PEAR packages can be separately downloaded from http://pear.php.net/ and can be put anywhere. Depending on convenience and licensing issues you could then package all the required PEAR files with your project or tell users how to download and "install" them.
What I do most times is I'll never use PEAR installed globally on a server. Versions can change and affect your application.. Instead I have a config file (in my case XML) that lists all the packages required and their versions. The installer connects to my personal FTP repository and downloads and installs all the PEAR packages locally in $PROJECTBASE/lib/pear/ .. And PEAR is run locally instead of globally. Something you may want to consider.
Using PEAR is no problem, if users do not have root access to their webserver, they can simply download the PHP files from pear.php.net and add it to their include path. PECL's a little more tricky to work around, since there's often no way to install new modules without root access.
You need to watch out because a lot of modules in pear are really of pretty low quality.
Some are great, don't get me wrong, but don't assume that anything in pear, by virtue of being in pear, is at any given quality. Which means you need to at least skim the source of a pear module before deciding to use it, which for simple enough tasks may take more time than going without pear.
pecl is different, however. Extensions tend to be better vetted and tested, else they'd crash php.
Reiterating much of what's already been said: http://www.codinghorror.com/blog/archives/001145.html