There appears to be a Validate package in Pear that I'm interested in useing in production. Our site has about 20M uniques across 10 languages, so as part of due diligence, thought I'd asked around here.
Does anyone have any experience with this PEAR package?
Is it ready for production?
Here's the Validate package in question:
http://pear.php.net/package/Validate
Intro:
http://pear.php.net/manual/en/package.validate.validate.php
Bugs (only 78 ever filed...)
http://pear.php.net/bugs/search.php?cmd=display&package_name[]=Validate&status=All
I'd strongly advise against integrating the PEAR code you use into your own code-base.
What happens then if a new version of one of the PEAR packages you use is released to fix security issues and there are multiple dependencies from that package onto others?
Do you download the new versions and check everything works ok and that you've not added a bug yourself by missing something?
The best thing to do, if you are paranoid of the system-wide PEAR install being compromised, is to make your own PEAR install. http://pear.php.net/manual/en/installation.shared.php would be where to start for doing this.
Then it's just a case of doing $pear upgrade [Package] rather than copying loads of files around.
The validate functions have been around a long time - some since 2003. I wouldn't worry too much about the beta tag, but I am still paranoid about code - so write tests for yourself, and don't upgrade the PEAR library on your systems without testing.
Even better - consider integrating the PEAR code you use into your own code-base rather than depending on the system PEAR library that can be upgraded separately.
you can make your own pear install (ie one that isn't system wide) - so you don't have to worry about any interdependencies when you upgrade - let the pear installer figure that out for you.
this is better than simply copying the code of pear packages into your own repo - what would you do if you miss a cricual bug fix released after you've inserted those pear packages that you're using into your revision control system?
honestly the validate package should be taken out of beta - it's been stable other than in name for a very long time.
Judging by the revision number and the revision title. (0.8.2 (Beta)) i would say no. Personally i would advice against using any Beta product in production, though there are many cases that it worked out fine (stackoverflow for example). Though you are always running a risk of something happening.
Related
I have been compiling PHP for years with the configuration options I want. I compile extensions I use from source. Is there an advantage to doing this versus installing it from a package manager like apt-get or yum. I assumed it would also give me a leaner binary. I noticed that their are PHP modules in the repos such as "php53-gd". What if there wasn't a package available for something I wanted such as cURL for PHP?
I understand the disadvantages of compiling such as needing to download/install dependencies based on my configuration options. I'm not really concerned with that.
So the question is:
Compile PHP on Linux or just use apt-get / yum? Can I get all the things I need from the repos? Does anyone out there still compile it from source?
Any insight is appreciated! Thanks.
I compile from source every time. It's not hard to corral the mentioned issues with regards to compiling manually. For example, my ./configure settings are saved to a file which is version controlled, so when a new version of PHP is stable and I am ready to make the switch, I download and extract the file, then run this command:
./configure `sh /path/to/my/configure/php.sh`
Not too difficult. And because it's in version control, I can add notes as to why a module was added or removed.
Another benefit of manual compilation is it allows me to keep the PHP footprint as minimal as possible. I pass the --disable-all flag, then add the modules I need. However, there is a downside to this minimalist approach, recently I needed to install Magento, so I had to recompile with --enable-hash and --with-mcyrpt flags. Even though I needed to add new flags, it wasn't difficult to add to the configure file and recompile.
Compiling from source has a few quirks:
There are hundreds of config parameters and flags. And you might not know the optimal ones that need to be used.
if you rely on apt-get's PHP, then you can be assured that you will get the latest patches and security updates if you set up auto-upgrade on your server.
the configuration of php.ini varies a lot. Sometimes your OS may decide some defaults for you which may work better with the rest of the system.
installing extensions like xdebug or other packages are a lot easier with apt.
However, it's worth compiling php from scratch if you want to learn. Also if you don't use some portions of it, you can always disable them in configuration - but then again it might not make much difference to performance.
I compiled php for specific needs only, like :
very small hard disk space so required a minimalist php version
and/or
need only a few specific modules or extensions
and/or
needed for a specific application
and/or
needed to optimize performances: when compiling on the machine where it's used, this allows some performance improvements, if using compile options to get a real tuned version for your system,
and/or
needed multiple and different php versions on the same machine.
and/or
I had a specific nux distro like only a busybox, so no other options than compiling.
But for common usage, e.g. in 80% of the cases, it's not worth spending time to compile and better using the repository version. But I learned a lot by compiling.
Personally, it's a matter of opinion. If you are in a hurry, apt-get it, if you have time to learn and possibly need to reinstall 20 times...compile it.
There are tons of guides out there for PHP compiling. It has a ton of flags for configuration, especially for GD and other libraries. Personally if this is for learning and development, just get LAMP or use apt-get...especially if you need to use Apache
I feel the primary reason for compiling is to have latest version binary (stable or nightly). package managers (most distors) are often annoyingly slow in this respect.
The other reason is that its very common problem that production systems are not wholesale upgraded using package managers. Even if that can be easy. Since package managers create dependency chains and you may not want to upgrade those items. So just to pick one item, compiling is an option. It keeps everything else as it is. You ofcourse have to always study the upgrade issues and make sure nothing else will fail.
As the title states, I am having considerable problems in installing the Zend Framework through PEAR. After spending most of the day on this I'm quite surprised and frustrated with the lack of documentation, so as a result I was hoping the community would help me out.
Today I decided to change from XAMPP to WAMPSERVER2.2 for my development environment. After configuring the environment correctly and attempted to install Zend, I was dismayed to find that it does not come with the PEAR manager by default (that raises the question, why the hell not???). As a result I had to go download go-pear.phar and run the install under the command prompt >php go-pear.phar. All seems to run quite well... however, after adding the Zend channel zend.googlecode.com/svn trying to install the package via pear install zend/zend I run into problems, i.e. No releases available for package "zend.googlecode.com/svn/zend" install failed.
Tearing my hair out over this... could it be that pear was installed incorrectly? Why after adding the channel would the install fail? Any advice would be much appreciated.
You're getting upset about the wrong things. I hope I can give you a few clarifications.
PEAR installer and the WAMP (Windows Apache MySQL PHP) stack of your choice are not connected in any way and it is good, if such packages let you handle your own PEAR environment independently from it.
The time of XAMPP and WAMPSERVER are over, use Zend Server Community Edition, it's so much better, more stable, easier to set up, easier to configure.
Zend Framework is just a library, it doesn't need any installation. Why don't you just download it, place it wherever you like and put it on your PHP include path?
The installation over PEAR as you describe it, works for me, maybe you don't have the latest PEAR manager. Find out which PEAR version you have installed with pear list.
The most important point is. You only need to learn about the PHP include path and you can solve this problem in no time in any environment independently of any W/L AMP stack or PEAR installation.
I know its a bit late, but in case someone else runs into the same problem, this may help:
http://code.google.com/p/zend/issues/detail?id=25
It's basically a problem with pear and cache.
I'm trying to figure something out:
I am using Ubuntu server 11.10 virtualized on Win7 (I don't think that matters but more info is better than less) to work on a Drupal 6 website I inherited and need to make significant changes to.
I want to set up a development copy of this Drupal website on my Ubuntu server so I can work without worrying about torching the production website.
I successfully got the production files downloaded and onto my machine, I got the production MySQL database exported and imported into the dev MySQL server, and I set up a symbolic link from the directory /home/myname/thewebsite.com to /var/www/thewebsite.com so I can easily access it.
When I got the website they didn't know the admin password so I dug around online and reset it in the dev db using phpmyadmin and finally log in.
When logging in and poking around the site there are lots of errors, which when googled lead me to believe that PHP 5.3 is causing them and that there are some modules in use that only work with PHP 5.2
After looking around a lot online and on stackoverflow there seems to be no easy way to install PHP 5.2 on Ubuntu Server 11.10. With no packages for 5.2 available through apt-get or aptitude what should/can I do?
1) Install 5.2 from source - how do I get it to interface with MySQL and Apache2? Also, I've never installed anything significant from source. Is there a walkthrough?
2) Replace the repositories with old ones? Will this work on 11.10? The newest instructions I found were for 10.04
3) Use already built PHP 5.2 packages for Ubuntu? Couldn't find these
4) Pay someone who knows more to do it for me? (Just kidding, this isn't really an option...)
Cheers and thanks for your help!
PHP dropped support for 5.2 in August 2011; operating system providers such as Ubuntu will not supply a version that is out of support, so you absolutely won't get an official copy of PHP 5.2 on the current version of Ubuntu (or any other OS).
If you're running an older version of Ubuntu (eg 10.04), you might be able to do it; it would still be a downgrade, because PHP 5.3 has been the default version for quite a long time now.
If you're on a newer version of Ubuntu, ie 11.10 as you state, it is going to be a problem for you.
The Drupal developers dropped the ball badly on this one. I guess it was because Drupal 7 tool so long to finish; they were expecting D7 to be out much sooner, and so they never bothered fixing up D6 to work with PHP5.3. As it turned out, this was a big mistake, because in fact D7 still wasn't officially released when PHP dropped support for 5.2.
But even so, they should have fixed it, because they're still officially supporting Drupal 6, so they need it to work with the current version of PHP. This is definitely Drupal's problem, not PHP's, Ubuntu's or yours.
But you still need to deal with it.
I found this question over on AskUbuntu.com, which gives an answer applicable to 11.04. It isn't quite 11.10 you were asking for, but it it a lot more recent than the best you'd found, so it might be helpful.
Alternatively, you could research exactly what it is about Drupal6 and your specific modules that doesn't work in PHP5.3. The language differences between 5.2 and 5.3 that can break things are not big, so I would expect any code changes required to be fairly small. You might find you can fix the code yourself. And maybe even submit the changes to the community -- Drupal is open source, after all.
Another tack you could take is to consider whether this saga represents an opportunity for you to move the site to Drupal 7?
This may or may not be feasible, depending on the modules you're using, etc, but if it is possible, it will solve the problem, because D7 is of course fully compatible with PHP5.3.
And just to cheer you up, I'll close by mentioning that PHP are on the verge of releasing PHP 5.4. Hopefully the Drupal devs will be more on the ball this time.
I'm trying to install PEAR, but I'm confused by the locations suggested.
I'm using Wampserver to run my PHP scripts, and I wanted to do unit tests. So I found PEAR.
I tried installing via the go-pear.bat file, but that didn't work.
I found out more about this here: http://blog.pear.php.net/2009/07/01/php-53-windows-and-pear/
So I downloaded the php file. The comments in the file suggest I
Put go-pear.php on your webserver,
where you would put your website
I find this a little strange. Still, I put it in the folder along with the other php files. Here's what I was presented with:
Maybe it is because I'm not very experienced with this, but I would initially believe I should put PEAR in a central location, using 1 pear install for all possible future projects.
Or is this the prefered configuration? And why?
Using a central location is the standard approach - it sometimes makes sense to have individual installs though, particularly if a speficic project requires older versions of some pear packages and would break if newer versions were installed.
Here's a pretty straightforward tutorial on how to set up PEAR on Wamp.
http://trac.symfony-project.org/wiki/HowToInstallPearOnWindowsWithWamp
You may have missed a few steps like adding PEAR to the PATH for Windows.
Also if you have a lot of problems with WAMPServer (I used to) there are alternatives like Zend Server Community Edition. http://www.zend.com/en/products/server-ce/index
I currently purchased a dedicated server hosted at iWeb and got it administered by them.
I recently asked after registration to add php_apc and php_imagick to the available libraries. It seems according to them that it is not possible as it is not supported with cPanel.
I would apparently need to do that myself... is there any risks to install those two libraries ? What kind of problem could it raise if there is any ? In case I would have to debug this myself.
Installing Imagemagick to your system in itself won't be too much of a problem.
However, adding support for it and APC to PHP may be a tricky procedure; it may be best for you to just no longer use the PHP provided by cPanel and install PHP yourself, which will go into /usr/local, and run the configure script for it yourself, compiling in whatever extensions you need. It'll mean that you'll need to keep PHP up to date yourself, but it'll also mean that you won't have all your customisations to it wiped the next time cPanel upgrades it.
If there are better suggestions I'd also be interested to hear them.