I was having some problems with a flash file that requires an external xml file so it can render random data…
Everything was working fine, except when it was in a cake app… long story short,
I found this post about PHP Proxy Script for cross-domain requests which had everything I needed.
<?php
// PHP Proxy
// Responds to both HTTP GET and POST requests
//
// Author: Abdul Qabiz
// March 31st, 2006
//
// Get the url of to be proxied
// Is it a POST or a GET?
$url = ($_POST['url']) ? $_POST['url'] : $_GET['url'];
$headers = ($_POST['headers']) ? $_POST['headers'] : $_GET['headers'];
$mimeType =($_POST['mimeType']) ? $_POST['mimeType'] : $_GET['mimeType'];
//Start the Curl session
$session = curl_init($url);
// If it's a POST, put the POST data in the body
if ($_POST['url']) {
$postvars = '';
while ($element = current($_POST)) {
$postvars .= key($_POST).'='.$element.'&amp;amp;amp;amp;amp;amp;amp;amp;amp;';
next($_POST);
}
curl_setopt ($session, CURLOPT_POST, true);
curl_setopt ($session, CURLOPT_POSTFIELDS, $postvars);
}
// Don't return HTTP headers. Do return the contents of the call
curl_setopt($session, CURLOPT_HEADER, ($headers == "true") ? true : false);
curl_setopt($session, CURLOPT_FOLLOWLOCATION, true);
//curl_setopt($ch, CURLOPT_TIMEOUT, 4);
curl_setopt($session, CURLOPT_RETURNTRANSFER, true);
// Make the call
$response = curl_exec($session);
if ($mimeType != "")
{
// The web service returns XML. Set the Content-Type appropriately
header("Content-Type: ".$mimeType);
}
echo $response;
curl_close($session);
?>
Go to your action script file and modify your content_xml.load:
Lately I’ve been working with phpUnderControl and I think it’s a very cool project… the problem is that it doesn’t support Simpletest (which is the default test suit for Cake…)
Searching for a solution, I saw this Drupal patch that pretty much let you run simpletest with phpUnderControl on Drupal apps.
So I started hacking on it so it would work on Cake apps… and after a while, I got it work a bit… however, there are still some simpletest configurations requirements that I haven’t been able to figure out…
So, if someone else is interested in running simpletest with phpUnderControl and would like to contribute with some code, I uploaded what I have so far on github…
There appear to be a lot of misguided people claiming all sorts of things you have to do to get CURL to work on a Windows-based XAMPP install. However it’s really quite simple.
– uncomment extension=php_curl.dll in your php.ini file, then restart Apache1.
NOTE: As of the 1.7.0 release, the php.ini file is found in /xampp/php/php.ini.
The storage-engine is what will store, handle, and retrieve information for a particular table.
Advantages of InnoDB
InnoDB should be used where data integrity comes a priority because it inherently takes care of them by the help of relationship constraints and transactions.
Faster in write-intensive (inserts, updates) tables because it utilizes row-level locking and only hold up changes to the same row that’s being inserted or updated.
Disadvantages of InnoDB
Because InnoDB has to take care of the different relationships between tables, database administrator and scheme creators have to take more time in designing the data models which are more complex than those of MyISAM.
Consumes more system resources such as RAM. As a matter of fact, it is recommended by many that InnoDB engine be turned off if there’s no substantial need for it after installation of MySQL.
No full-text indexing.
Advantages of MyISAM
Simpler to design and create, thus better for beginners. No worries about the foreign relationships between tables.
Faster than InnoDB on the whole as a result of the simpler structure thus much less costs of server resources.
Full-text indexing.
Especially good for read-intensive (select) tables.
Disadvantages of MyISAM
No data integrity (e.g. relationship constraints) check, which then comes a responsibility and overhead of the database administrators and application developers.
Doesn’t support transactions which is essential in critical data applications such as that of banking.
Slower than InnoDB for tables that are frequently being inserted to or updated, because the entire table is locked for any insert or update.
The comparison is pretty straightforward. InnoDB is more suitable for data critical situations that require frequent inserts and updates. MyISAM, on the other hand, performs better with applications that don’t quite depend on the data integrity and mostly just select and display the data.
Comparison
MyISAM in most cases will be faster than InnoDB for run of the mill sort of work. Selecting, updating and inserting are all very speedy under normal circumstances. It is the default engine chosen by the MySQL development team which speaks to its integrity, reliability, and performance.
InnoDB, or the OSX of the database-engine world, has emerged with some nifty features and created a niche for itself very quickly. Boasting features like row-level locking, transaction-safe queries, and relational table design are all very temping. The first two features really shine in a table that is constantly getting hammered like a logs, or search engine-type table. Since queries happen in the blink of an eye (faster actually) table-level locking(MyISAM) is sufficient in most other normal cases.
InnoDB recovers from a crash or other unexpected shutdown by replaying its logs. MyISAM must fully scan and repair or rebuild any indexes or possibly tables which had been updated but not fully flushed to disk.
REMEMBER!
It’s OK to mix table types in the same database! In fact it’s recommended and frequently required. However, it is important to note that if you are having performance issues when joining the two types, try converting one to the other and see if that fixes it. This issue does not happen often but it has been reported.
This will link to prototype.js, scriptaculous.js and jquery.js respectively as long as there in app/webroot/js.
Put echo $javascript->link($jslibraries); into the head of your layout and you’re done. You have all three JavaScript libraries at your disposal.
Note: I had some problems with the path in general since windows uses “\” and the web server uses “/”… considering this slashes issues while troubleshooting could be a time saver!
I’ve being playing around with the Apache Ant tool and definitely WAMP server was not up to the challenge. I started having several issues with xdebug and Pear features in general… So, I thought about giving a try to XAMPP (which I think that the home page is king of weird… lol, any way…) it comes with much more configuration options… therefore if you” know” what you are doing I think is much better!
Well, firs problem was that I Got the following error on running pear.bat from command.com.
The PHP_PEAR_INSTALL_DIR is set to ='c:\wamp\php\php5.2.6'. you need to change the path in the environment variables or change it in pear.bat file.
I tried deleting the environment variables from my 2008 server System (pretty much the same as vista) & restarted. But no luck!
Then again deleted the environment variables I created and logged off and on my computer…then again ran pear.bat from command.com…now got the initial error again:
C:\Documents and Settings\ Administrator\pear
PHP_PEAR_INSTALL_DIR is not set correctly.
Please fix it using your environment variable or modify
the default value in pear.bat
The current value is:
C:\wamp\bin\php\php5.2.6\pear
go-pear.bat still gives me the same error:
C:\xampp\php>go-pear.bat
ERROR: manifest length read was "1236" should be "678716787"Press any key to continue . . .
Then I tried adding them using DOS SET command, though found that its a temporary command. Then added them through right click “computer” > System > Advanced > Environment variables…
Ran pear.bat….it ran this time w/o any errors & this was the output, which made me realize that the env variables are being taken from some file located elsewhere in the C:\ drive.
So I deleted all these files outside of my XAMPP directory > restart > and that was it… I can now use pear with out a problem and configure XAMPP however I want to…
In this second part, I will setup phpUnderControl (using Git for source control) and the installation of all the necessary software… Plus I will make reference to a couple of good tutorials on how to set up a PHP apps to work with Capistrano for deployment.
However, I changed some things… such as, using Git instead of SVN and a bit more specific on certain areas that gave me some trouble…
In any decent sized project, the more times you commit code, the bigger the chance is that you will break something. Call it the law of unintended consequences or the butterfly effect, but the fact is that in complex systems, we cannot anticipate all the effects of a change. To deal with this we can either adopt the “release and pay” method of software control, or we can setup systems to help us find the consequences of our actions, so we that can correct them before they become a problem. We usually call these systems Continuous Integration systems.
In this article, we will look at how to set up a Continuous Integration system for PHP using phpUnderControl. After reading this article, you should have a good understanding of the pieces involved in a Continuous Integration system and be able to set up and run your own.
What is Continuous Integration?
Thoroughly explaining Continuous Integration would require an article of its own or possibly a whole book. A good one-sentence definition of Integration is “Delivering a working system”, so Continuous Integration means “Continuously delivering a working system”; after every change made to the code the system can be proven to work.
Obviously, manually deploying and testing a system after every change is a very tedious job; however tedious jobs are what computers are really good at, and Continuous Integration systems are the programs that can do the work for us.
It can run unit tests, generate the API documentation, check the code for compliance with coding standards, and present you with a web interface to review the results. It can even turn on the lights.
Setting up phpUnderControl
For this tutorial, we will use Ubuntu Server as the reference platform, but the instructions should translate easily to other Linuxes, BSDs or even Windows. You should have a dedicated machine available, but if you don’t, it is possible can also install it on a machine used for other tasks.
As mentioned above, phpUnderControl is an add-on for CruiseControl, which is a Java application, so we install that first:
sudo apt-get install sun-java6-jdk
PHPUnit needs xDebug to generate the code coverage reports:
You can also, rather than including the xdebug.so extension in your php.ini file, it is probably more appropriate to create an .ini file specifically for this extension in /etc/php5/conf.d/xdebug.ini. The file can be as simple as:
If you use the -E option, you retain your own environment variables. You need the JAVA_HOME for cruisecontrol.sh to work properly. You can also run cruisecontrol.sh as a regular user, but then you have to make sure you own the whole CruiseControl tree: (Don’t do this while CruiseControl is still running.)
sudo chown -LR user:user /opt/cruisecontrol
The -R option makes the command recursive. This ensures that the ownership of the link is changed along with all files beneath it. The -L options ensures that if there are symbolic links to directories that they are traversed also.
Configuring phpUnderControl for a sample project.
We can now fire up a browser and go to http://[ip-address of ci server]:8080/cruisecontrol and it should show something like this:
Don’t worry if you see error messages in the ‘coverage’ and ‘metrics’ tags about missing files in the ‘artifacts’ directory. The configuration of the installed example project is not quite correct. You can find a fix here.
We can now stop CruiseControl with:
kill `cat /opt/cruisecontrol/cc.pid`
Setting up a new project
Now you’re ready to set up a new project. In this example I will assume that you already have a working Git project which you can clone… after following the previous tutorial about Gitosis, most likely your project repo is in /home/git/repositories/. For this example we will call this project ‘my_project’.
If you already have a project with some PHPUnit tests perfect, use that! if not, copy this two files in your "my_project" directory
Calculator.php:
<?php
Class Calculator
{
public static function Add($a, $b)
{
return $a + $b;
}
}
CalculatorTest.php:
<?php
require_once 'PHPUnit/Framework.php';
include 'Calculator.php';
class CalculatorTest extends PHPUnit_Framework_Testcase
{
public function testAdd()
{
$this->assertEquals(3, Calculator::Add(1,2));
}
}
In order to add a new project to CruiseControl you have to do three main things:
Create a project configuration.
Set up a directory structure.
Add the project to the main configuration.
Cruisecontrol projects live in the subdirectory projects/ in the cruisecontrol/ directory, so the first step is to create a project directory:
cd /opt/cruisecontrol/projects
mkdir my_project
cd my_project
Then make a build.xml file there with the following content:
[/source]
The structure of a project section of build.xml is always the same, a target element with a name attribute that contains an exec element.
The exec element has an executable attribute that points to the program to run and a dir attribute that determines the directory in which the program is executed. Within the exec element is an arg element that holds the command line argument.
A detailed description of the build.xml file can be found here.
This file lists all the steps needed to get a working system to test. Each step is called a ‘target’, and a target can depend on other targets to be finished before they can be executed.
The first step is to update the code:
This will run ‘git pull’ (similar to ’svn update’) in the projects/my_project/source directory. To get our project files there, we need to a checkout first:
Ant is the program that actually runs the builds. The output should look like
this: </p>
checkout:
[exec] At revision 1.
BUILD SUCCESSFUL
Total time: 1 second
Now we can add the other targets:
PhpDocumentor:
<target name="php-documentor">
<exec executable="phpdoc" dir="${basedir}/source">
<arg line="-ct type -ue on -t ${basedir}/build/api
-tb /usr/share/php/data/phpUnderControl/data/phpdoc
-o HTML:Phpuc:phpuc -d ."/>
</exec>
</target>
An explanation for the various arguments can be found by typing
phpdoc -h
The -tb argument makes sure phpdoc uses a template that looks good with phpUnderControl. Phpdoc stores its output in the build/api directory, which you will have to create manually in the my_project/ directory.
mkdir -p build/api
And as with the checkout target, you can check if it is correct by using Ant again:
This target puts its output in build/logs and build/coverage, which also have to be created manually:
mkdir -p build/logs build/coverage
The failonerror=on is needed to signal a failed build when phpunit returns an error. (It returns an error whenever it detects failed test). The command line arguments for PHPUnit are covered extensively in the PHPUnit documentation.
The command line arguments are documented in the php-codesniffer manual. A particularly useful parameter is –ignore, which gives you the option to ignore certain files when sniffing the code. Very useful if you have included external code which does not comply to your standards.
The central configuration file for CruiseControl is config.xml, which in our example can be found in /opt/cruisecontrol/config.xml For a detailed overview of the options available for this file, check the Cruisecontrol documentation. I am going to configure our project so that it periodically runs the build, even if nothing has changed.
First, rename the old config.xml file and replace it with an empty config.xml file:
The buildafterfailed=false attribute tells CruiseControl not to attempt a build if the previous one has failed and no changes have been found. If your tests depend on an external source that can fail, like a SOAP service or a database, it might be useful to set this value to ‘true’.
In the schedule element is a list with tasks to do on each build. In this case, run Ant on the build.xml file we just created. The ant element also has an optional target attribute, where you can choose the target to build. The interval attributes specifies how many seconds to wait between builds. To enable the front-end to show the status of the build, we have to add a listener:
The listener element holds elements that can communicate the status of the build to other parts of the system. In this case the currentbuildstatus puts the status in an HTML snippet that the CruiseControl webserver can read.
Now we need a place to put all the information gathered during the build process:
The two arifactpublishers take the information from the build and puts them in a publicly accessible directory. The first one takes the files from build/api, which holds the api documentation generated by phpDocumentor. The second one is for the code coverage information. The execute element generates the nice-looking graphs for your manager.
If you start up your browser go to http://[ip-address of ci server]:8080/cruisecontrol And click on the my_project link, you should see something similar to this:
Now we’re going to change the configuration file to only do the build after we have made change in the code.
The quietperiod attribute tells CruiseControl to wait with running a build for a minute after the last change to the repository. This gives you the opportunity to commit parts to the code without running the risk of breaking the build while you are still busy committing.
If you now run CruiseControl for a while, you will see that the last build time will not change. When you make a change to the code, commit it and wait for a minute or two, you will see that a new build has been run.
Two nice features
In this section I will briefly describe two of the very many nice features available in CruiseControl, sending out an email when things break, and setting up and tearing down a database.
Sending mails when things break
You can make CruiseControl send an email on build failure by adding a publisher to config.xml:
This is how the phpUnderControl admin dashboard looks like, very nice!
You now have a working Continuous Integration system. Systems like this always take time to get setup and working properly. Now however, you have a powerful tool that will help you create better software faster. The return on investment in your time will be stable code and your client’s confidence in your work. Go and play around with phpUnderControl and discover more of its features and uses; spend the time to understand the system and customize it for your specific needs. The time you spend will be well worth it when you go to roll your next version into production.
If you are interested in Continuous Integration and want to read more about it, Continuous Integration by Paul M. Duval is a very good book on the subject.
phpUnderControl: for source controls (Git), custom continuous builds, notifications schemes, documentation, code sniffing, etc… Plus Capistrano: for deployment (Part 2)
Ubuntu server configuration: (Ubuntu Jaunty Jackalope (Ubuntu 9.04))
Most of the how-to is a compilation from various how-to’s I used… (Check them for further reference)
First, I pretty much follow this tut till page # 3:
Now that we have a fairly simple and stable environment I prefer to configure Git and the SSH requires just in case something goes wrong it wouldn’t be such a pain to reinstall everything…
I pretty much only installed openssh-server and set up the keys so I don’t need to use password authentication (which is a requirement for Git). Don’t continue if you don’t have this set up because that’s why I was talking about reinstalling the whole thing again…
Step 1: Install Git. You’ll have to do this ON BOTH YOUR SERVER AND LOCAL MACHINE. If you’re running a different OS for your client find and check out instructions for installing git on that OS instead. See this link for OS X if you don’t have Mac Ports.
Step 2: Set up the server. We’ll have to do some work on the server. We’re going to use Gitosis which needs python and a python setup tool to get running. Grabbing the python setup tool in Debian/Ubuntu will grab all the requirements if you don’t already have them:
sudo apt-get install python-setuptools
Step 3: Gitosis. Now it’s time to get Gitosis. For the most part I followed the instructions on scie.nti.st, so full credit and many thanks to them. Once you’re done with my instructions, I recommend you go visit them and read more details on adding users and some other advanced topics.
From your home directory on your server, create a new directory called src, and from there grab the gitosis code.
mkdir ~/src
cd ~/src
git clone git://eagain.net/gitosis.git
Install it using the python setup tool we grabbed earlier.
cd gitosis
sudo python setup.py install
Step 4: Setup some security. We’re next going to add a new user called git. This is the guy that will do all the heavy lifting for us!
IMPORTANT: If you have locked down ssh, don’t forget to go into your /etc/ssh/ssh_config file and add git to the list of Allowed Users that can login. That list of users is separated by a space not a comma.
I always encourage the use of public/private key exchange and in the case of gitosis it looks to be required. Generate a key if you haven’t already. See instructions for public/private key here. I’m going to assume that from this point on you can access your server from your local machine using a public key exchange!
Next, copy your id_rsa.pub file over to your server somewhere (in our example we’re using /tmp) and then run this command:
sudo -H -u git gitosis-init < /tmp/id_rsa.pub
You’ll see output like this:
Initialized empty Git repository in ./<br />
Initialized empty Git repository in .//source]<br />
Others have reported seeing that 3 times but when I did it on Ubuntu Hardy Heron I only saw it twice.<br />
<strong>Step 5: Minor permissions tweak.</strong> Just in case, let's make sure permissions are set correctly: <br />
[source='bash']sudo chmod 755 /home/git/repositories/gitosis-admin.git/hooks/post-update
We’re now done with the server config! From your local machine, test it out with this:
git clone git@YOUR_SERVER:gitosis-admin.git
If all went well you have a gitosis-admin directory with a gitosis.conf file and keydir directory. We’re basically setup now. We just need to create a new repository and push it to the server.
Also, as promised here are some resources: (I added a couple more)
PhpMyAdmin is a very famous MySQL management software package. To use it you should install and configure PHP, Apache and php mysql (or mysqli) extension see ApacheMySQLPHP for instructions.
Install phpMyAdmin from the Universe repository see InstallingSoftware for detailed instructions on using repositories and package managers.
From console:
sudo apt-get install phpmyadmin
If you’re using Ubuntu 7.10 (Gutsy) or later select Apache2 from the "Configuring phpmyadmin" dialog box.
To set up under Apache all you need to do is include the following line in /etc/apache2/apache2.conf.
Include /etc/phpmyadmin/apache.conf
If you are using Ubuntu 9.04 (Jaunty), there is no need to modify /etc/apache2/apache2.conf as the package installer already copied the file phpmyadmin.conf into /etc/apache2/conf.d directory. You can also skip the set up step and go directly to http://<hostname>/phpmyadmin and login with the user and password you set up during install.
Once phpMyAdmin is installed point your browser to http://localhost/phpmyadmin to start using it. You should be able to login using any users you’ve setup in MySQL. If no users have been setup, use admin with no password to login.
Should you get a 404 "Not Found" error when you point your browser to the location of phpMyAdmin (such as: http://localhost/phpmyadmin) this is likely caused by not checking the ‘Apache 2′ selection during installation. To redo the installation run the following:
sudo dpkg-reconfigure -plow phpmyadmin
Then select Apache 2 for the webserver you wish to configure.
If this does not work, then you can do the following to include the phpMyadmin-shipped Apache configuration into Apache:
If you get blowfish_secret error: Choose and set a phrase for cryptography in the file /etc/phpmyadmin/blowfish_secret.inc.php and copy the line (not the php tags) into the file /etc/phpmyadmin/config.inc.php or you will receive an error.
If you get a 404 error upon visiting http://localhost/phpmyadmin: You will need to configure apache2.conf to work with Phpmyadmin.
sudo vim /etc/apache2/apache2.conf
Include the following line at the bottom of the file, save and quit.
Include /etc/phpmyadmin/apache.conf
These are the steps I followed in order to get cakephp working on my user public_html folder. (Source)
as many of you probably know, if you have apache’s userdir module loaded, you can put your web pages on /home/user/public_html , and access them with the url: http://localhost/~user/ . I really prefer this, so all my web pages are on my personal home, but how to configure cakephp to work with these paths, i got a hard time with this, but finally got it!. here’s how:
You need the rewrite module also… (this could be done with the same method used for userdir)
sudo a2enmod rewrite
Now lets edit some apache files…
sudo vim /etc/apache2/sites-enabled/mysite
Inside the first two <directory></directory> tags, change the AllowOverride lines:
<Directory />
Options FollowSymLinks
AllowOverride All // change here
</Directory>
<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride All // change here
Order allow,deny
allow from all
# This directive allows us to have apache2's default start page
# in /apache2-default/, but still have / go to the right place
#RedirectMatch ^/$ /apache2-default/
</Directory>
Do the same on /etc/apache2/mods-enabled/userdir.conf
<Directory /home/*/public_html>
AllowOverride All // change here
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
</Directory>
Now you need to restart you apache2 server…<
sudo /etc/init.d/apache2 restart
I’ll assume you’ve already downloaded cakephp latest release or that you know where you can find it
Unpack the downloaded file in /home/user/public_html/
rename the extracted folder (thats the name of your application)
We’re at a unique moment in history, says UK Prime Minister Gordon Brown: we can use today’s interconnectedness to develop our shared global ethic — and work together to confront the challenges of poverty, security, climate change and the economy
You can execute phpDocumentor directly from Aptana or Eclipse. The project you would like to document needs to be open.
1. Open the ‘External Tools’ Dialog through ‘Run -> External Tools -> External Tools…’
2. Click the ‘New’ button and enter the following data:
Name: You can give any name, such as ‘phpDocumentor’.
Location: Path to your php.exe file including the file name ‘php.exe’.
Working Directory: Path to your phpDocumentor installation directory.
Arguments: Enter any parameter according to the phpDocumentor manual. At least the parameters -d, -t und -o have to be set. -d <PathSource> stands for the directory or files you want to document, whereas -t <PathTarget> should lead to the directory where the documentation should be stored. The parameter -o sets the template you want to use.
Important: All paths used in arguments containing spaces need to be enclosed in double-quotes.
You can build the project documentation using the command-line script phpdoc, or a Web-based interface. To begin, download the latest version of PHPDocumentor from the website, extracting it to a protected area of your web document root. Then navigate to the index.html file located in the PhpDocumentor directory. You’ll see several tabs at the top of the interface, including Introduction, Config, Files, Output, Options, Credit, and Links. Feel free to browse each tab to get an idea of their purpose, however for the purposes of this example you’ll need to be concerned with only the Files and Output tabs. Navigate to the Files tab, depicted in Figure 1.
Figure 1. The Files Tab
Note that you can specify input files in four manner: by file, by directory, files to ignore, and by package. I’ve added the directory containing the sample1.php and sample2.php files. Next click on the Output tab, depicted in Figure 2.
Figure 2. The Output Tab
The Target field is used to specify the documentation destination directory. The Output type dropdown lists the variety of templates and documentation types available to you. Throughout this tutorial I’ve usedHTML:Smarty:default. Feel free to experiment with other formats. Add a target directory and press the create button located to the lower-right of the window. You can scroll through the output appearing in the lower frame to review PHPDocumentor’s actions. Assuming all goes okay, the output will conclude with "Operation Completed!!". Review your documentation by navigating to the target folder.
Recent Comments