SFTP stands for SSH File Transfer Protocol and it uses the SSH protocol to reliably and securely transfer files. While using sftp on Dreamweaver is not too complicated, setting it up to use a specific port is not well documented. SFTP uses the same port as SSH, the default port is 22 but it is not uncommon that you will be assigned a custom port as this is a standard practice to avoid brute force SSH scanning.

Setting up SFTP on Dreamweaver

Open up the sites manager and choose to setup a new site.

Proceed to setup the site as you normally would any other site on Dreamweaver. Once you get to the “remote setup” you will need to define the port number. The default port for sftp in Dreamweaver is port 22. If you select you want to use sftp and do not define the port number, Dreamweaver will automatically try to use port 22. To use an alternate port you must define it in the FTP Host field like this ” hostname:portnumber “. So if I want to access files on example.com using port 21324 I would put in the FTP host field example.com:21324

Once you are done, click on test connection to verify if everything is working correctly.

The symfony admin generator is a BIG time saver. It’s almost like magic, it generates an administration interface based on your database models. If you spend countless hours creating lists and forms to manage data in tables, you are crazy not to use it.

When you have HTML content in a table, the ideal is to show a WYSIWYG editor instead of the TEXTAREA where the HTML will be displayed. In older versions of symfony, TinyMCE was integrated. With the release of symfony 1.2 the approach was to decouple some of the functionality so you could use different libraries. This is a good thing, but the admin generator suffered a bit. Some things that were very easy to accomplish, became a bit too hard, one of these things is the ability to display a WYSIWYG editor.

CKEditor is the successor of FCKeditor, probably because some people to name it a “bit” differently (you figure it out) due to some difficulties when using it. What’s important is that CKEditor is an amazing piece of software. A very powerful and feature rich HTML editor that runs inside a browser.

In order to use CKEditor in a symfony 1.2 generator admin interface, follow these steps:

a) download CKEditor, and place the files in your web directory.

b) add CKEditor javascript to your apps/[yourapp]/config/view.yml

javascripts:    [/js/ckeditor/ckeditor.js]

c) edit apps/[yourapp]/modules/[yourmodule]/config/generator.yml and add the class ‘ckeditor’ to the field that will be your editor. Make sure the field is displayed as a TEXTAREA in your form (TEXT and LONGVARCHAR database types work)

config:
actions: ~
fields:  ~
list:    ~
filter:  ~
form:
  fields:
    content:      { attributes: { class: ckeditor }}
edit:      ~
new:     ~

# make sure you keep the proper indentation in your yaml code.

content is the field that contains HTML code in our example.

And that’s it! Since you are loading the javascript for CKEditor in your view configuration, it will look for any TEXTAREA with a class “ckeditor” and will replace it with a CKEditor instance.

One of the most common errors after installing WordPress on your hosting account is the “The uploaded file could not be moved” error when trying to upload a file. Typically the error message looks like this:

The uploaded file could not be moved to /var/www/vhosts/domain.com/httpdocs/wp-content/uploads.

This is a common error due to permissions. I got this error fixing a WordPress instalation on another host which, will remain unnamed, for a treasonist family member who does not use ServerGrove, who will also remain unnamed. I did some research and while reading the solutions out there I was amazed to see the amount of posts asking people to chmod 777 their entire wp-content and wp-content/upload directory. Let me say this once: it’s never a good solution to chmod 777 an entire directory.

Let’s analyze the problem to better understand what’s going on. When you create directories either via FTP or via some other method, the directory is owned by the user that created that directory. So when you upload your Wordpress via FTP the directories are owned by your user. Then when we try to upload images via the WordPress admin we are uploading via a web page we are actually uploading via http, and items uploaded through http are owned by the Apache user, master of http. So when the Apache user tried to put a file in the folder owned by your user, Linux steps in and notes there is a permission problem. You cannot put content into a directory owned by another user and spits back the error:

The uploaded file could not be moved to /var/www/vhosts/domain.com/httpdocs/wp-content/uploads.

So, the question rises, why does this happen on some hosts and does not happen on other hosting companies like ServerGrove? Well for one, we are wise, and know that permissions errors are very common and easily avoidable (kind of like acne). The solution lies in the way your shared hosting server is setup, some hosting companies slap the default installations and other wiser ones spend their waking hours fine tuning the servers and making them perform faster and work better for their clients.  Our servers are configured so Apache runs as the same user as your user (a different one for each website), this means that your user and Apache are the same which makes everyone’s life easier. This simple permission error would never happen on our servers and had my weasel family member setup on ServerGrove he would not have had to ask for my help.

I was working with SlideshowPro and could not get the images to upload. There was no error in the log files, nothing. All I got was an error message from ssp asking me to edit the .htaccess file. I did that and still no success. I checked the access log and:

[...]“POST /photoadmin/index.php?/uploads/image/3/4/1 HTTP/1.1″ 401 1516 “-” “Adobe Flash Player 10″

Finally it came down to disabling the password protection for the site. Since my site was still in development, I decided to password protect it. Disabling the password protection allowed the flash image uploader to work fine. The downside is that now my site is unprotected.

In order to install a SSL certificate on a CentOS Virtual Server, make sure your plan includes a dedicated IP address. If it does not, contact us so we can assist you with adding one to your account.

To install the SSL certificate follow these steps:

1. Create a file /etc/httpd/conf.d/cert.key and place the content of the certificate key in it. It will look like (with more lines):

   —–BEGIN RSA PRIVATE KEY—–
   MIICXgIBAAKBgQDsvYWqOtJBR+j15pCITwyM48Cp3rBArdJOsOjoFrU2CXiDpYAb
   4ZiA3CD+wTQtod+3aeRTAkEAuXfD0NSgcTYsqHS+HHUyDZifrjZBPhBNL4ONAvof
   ReXZzngKgFTGhfUm0Ypu6QVTRHit+Miv+AyY72KCUsN4/A==
   —–END RSA PRIVATE KEY—–

2. Create a file /etc/httpd/conf.d/cert.crt and place the content of the certificate in it. It will look like (with more lines):

   —–BEGIN CERTIFICATE—–
   MIIDODCCAqGgAwIBAgIDC+KlMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVT
   MRAwDgYDVQQKEwdFcXVpZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0
   UeHR9A2VwXvIbcrxYoLLFZraqI56CNwRCNIsUB9Z9k+6Y0J+A2iRo75Ws2cHPAMc
   97keASGvyDZy1w9W
   —–END CERTIFICATE—–

3. Edit /etc/httpd/conf.d/ssl.conf and change SSLCertificateKeyFile and SSLCertificateFile directives so they point to the files listed in 1 and 2.

   SSLCertificateFile /etc/httpd/conf.d/cert.crt
   SSLCertificateKeyFile /etc/httpd/conf.d/cert.key

4. Restart apache by running service httpd restart

One of the things we spend lots of time on, is trying to make application deployment as simple as possible so developers can focus on development. We are developers as well, so when we finish a project, we want to upload it, test it and start on the next project. Keep it simple, move on. Like you, we don’t like to fight with configuration, permissions and whatever other issues may delay our deployment. Most of our in-house projects are developed in symfony, so we have gotten particularly good at fine tuning our servers for this framework (not to mention it’s the best framework in the world).

As a policy, we help all our clients with migration and installation issues. A great majority of our support time is dedicated to this type of service, so the easier it is for people to install their apps, the less time we spend answering tickets. We like to call this: motivation.

While most people seem to be figuring out how to use Maestro and get their apps up and running on our servers without much difficulty, we decided to write this setup guide for setting up symfony applications quickly on ServerGrove shared hosting accounts.

1) Preparation

There are a few steps you can take to make the installation of your application a breeze, and while we try to configure our servers to be as transparent as possible for developers, it is impossible to match everybody’s environment and/or preferences. Here are a few things to keep an eye out for:

a) Make sure all paths are unix-based. Developers running on windows will have their paths with C:\symfony or similar structures. Our servers run on Linux, so you need to use unix-based paths like /usr/local/php/symfony12

b) The Linux filesystem is case-sensitive, so Symfony and symfony will be different names. Make sure your code paths and file names match the names of the files and directories.

c) On shared hosting accounts, your home directory will be in /var/www/vhosts/example.com . Your symfony project files will reside in /var/www/vhosts/example.com/symfony_projects/PROJECT_NAME (replace example.com and PROJECT_NAME with your names, remember, domain names are lowercase and the project names are case-sensitive). Keep these paths and names in mind as you will need to use them in different places to properly configure your project and applications.

2) Paths Configuration

Before you upload your symfony project, you need to configure your project to find the symfony library. All our servers have symfony libraries pre-installed, so you can use the server-wide installation.

a) Use server-wide symfony installation (recommended)
The server-wide libraries are in /usr/local/php/. Here are the paths for the different versions of symfony:
symfony 1.0.x : /usr/local/php/symfony10/lib
symfony 1.1.x : /usr/local/php/symfony11/lib
symfony 1.2.x : /usr/local/php/symfony12/lib

To configure a Symfony 1.0.x project, edit config/config.php and setup the proper paths for the symfony library:

<?php

// symfony directories
$sf_symfony_lib_dir  = '/usr/local/php/symfony10/lib';
$sf_symfony_data_dir = '/usr/local/php/symfony10/data';

To configure a symfony 1.1.x, edit the config/ProjectConfiguration.class.php file:

<?php

require_once '/usr/local/php/symfony11/lib/autoload/sfCoreAutoload.class.php';
sfCoreAutoload::register();

class ProjectConfiguration extends sfProjectConfiguration
{
public function setup()
{
// for compatibility / remove and enable only the plugins you want
$this->enableAllPluginsExcept(array('sfDoctrinePlugin', 'sfCompat10Plugin'));
}
}

To configure a symfony 1.2.x project, edit the config/ProjectConfiguration.class.php file:

<?php

require_once '/usr/local/php/symfony12/lib/autoload/sfCoreAutoload.class.php';
sfCoreAutoload::register();

class ProjectConfiguration extends sfProjectConfiguration
{
public function setup()
{
// for compatibility / remove and enable only the plugins you want
$this->enableAllPluginsExcept(array('sfDoctrinePlugin', 'sfCompat10Plugin'));
}
}

b) Alternatively, you can upload your symfony library. If you do so, make sure you configure your project to have the correct unix paths described in bullet 1.C

3) Database configuration

Your symfony applications will probably use Mysql to load and save data. The Mysql database will be running in localhost. We recommend that you create the database and tables, and load the data before uploading the site. In order to do so:

a) login into the Control Panel with your username and password which you can find in the email with subject “New account information”.

b) once in the control panel, select the domain and go to the Databases section.

c) create the database and then create the user to access the database.

d) click on the phpMyAdmin icon, this will open a popup with the admin interface.

e) select the database. Now you can import a SQL file with all the statements to create tables and insert data

Refer to the phpMyAdmin manual for more information on how to use this powerful tool.

4) Transfer files

You already configured your paths, created the database and imported the data. Now you are ready to upload the project files. You will need to use a FTP client to connect to the server. You can find the FTP login information in the email with subject “New account information”.

Once you have connected to the server, go into the symfony_projects directory. Upload your project so all the project files end up in the contained in a directory residing in symfony_projects (ie. symfony_projects/myproject)

5) Configure Apache to use your symfony project web root.

Once you finished upload the files, it is time to configure the Apache web server to use the project web directory as the document root. For this, we recommend that you use our Control Panel extension, Maestro. To learn more about Maestro, go to the release announcement and watch the screencast

6) Something is wrong…

If something did not go right, we recommend that you look at the different log files that may contain critical information to fix the problem:

a) the Apache error log may contain warnings about Apache configuration error, the file is located in statistics/logs/error_log

b) in our servers, each website has its php error log. This file may contain warnings and fatal errors, you can find this file in statistics/logs/php.log or you can see it online through Maestro’s ajax-based log viewer.

c) if your symfony application is configured to log errors and messages, you can find those in symfony_projects/PROJECT_NAME/log

If you are unable to find any errors or locate the problem, feel free to contact us and we will assist you to get your site running as fast as possible.

7) Done!

If you followed these steps, your symfony-based site should be up and running.

We would like to hear from you: Please take some time to tell us how was your installation and setup experience, and specially, if there are any steps that need improvement.

Write an article or a tutorial about symfony, zend framework, php, wordpress or and other technology offered and supported by ServerGrove and we will pay up to $200 for accepted articles. To get involved read our guidelines and pitch your idea. If you have an idea for an article you think should appear in our blog, submit it to the comments area, perhaps someone will pick it up.

Some of you have asked for a screencast. Here it is. Send us feedback and feature requests, we are interested to know what you think.

We have two big symfony related announcements to make today!

1) We have four new shared hosting environments configured and performance tuned exclusively for running symfony applications. Cheaper and better, view plan details here.

2) We also launched Maestro, an exclusive extension to our control panel to facilitate deployment, debugging and management of symfony applications on shared hosting accounts.

What is Maestro?

Maestro is an extension to our hosting control panel that will allow our shared hosting users to easily deploy and manage multiple symfony applications. Some of its key features are:

• Install, configure and deploy your project with our Apache Web Servers easily and quickly.
• Manage the Apache configuration changes that need your Symfony-based sites, including the document root, .htaccess and mod_rewrite configuration.
• Includes an Ajax based log viewer so you can monitor symfony generated logs and PHP error log all from your browser.
• Run symfony commands like clear cache and fix permissions from your browser.
• Enhanced shared hosting security by running each website under its own user, preventing other users in shared server to access your files, cache and session data.  Additionally since your site runs with your FTP user, there are no permissions conflicts between the files you upload using FTP and the files generated by your site.

How do I use Maestro to setup my symfony project?

1. Upload your symfony project directory using your favorite FTP client

File Structure

2. Configure your symfony project to use the server-based symfony installation

<?php
require_once '/usr/local/php/symfony12/lib/autoload/sfCoreAutoload.class.php';
sfCoreAutoload::register();

class ProjectConfiguration extends sfProjectConfiguration
{
public function setup()
{
// for compatibility / remove and enable only the plugins you want
$this->enableAllPluginsExcept(array('sfDoctrinePlugin', 'sfCompat10Plugin'));
}}

3. Launch Maestro, click on the “Setup Web Server” button, and hit OK

Steps to launch a symfony application

4. Open your site in the browser, that’s it!

View your site using the preview link or your URL

Features in detail

• Manage symfony projects Maestro lets you manage all your symfony projects within each domain. When you launch Maestro, after selecting the domain in the control panel, you get the list of projects under the directory symfony_projects. It shows the symfony version, and URL/web root if it is active. You can have multiple projects and activate them as needed.

Select applications you want to manage from the projects list

• Know everything about your project Maestro features a check list of things that need to be configured in order for your project to run successfully. Checks permissions, paths and configurations and suggests fixes to get your application running painlessly.

Know everything about your project at a glance

• Run commands from your browser
  

  symfony tools

• Ajax-based log viewer Maestro provides a log viewer so you can monitor log messages generated by your symfony application. You can also view the PHP error log.

Ajax based log viewer

• Run symfony tasks from your browser Maestro lets you run symfony tasks like “clear cache” and “fix permissions” and view the output right from your browser, no need to get a SSH account and login, change directories, etc.  Additionally, fix-permissions is done a bit differently: Key files and directories are set to 700 so only your user can access them, providing extra security for cache and log files.

ajax based clear cache

• Easy Web Server Setup How many times you uploaded your project to a web host and had to fight countless hours to get your site running? Fight no more! Maestro manages all Apache configuration for you, including .htaccess and mod_rewrite. Just go to “Setup Web Server” and hit OK. The rest is done for you.

Configure your webserver from your browser

• Enhanced security Symfony developers often discussed about the drawbacks and security concerns regarding hosting symfony application in shared hosting servers. We listened.At ServerGrove, your site runs under your userid, not the Apache user. This means that all files generated by your site will be owned by you. Other users in the server are not going to be able to access them. Your cache and log files are safe. Additionally, if you run “fix-permissions” from Maestro, we set the cache, log and web/uploads permissions to 700 instead of 777 where every user in the server can access them, providing extra security. That’s not all! Every domain has its own sessions directory where all PHP session files are placed and owned by your user. Traditionally, PHP uses a centralized directory for session storage, on shared hosting this is not a very good idea. We still recommend our customers who are very concerned about security to purchase a VPS hosting account where you don’t share Apache or the file system with other hosting customers.
  
• Save all your session files in your personal directory. When we configure your domain, PHP is configured to save all session files in your personal directory and since your site runs with your userid, the session files are not readable by other users.
  
  
• No more file permissions conflicts Since your site runs using the same user as your FTP account, you won’t have any more conflicts of permissions between files uploaded through FTP and those created by your site.

Learn more about our hosting products preconfigured to run your symfony applications here

As promised a few weeks ago, we are releasing to the public a Symfony plugin that let’s your Symfony based applications interact with Jabber accounts. This means that your application can communicate with IM users of Google Talk and other Jabber (XMPP based) servers.

The possibilities are endless, here are just a few ideas:

• send and receive messages
• monitor contact online status
• execute server/application side operations controlled by IM users

The plugin offers:

• a daemon that is in charge of keeping the “bot” like user online, receives and sends messages, changes online status.
• a set of CLI tasks to send messages, and change status
• a set of API methods to use from your existing applications
• a set of callbacks that are executed from events within the daemon (ie. calls a method in your application when a message is received)

We are using this plugin in some of our applications. For example, our Live Chat system keeps track of the operators availability by monitoring the IM users online status. It also notifies the operators of incoming chats by sending messages to the IM accounts. By using this method, we are not require to use any special clients or open special websites to signup to our Live Chat system.

We are also developing other exciting applications that will interface with IM using this plugin, so stay tuned for future announcements!

This is our way of giving back to the Symfony community and we hope new and cool applications get created. If you do, we want to hear from you!

You can find the full documentation for the plugin at the plugin official home page.

If you have suggestions, improvements or any comments regarding this plugin, please let us know!