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.

This is one of the more annoying bugs in Wordpress. Wordpress is working fine, but when you check the RSS feed you get the following error:

XML Parsing Error: XML or text declaration not at start of entity
Location: http://domain.com/feed/
Line Number 3, Column 1:<?xml version="1.0" encoding="UTF-8"?>
^

The most common explanation for its cause is blank spaces leading and ending the PHP pages caused by editing the theme. There are two solutions for this problem. The first is the easiest and I would recommend trying this first.

Solution 1:

Step 1)

Install the fix-rss-feed plugin. http://wordpress.org/extend/plugins/fix-rss-feed/

Step 2)

Go to Admin > settings > fix RSS Feed

Step 3)

Click on the “Fix wordpress rss feed error” button

This might or might not fix your problem. I have had it work on some themes and it failed on others. If it fails I would recommend the following solution:

Solution 2:

The “Wordpress leading whitespace fix” is slightly more involved than the plugin, albeit a very good solution when the plugin fails. The fix is well documented so I will not bother to repeat the steps here. You can read installation instructions and download from here: http://wejn.org/stuff/wejnswpwhitespacefix.php.html

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.

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.

In this post we will explain how we were able to use Symfony templates in WordPress, allowing us to avoid duplication of files and code, and still carry the same look and feel of our main website (which runs in Symfony) into our Blog.

When making changes in the templates of our symfony-based site, those changes are immediately available in the Blog which runs on WordPress without having to copy code or files.

In our case, we wanted to have the top section of our website (header and top navigation) and the footer in both the corporate website and Blog.

The way we had built our site proved to be very useful and time saving, this is how we defined it in symfony:

• The top header and navigation of the site was placed in a global partial named _topnav.php, which is located in the templates directory of the application (apps/site/templates).
• The footer of the site was placed in another global partial named _footer.php, and it is located in the same directory.
• Then, we included these partials in layout.php also located in this directory. It looks like this:

include_partial('global/topnav');
echo $sf_content;
include_partial('global/footer');

Wordpress themes include several files that need to be customized to change the way it looks by default.  These files can be modified by going into “Appearance” and “Editor”.

We did not use the main layout.php template from Symfony, because we moved the common elements of the HTML into the partials. So on Wordpress we only modified header.php and footer.php

In header.php we included the _topnav.php file from symfony. So after the <body> tag we inserted the following line:

<?php include('/path_to_symfony_project/apps/site/templates/_topnav.php'); ?>

This inserts the top area (including the navigation) of our site into every page and post of the Blog. if you have an external CSS in your main site, which you probably do, you need to make sure to add it to the header.php in WordPress.

Then to properly add the footer section of the site to the Blog, we edited footer.php and inserted the following line before the </body> tag

<?php include( '/path_to_symfony_project/apps/site/templates/_footer.php' ); ?>

The same could be done in the inverse way. If you have your main elements of your site design in WordPress, you could include those in the Symfony templates.

If you have any other ideas on how to accomplish this, or other tips on Symfony and WordPress integration, leave a comment, we would love to hear form you.