Michael A. Peters wrote:
Manuel Aude wrote:
I'm giving a PHP course next semester (3 hours all saturdays for 22 weeks)
and I just realized that PHP 5.3 is coming very soon (2 days now!). So, my
plans of teaching PHP 5.2 are starting to change, and I think it's a good
idea to teach them 5.3 already.
While the majority of the students use Windows, I'm aware that a vast amount
will be using Ubuntu/Debian (and some use Gentoo, Fedora and Arch)
distributions of Linux, so I'm hoping there won't be too many problems on
installation. I don't want to waste the entire first class fixing
installation problems, because that kills the student's motivation.
The course starts on August, but I'm preparing it during the last two weeks
of July. You think that installation packages will be bulletproof by then?
Or should I just teach 5.2 and wait for another semester before starting on
5.3? I mean, most hosts will remain with PHP 5.2 for the rest of the year,
so I'm a bit confused on what I should do.
I'm just a university student that wants to spread PHP, for I've been using
it for many years now =)
Thanks for the advices,
Mamsaac
Many hosts are still on php 5.1.x (IE RHEL based hosts).
I would be worried that many popular classes and apps might be quirky
under 5.3.
I've not played with it at all, and probably won't for some time, but
I've been bitten by that more than once.
Nice thing about 5.2.x as far as linux goes anyway, installing it is
cake from the package repositories. Using package repositories for php
installs is suggested as security fixes can be updated with ease.
As someone running a newer version of php (5.2.9) than what my distro
ships with, here are some of the issues:
A) I needed to create packages so that I could RPM install various
stuff, like Squirelmail, etc. - and get the security updates for them
from my OS vendor (CentOS or EPEL repods). So to do that, I used the
Fedora src.rpm.
B) When building php rpm's on my system, the %check portion of the spec
file (runs make test I believe) fails sometimes if there is an existing
php install. To solve that, you have to build it in mock.
C) Mock needs a lot of disk space and will download a lot of packages,
if you don't local mirror the update repositories, it can be really time
consuming. Furthermore, occasionally the build list for mock is broken
making it un-usable for package building.
I have to use 5.2.x because I need a pecl extension that does not work
with 5.1.x - and building rpm myself lets me add suhosin patch (to the
fedora spec file) but unless your Linux students want to do absolutely
everything php by source and not have anything installed from the
package managers that rely on php, I would highly suggest that they use
whatever version of php their distro of choice has in its stable
repositories.
-=-
Since you are teaching students, one pet peeve of mine that I see in web
app after web app after web app - they have an admin interface that
writes a php file which the app then parses as php. Often they even
instruct the person installing the web app to have 777 permissions of
directories and/or files within the web root.
There's a better way. Either store the configuration settings in a
database (obviously can't store database connection setting in the
database ...) or store them in an xml file, not php.
You can write and read the xml file with any number of existing php
functions. And the config file should not be in the web root, nothing
the web server can write to should be in the document root.
Applications (like Gallery and I think joomla and wordpress) often want
write permission to the document root so they can have a web interface
to install/update their modules - but it creates a security risk. It's
better to install the modules you want from a distro vendor repository
so you can keep them up to date that way, and hence, it's better to use
a packaged php install so that the dependencies are met.
Sorry for rambling, but the trend of web server having write permissions
to files the web server then executes (and often in the web root) is a
trend that needs to stop. So flunk the students that do it ;)
And how do you propose people get around open_basedir restrictions which
is common in many Plesk environments?
There is nothing wrong with having the above mentioned write access if
it is properly protected.
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
