I work in a dev environment that is currently IIS6/Server 2003 with Framework 3.5. I primarily am working in ASP.NET MVC.
I've run into a scenario where, for the solution I'm working on, I'd either have to spend weeks reinventing the wheel or integrating a PHP-based opensource project into one of the components I'm building.
I'd love to add this project to the fold, but the fact that it is based on PHP greatly concerns because of potential compatibility, security, and administration issues with running both PHP and .NET on a single IIS installation.
What are your experiences of doing this? Good? Bad? Not a big deal? Major headache?
Check the dependencies very carefully.
Many OSS php apps were not available to me because they required libs which were *nix only.
Very often its not until you download it and have a good look that it becomes obvious what those dependencies are.
Not sure if your Q hints at running .asp and .php extensions, but yes you can run them alongside - I even once managed to get .htm files that got parsed by as .asp first THEN as .php after ( btw this was old-style .asp not .net - but on IIS all the same ) .
The major issues I hit in the past may not be a problem for you:
Some PHP libraries assume you can use mod_rewrite. I used ISAPI Rewrite instead, but it was not 100% compatible.
Some libraries (or developers) assume they will run in a Unix based environment, and the file system will be case sensitive.
Apart from these, I haven't had any issue when running PHP from IIS that would prevent me from using it in a production environment.
Related
I just read the Twelve-Factor App, which looks like a pretty comprehensive set of rules to apply in a web-based application. It uses python or rails in its examples, but never php... I was wondering which factors of the manifesto can be applied to PHP projects and how?
Thanks
Short answer:
All points apply to PHP as the twelve factor app manifesto refers specifically for web apps.
PHP has a very hard time complying to twelve factor, in particular in the items 2, 7, 8 9 (as a side effect of 7 and 8) and 12 (partially). Actually that's the first really grounded argument I have heard in the whole "PHP sucks" rant that is common on the Ruby and Python communities (don't get me wrong, I think Ruby and Python are better languages, but I don't hate PHP, and definitively hate the "my language is better" rants.)
Being that said, it may be that your PHP project is not a web app or SaaS, but just a simple website, so you may just deem that twelve factor is not a need.
Long answer: A point-by-point analysis would be:
Codebase: not an issue
Dependencies: the way PEAR works goes quite against this point, as pear dependencies are installed system wide and usually you don't have a consolidated manifesto to declare them. Is also usual for a PHP setup to require you to add packages to your OS installation to get some libraries available. Finally AFAIK there isn't a tool in PHP to provide isolation like "virtualenv", "rbenv" or "rvm" (or if it exists is not popular among the PHP community) Edit: Composer (http://getcomposer.org/) seems to do the right regarding dependencies, it still doesn't isolate the PHP version, but for all the rest it should be fine.
Config: some PHP frameworks are not very well suited to do this, but there are certainly others that do well, so it's not a flaw of the platform itself
Backing Services: shouldn't be much of an issue, despite maybe having to hack some frameworks a little in order to manage the services as resources
Build, release, run: this is totally appliable to PHP as this definitively doesn't concern only "compiling". One may argue that several projects and hosting platforms on the PHP community abuse of direct FTP, etc. but that's not a flaw of PHP itself, and there is no real impediment on doing things right regarding this item.
Processes: This definitively concerns to PHP. PHP is quite capable of running purely stateless processes (the emphasis is on the word stateless), and actually several frameworks make your life easy for it. For example, symfony provides out-of-the-box session management with memcached or database storage instead of regular sessions
Port binding: Over simplyfing it, this point basically demands you to reverse proxy and have the actual webserver embedded on the app instead of being a separated component. This puts PHP in a very hard position to comply. Despite there are ways to do this (see the reply about using PHP as FastCGI) that's definitively not the most common nor the best supported way to serve a PHP app as it is on other communities (e.g. Ruby, Node.js).
Processes: This is not impossible in PHP. However several elements put PHP in a hard position to comply. Namely the lack of good support for items 6 and 7; the fact that the PHP API to spawn new processes isn't really very nice to work with; and specially the way Apache's mod_php handles their workers (which is by far the most common deployment schema for PHP)
Disposability: If you use the right tools there is nothing inherent on PHP to prevent you from creating fast, disposable, tidy web and worker processes. However I believe that since the underlying process model is hard to implement as per points 7 and 8, then 9 becomes a bit cumbersome as a side effect
Dev/prod parity: This is very platform agnostic, and I would say one of the hardest to get done right. PHP is no exception to this rule, but it doesn't have a particular impediment either. Actually most of the tools named on the manifesto can be applied to a PHP project
Logs: Having your app agnostic of the log system on the execution environment is totally doable on PHP
Admin processes: The most important flaw of PHP regarding this point is its lack of a REPL shell. Regarding the rest, several frameworks like Symfony allow you to program admin tasks (e.g Doctine-based database migrations) and run them on the same environment as your "regular" web envionrment.
Since the PHP community is evolving, it may be that it has already righted some of the wrongs mentioned.
Build, release, Run: Applicable to compiled code which is not the case in PHP. So this
point is not something you need to look at.
I don't claim any authority on this 12 factor stuff, but my read of that section is that the author would disagree. It's not just about compiling, it's about managing dependencies both in the small (the snapshot of the code) and in the large (any libraries the code uses).
Imagine you're a new dev and they say, "Okay, this is a custom php app, so...
a) The custom code is really two subprojects, which are in repo A and repo B.
b) You'll need to create a directory layout like so, and then
c) check the code for each subproject out into this subdirectory and this subdirectory.
d) You'll also need these three open source PHP libraries:
version 3.1 of library Foo,
version 2.3 of library Bar, and
version 5.6 of library Bat.
e) download them from their home project sites and unpack them, then copy them into this directory, that directory, and the other directory.
f) then you'll need to set these configurations in the external library,
g) and these configs in our two custom code projects.
h) once that's all done, tar/gzip it all up, upload it up to the QA server and untar it into htdocs.
There's no compiling going in that set of steps, but you can bet there's a lot of building.
Getting all of that set up and working is the build step.
Using tar/gzip to take a snapshot of the working build is the release step.
SCP'ing/unpacking it into the QA server's htdocs directory is the runtime step.
You might say that some of those steps above are unnecessary - the libraries should be deployed at the system level and merely imported. From the 12factors.net site I'd say the author prefers you to import them uniquely and individually for the app. It sidesteps dependency versioning problems at the cost of more disk space (not that anybody cares). There are more hassles in managing all those dependencies as local-to-the-app, but then that's the point of the build/release/runtime scheme.
It might have changed since you read it - there are a few PHP examples now, although a few of them seem like negations of the twelve-factor concept.
One of the ways that normal mod_php sites violate twelve-factor comes with VII. Port binding. From the manifesto:
The twelve-factor app is completely self-contained and does not rely on runtime injection of a webserver into the execution environment to create a web-facing service. The web app exports HTTP as a service by binding to a port, and listening to requests coming in on that port.
However, apache/php can be coaxed into this worldview with something like this:
https://gist.github.com/1398498
Not perfect, but it works for the most part. To test it out, install foreman:
gem install foreman
then run it in the directory you cloned the gist into:
foreman start
then visit
http://localhost:5000/foo
DO NOT TAKE THIS POST AS A REFERENCE, THIS WAS WRITTEN IN 2011, MANY THINGS HAVE CHANGED SINCE THEN... THE WORLD OF PROGRAMMING IS IN CONSTANT EVOLUTION. A POINT OF VIEW OF 2011 IS NOT NECESSARILY STILL VALID IN 2018.
I just read a few lines of each points and here goes my analysis of the document:
Codebase: Everyone, php or not should have a codebase even for the little projects
Dependecies: PHP uses includes and code libraries that you should always be able to port easily by simply copying the code to a server. Sometimes you use PEAR and then if the server doesn't support it, you have to copy and install pear manually. I use Zend Framework most of the time, so it's just copying the code of the framework with the ftp upload.
Config: It is common for php apps to have a writable config file that you store configurations into. Where you store it is your choice as a developer, but it is usually either at the root of your app or in a settings/config folder.
Backing Services: PHP does use backing service most of the time such as MySQL. Other common services depending on your app are twitter and facebook. You use their API to communicate with them and store/retrieve data to work with.
Build, release, Run: Applicable to compiled code which is not the case in PHP. So this point is not something you need to look at.
Processes: HTTP is stateless and is SERVED,thus, you usually have no process apart from the web server. This is not entirely true as a webservice may be bundled with applications you package with or create for it. But, for the sake of standards, you usually don't have to use processes in the web world.
Port binding: PHP doesn't apply to port binding at all because it is not a process that hooks to an address, Apache, NGinx or Lighttpd does that for you. Reading #6/7 makes me understand that a website could never be a Twelve-Factor app.
Concurrency: Again this point treats about processes which do not apply to PHP web pages. This point applies to the server serving the content.
Disposability: This point discusses about how fast a process should be. Obviously, PHP web sites not being a process shouldnt apply but always note that your website should execute pages as fast as possible... Always think about this block or that block of code and see if it is optimized.
Dev/Prod Parity: This point is crucial in any app development. You never want to have a large gap between two app versions or upgrading can become a hassle. Furthermore, never create client specific versions of an app. Always find ways to allow your app to be configured/customized at the template level so you can keep your app as close as possible to all installed versions everywhere.
Logs: Logs are always a good thing to have, they allow you to follow the process of your code without having to output it to screen. My favorite tactic is to "tail -f logfile" inside of a linux console and look at what is happening as i execute my code.
Admin processes: Not applicable, in php, you don't have processes, but you do have pages that you can secure with usernames and passwords.
I started web development some time ago, but have invested essentially all my time in learning PHP, MySQL/SQLite, (X)HTML/XML (XPath, XQuery, XSL), etc. I went with an out-of-the-box XAMPP install, everything was pretty straightforward, and I could focus my learning on languages.
Now, however, I'm looking to learn Ruby and Python (and more Perl) but to my dismay, have discovered that I know essentially nothing about Apache configuration, or any related tasks associated with setting up an environment for embedded PHP, Perl, Python and Ruby.
I posted recently a question that I thought would take me in the correct direction. Having read the mod_wsgi and mod_rails docs, I'm more confused than I was to start.
I'm running Windows 7 x64 with an existing XAMPP installation, just grabbed Ruby and Python, just installed NetBeans; and I'm wondering:
Should I start with a fresh Apache install, or is XAMPP fine to pile additional modules on?
Where can I find some information about configuring Apache to support these modules? I'm thinking step-by-step to build an environment that supports some of, all of, or more than the aforementioned languages.
I suppose my question can be summarized to; What are some suggested reading/learning resources for configuring an Apache based multi-language web application development environment?
I hope this question isn't regarded with high subjectivity or generality; I'm just lost and don't want to waste time staring blankly at configuration files or the like.
I really appreciate any insight, and forgive my noob factor. I am surprised I am as unfamiliar with this territory as I am, and quickly need to change that.
I would recommend the following:
Make your home in the Ubuntu environment within the VM you mentioned
Essentially all of the technologies you mentioned started out in Unix-based systems, and, while the playing field is leveling, there are still significant advantages to developing with these technologies in a Unix-based OS (such as the Ubuntu install you mentioned.)
Additionally, Ubuntu is very well documented online, has active forums, and has very nice install systems (apt-get, aptitude.)
Learn Nano
You can use other IDE's or text editors, but Nano is really, really easy to use, so you can focus on learning the technologies you're interested in, not a complex text editor such as vim or emacs (which are both fantastic, but learning sessions in and of themselves.)
Get yourself a cheap cloud server to pound on
Many companies offer great cloud servers. The nice thing about this is that you can play with the every aspect of the environment, including the networking capabilities, such as getting a firewall running, etc.
For instance, Rackspace Cloud Servers work great and the Wiki pages walk you through a vast number of installs and configurations (I just pointed you to the Ubuntu docs cuz that's what you mentioned already running):
Rackspace Cloud Server Wiki
Build up your web server from scratch (and keep a log of the build steps, so if something doesn't go well, you could redo things quickly.)
Start building (and breaking) your next great app
Start making a cool app using the technology of choice. If you want to focus on Ruby next, crank out an ROR app, or even dig down and use RACK to set up you're own baby framework for handling web requests:
Rack: a Ruby Webserver Interface
Or, if python is your next learning project, try out Django, or even jump down to CherryPy for a low level web server implementation that helps you see all the moving parts:
CherryPy
Join the mailing lists of the technologies you're most interested in
Mailing lists provide great insights into the strengths and weaknesses of technologies. Just joining a list to listen to the daily banter can significantly help your understanding of the technology and the challenges that you'll likely face in the future.
These are all things I've done (different language focuses, but same techniques) and they've helped me greatly. Hopefully, they help you, too :) Happy coding!
Just an additional info, XAMPP has mod_perl included since version 1.7.2.
To setup this quickly on Windows, already prepared stacks built by BitNami can help:
Ruby + Rails
Python + Django
I have an existing CakePHP that runs on a LAMP environment and need to install it on a USB drive for mass public distribution.
There are a few requirements:
Protect the source code
No installation required
Windows support essential
MAC & Linux would be a bonus
Must run offline, without Internet connection
Ability to sync with server for data transfer and updates
I have conducted a large amount of research into the options and am keen to learn what other developers think.
Potential solutions:
- Flash / XML
- Adobe AIR app
- USB webserver (Server2Go, Portable Apps XAMPP)
Has anyone used any of the above, any comments would be greatly appreciated.
Thanks
Similar thread here :
Portable USB Webserver
If you ask me, XAMPP should do, because it offers a "plain unzip" version. There's lots of variety out there - Bitnami also offers a nice bunch of stacks, although they may not be good for this particular task.
To keep the same scripts in both Windows and Linux, you could consider using UnxUtils which is a port of all common Linux commands. This will be very handy if you are good at Linux bash shell scripting but not good at Windows batch files.
Protecting the source code is a bit troublesome. Do you really, really need to do so? Because there's a ton of great open source code out there which already does practically everything in most common business domains - sourceforge.net.
And if someone's taking your code and calling it their own, you can just name them on the internet if you can prove it. That itself will be bad publicity for them. That said, I obviously don't know your specific need. So that is just my opinion.
You will have problems with this, no matter how you go about it. Each step is a little more unusual it seems.
You'll need to use a source code obfuscator to protect your source. I recommend the one by Zend, not from experience, but because Zend makes awesome products. Never used a source protector myself.
You'll need three custom LAMP/MAMP/XAMP installs, one for each target OS. They should point to a directory that is shared on the USB drive. Make sure you configure them to use an unprotected port, otherwise the user will need admin privileges to run the server software. And getting the server stuff up and running will likely result in a few hiccups as well.
I would actually recommend finding something that will allow you to distribute a binary, or something like an AIR app that is intended for this type of distribution. You may have to rewrite lots of code, but it'll be easier to fix than all the niggling little install errors you'll see on the client end. To package scripts into binaries without rewriting stuff, check out http://www.scriptol.com/apollo.php and similar products.
But I'd suggest you make a standalone app in adobe air that will sync with your server (maybe even some google gears integration, to have it function offline). Don't try to force a PHP app into this distribution model, it'll create nightmarish problems.
This is what I used to run a CakePHP app from a DVD. Worked on USB too (while I was still developing it).
http://www.server2go-web.de/
Server2Go is a Webserver that runs out of the box without any installation and on write protected media. This means that web applications based on Server2Go can be used directly from cdrom, a usb stick or from any folder on a hard disk without the hassle of configuring Apache, PHP or MySQL.
Server2Go allows you to create a standalone working web site or PHP application on a CD-ROM.
It's really nice.
You can use MAMP for Mac, you'll just need to edit the config to properly point the sites directory.
however you would have the problem that the mysql db would not necessarily work with windows. if you switched the db to sqlite, you could sync the sqlite db file fairly easily.
XAMPP would work for the windows side
sorry dont know about the linux side.
Out there is a CakePHP InstaWeb Server
http://bakery.cakephp.org/articles/view/the-cakephp-instaweb-webserver
that runs on python and doesn't need an installation. This plus some additional goodies should get you already half the way.
I am doing a clean install of OS X Snow Leopard and I was wondering what people think should go into the ideal web developer environment?
Can I get a good rundown of things you would do when setting up a clean system?
My main focus is HTML, CSS, PHP, and Actionscript work. But I would also like to dabble in other languages and frameworks as well (including Ruby and Python, Rails and Django).
The main goals
Cleanly and rationally organized
Efficient to add new frameworks, project source code and packages
Easy to disable components, frameworks and parts of the environment
Ability to host multiple projects simultaneous without too many conflicts or dependencies
Effective source control over all projects and environment configurations
Somewhat idiot proof for a non system administrator, but sufficient power to customize
Easy to isolate and debug environment configurations.
I am aware of MAMP and XAMPP. And I use Git.
I was thinking about using macports for setting up various tools and packages. I also want to cleanly manage frameworks. But I also want to be able to experiment with unknown frameworks without fear of cluttering or breaking my normal day to day working environment.
I know the command line but I am by no means a system administrator. With all that said what would you recommend for managing the hosting environment? Apart from VM are their tools for conveniently sandboxing configurations (different versions of frameworks, databases, webservers, etc) and linking these to a particular client's project code?
It seems like macports by putting everything in /opt is the way to go. I don't have to worry about mucking up the system binaries. And if I make a mistake or want to start over I can blow away /opt anytime I want to.
Are there tools to manage changes to your local web environment? For example if I install a particular package can I conveniently see "what has changed". Basically a way to do a diff on part of or even the whole system to know what implications are in place as I add new a new framework or update a package like PHP, Ruby, Perl, MySQL, Apache, etc. What about snapshots and backups of the configuration? can I version control this? If I setup PHP and Apache in a specific way to work with a specific clients hosting environment needs can I undo that configuration to quickly switch over to a different project?
Feel free to mention or link other related questions or answers if this question has any overlap. And I am not sure if this question should go on serverfault or superuser. But I am mostly interested to hear what other web developers have to offer.
Also, in particular I am curious to learn from people's mistakes. The main gist is, if you were starting over what would you do differently? Knowing what you know now?
For snapshotting entire setups including servers VM's would be the way to go. In Linux I often use chroots to isolate an install, but then the Apache ports etc are still shared.
Does using a PHP framework (CodeIgniter, Zend) require special server side setup? And if yes, is there a PHP framework which doesn't require that?
The intention would be to use a hosting server which supports plain PHP only (no framework installed - if that makes sense), and use the mentioned framework on the development machine only, which would then be preprocessed ("compiled") into plain PHP.
[Edit]
To all you guys: sorry for the newbie question, I guess I got it wrong. I have only worked in .NET so far, and I haven't done anything from scratch in PHP yet. For this small project I am supposed to do, I wanted to learn and use CodeIgniter, as it seems like a light MVC framework where I can get results quickly.
Before starting, I wanted to check with the hosting provider (from which my customer has already bought a year of hosting) said they only support Zend. So, I guess that's nonsense then?
[Edit 2]
To make my question complete, here is what their hosting package provides:
PHP 5 or PHP 4
Perl
CGI
Python
Tomcat / JSP Tomcat 5.5.9 / Servlet 2.4 / JSP 2.0
FrontPage extensions
Ruby On Rails
PHP / Zend optimizer
PHP / IonCube
Fantastico
DB: MySQL Server 5, PostgreSQL Server 8
To be precise, my question was (since I am a newbie after all):
Q: Which PHP frameworks do you support (Zend, CodeIgniter...)?
A: We support Zend, but not CodeIgniter
Now I am aware that the question itself is a bit dumb, so I might contact them again.
No php framework I know of needs any special server side setup. PHP frameworks are just that: plain PHP only, as you call it. PHP frameworks are nothing more than already written PHP code for you to build your further code on. Nothing special about it.
People sometimes ask question on 'how to install' this or that framework which derives from the same missconception that frameworks are some kind of bundled software that need complicated distributed installation routines. None of that. Just code you didnt' write yourself. And as that you just need to upload (or download) to server. Done.
[EDIT] after your edit:
I slightly doubt the competence of your hosting company. You might have a missunderstanding with them as 'Zend' often means Zend Optimizer or Zend Guard or such. As to PHP frameworks your host doesn't need to support or not support them. It is entirely up to you what PHP code you upload to that host and who has written that code.
Some hosting companies offer framework support in a way that the frameworks are already available on their servers and are updated by your host. And surely there are a few things that can be optimized like php.ini settings. But in general it will work also without these optimized settings.
I almost never accept hostings that a client has already purchased. When I write an offer I attach the strings that the hosting is chosen by me. If I'm satisfied with what the client already has, the better for him.
The only setting you need to configure for CodeIgniter is $config['base_url'] which is used for building links and form actions. Then you should be good to go, as CodeIgniter (and all other frameworks) are just PHP and nothing more.
That said, there are of course environment issues to watch out for. If you are moving from your localhost to a server with a totally different install then there will of course be things that need to be changed, such as $config['uri_protocol'] as sometimes you will get 404's, blank pages or default controller loading when you look at other pages. This can normally be fixed by flicking through each of the uri_protocol options listed just above the option. This is not very common, just something to keep in mind.
And finally of course, don't forget to chmod your writeable upload folders and keep your DB settings correct.
Take a look at my article on "how to get CodeIgniter working on different production environments" without too much faffing with db config.
See EZMVC, it does not require server-side settings/handling.
AFAIK the only thing that is not server-independent is the rewriting of links, as Apache, nginx, IIS and others, all have different rewriting engines/syntax.
I have worked on many php frameworks such as Zend framework, Cakephp, codeigniter and YII. Of these I liked YII ( http://www.yiiframework.com ) the most because it is easy to learn, purely Object oriented and works almost like the Ruby on rails framework. It also has great documentation and is very fast. Yii unlike codeigniter works on PHP 5 only which gives it capabilities like auto loading of classes.
But the only problem with frameworks are that they require configuration settings. You cant make it work without one config file atleast.
Did you try cakephp?
I am using yiiframework and I needed to do a project with php 4, so I used cakephp that I liked it too.