Archive for the ‘Wordpress’ Category

  • WordPress and the Shared Hosting Environment

    Date: 2012.12.09 | Category: Wordpress | Response: 1

    Wordpress in a Shared Hosting Environment

    In a Shared Hosting Environment, several WordPress installations use the same server-side resources, such as PHP.

    WordPress officially recommends a dedicated hosting environment. To quote,

    Just like flowers need the right environment to grow, WordPress works best when it’s in a rich hosting environment.

    And elsewhere,

    Not required, but recommended for better security

    Hosting is more secure when PHP applications, like WordPress, are run using your account’s username instead of the server’s default shared username.  The most common way nowadays for hosting companies to do this is using suPHP.  Just ask your potential host if they run suPHP or something similar.

    However, these recommendations are not mandatory. And WordPress will also work in a shared hosting environment, which is the most economical of all hosting environments. The question is, what limitations will a WordPress installion face in a shared hosting environment, versus a dedicated environment?

    The following are some of the limitations your WordPress installation will face in a shared hosting environment (that uses shared IP hosting).

    Inability to update WordPress and WordPress plugins through the Dashboard

    In a shared hosting environment, PHP is run by the web server, and not the FTP account holder (you). In other words, you don’t have “suPHP.” When you click on the links to update WordPress (or WordPress plugins) through the Dashboard, you will be prompted for your FTP credentials. But no matter how many times you enter them, the update won’t proceed. Your only option to update WordPress and WordPress plugins is through an FTP program, or by running Subversion scripts in a terminal (provided, you installed WordPress and its plugins via Subversion).

    Possible issues with Chron Jobs

    In some shared hosting environments, the website only exists when it is accessed. Therefore, scheduling your WordPress installation to perform different tasks at certain times may not work as planned. The tasks may be completed in a sudden flurry when some random user accesses the website.

    HTTPS Security cannot be implemented

    In a shared hosting envronment that uses shared IP hosting, HTTPS security cannot be implemented to secure the login page, the contact form and the admin area. This is because HTTPS requires a dedicated IP address, and your website’s IP address is usually assigned from a pool of IP addresses whenever it is accessed. However, the login credentials can be hashed using the Chap Secure login plugin.

    Dynamic Plugins generate Garbage Files

    Some plugins that serve dynamic content (such as the QR Code Widget that creates QR code images for pages) may generate tonnes of garbage files. This is usually because these plugins were designed to be used with PHP running as the FTP account holder (suPHP). Fortunately, you will always find a substitute plugin that will do the job.

    “PHP out of memory” Errors

    Sharing the server side PHP process means rationing PHP resources across different WordPress installations. Usually, a shared hosting environment will provide you with sufficient PHP memory. But some plugins like WordPress Backup to DropBox currently require 64 MB of PHP memory, which exceeds the quota of some shared hosting environments. The good news is that some shared hosting environments allow you to purchase additional memory. The bad news is that you will only find out your plugin’s memory requirement through trial and error. WordPress plugins do not list memory usage in their specifications beforehand.

    Possible Issues with Caching

    Shared Hosting environments sometimes run their own caching processes (usually Squid) to reduce bandwidth costs. These can sometimes conflict with your WordPress caching plugins. I strongly recommend Quick Cache for Caching WordPress in a shared hosting environment. Quick Cache has a special setting for shared hosting environments. Keep mind though, that some shared hosting environments may limit some extra features of Quick Cache as well. For example, Quick Cache can work faster with GZIP compression enabled. But this requires a module on the Apache sever to be turned on (mod_deflate). But many shared hosting environments disable this module because it consumes a lot of server side resources.

    Inability to Enable certain PHP modules

    Every now and then, you may come across a quirky plugin that would work better of certain PHP settings are customized. But in a shared hosting environment that shares the same PHP installation, it is not possible to customize the PHP configuration. You would rarely need to do so, but be warned.

    The Redeeming Factor

    Despite all of the above, WordPress continues to thrive in the shared hosting environment. And unless you are building a dot com startup, the costs of dedicated hosting are unjustified. While you continue to customize your WordPress installation  to the shared hosting environment, It is important to develop an understanding of its limitations, which are sparsely documented.

    Share
  • Visualizing WordPress

    Date: 2012.08.14 | Category: Wordpress | Response: 3

    Newcomers and converts to WordPress usually find themselves baffled over how WordPress interlopes with other server-side components such as PHP and MySQL. Guide books for beginners, such as WordPress For Dummies and Head First WordPress insist that beginners should blindly implement certain server-side configurations, and that fully understanding them is not neccessary for the operation of a WordPress website. While its true that understanding WordPress’ relationship with PHP and MySQL is not neccessary for operating a WordPress site, there are those of us who want to peek under the hood. Unfortunately, what lies under the hood is usually represented by complex diagrams and schematics, supplemented by pages of programming jargon. The following is an attempt to better visualize WordPress by blurring the boundary between art and abstraction.

    Visualizing WordPress

    Click on the pic to download a high quality version

    Creative Commons Licence
    Visualizing WordPress by Hamad Subani is licensed under a Creative Commons Attribution-NoDerivs 3.0 Unported License.
    Based on a work at http://www.techtangerine.com/wordpress.
    Permissions beyond the scope of this license may be available at http://www.techtangerine.com/contact.

    Components of WordPress

    The WordPress Installation

    This is the ~10MB of WordPress files that constitute your WordPress installation. They reside on your personal webspace.

    PHP

    PHP is a server-side scripting language that runs on your webhost’s server (usually on Linux). On its own, PHP is usually too complex and too fragmented for creating dynamic websites. WordPress harnesses the power of PHP by acting as a medium through which some very specific and useful functions of PHP can be accessed and deployed.

    MySQL

    MySQL is a database that resides on your personal webspace. This is where WordPress stores most of the content of your website (excluding graphics). When you access a WordPress website, the dynamic content is pulled from the MySQL database, while WordPress components remain static. This is what allows WordPress themes to be so easily changed, like skins. But as your database grows in size, pulling content from it can also slow down WordPress, which is why caching is neccessary.

    Sub-Components of WordPress

    wp-config

    Wp-config is a WordPress file that is used by WordPress to access the MySQL database. It resides in your personal webpsace.

    .htaccess

    .htaccess is a PHP component that resides in your personal webpace and controls access to your WordPress website. WordPress makes limited (but essential) use of it. However, it has powerful capabilities, and is often modified by some WordPress users to act as a firewall, and to block remote linking of images.

    Share
  • Why WordPress should be served Cached

    Date: 2012.03.12 | Category: Wordpress | Response: 4

    Serving WordPress Cached.

    Please click on the image to download a high quality version. Serving WordPress Cached by Hamad Subani is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.

     

    To Cache or to not Cache

    When it comes to self-hosting WordPress, Caching is an inevitability.

    The biggest strength of WordPress is its dynamic nature. A browser view of a WordPress website is like a “skin” which interfaces with dynamic components under the hood. But once a WordPress website starts growing, this also becomes the biggest weakness of WordPress. The “skin” becomes overloaded with more and more dynamic components. and a simple pageview becomes acrimonious for the server, as it struggles to deliver a “freshly prepared skin” to the browser for each and every page view. On the user end, the lag becomes noticeable.

    There are of course, some theoretical alternatives to caching, such as pruning your plugins and becoming a Cloudflare subscriber. But there is no substitute to Caching, when it comes to improvement in speed.

    Myth: Caching is a Compromise

    It first glance, Caching appears to be the very antithesis of WordPress. If WordPress was meant to provide dynamic content, why go back to serving static files? In reality, Caching will not compromise the dynamic nature of your WordPress site. It will more or less act like an intermediary between your dynamic WordPress site and its viewers. Ninety per cent of WordPress sites do not need to be dynamic in realtime (as WordPress by default allows them to be). Caching can be tweaked according to your requirements. Setting the cache to be refreshed every hour is considered to be the ideal compromise between keeping your website dynamic and serving static files.

    The ideal Caching plugin

    There has been considerable debate on what is the ideal WordPress Caching plugin. There are also rumours that Caching may one day be integrated into WordPress. For the time being, Check out the exhaustive testing conducted by Kyle Robinson Young at Tutorial 9.

    It is also evident that caching works differently in different server environments. For example, in shared hosting environments (where websites do not have dedicated IP addresses), the results tend to be different.

    Quick Cache

    Of late, Quick Cache has gained a lot of attention as a lightweight caching plugin with out-of-the-box functionality. It appears to be ideally suited for a shared hosting environment. But what makes this plugin different is its complete rethinking of the concept of caching. To quote Lead Developer Jason Caldwell,

    Quick Cache is extremely reliable, because it runs completely in PHP code, and does not hand important decisions off to the mod_rewrite engine or browser cache. Quick Cache actually sends a no-cache header ( yes, a no-cache header ) that allows it to remain in control at all times. It may seem weird that a caching plugin would send a no-cache header :-). Please understand that the no-cache headers are the key to the whole concept behind this plugin, and they will NOT affect performance negatively. On the contrary, this is how the system can accurately serve cache files for public users vs. users who are logged in, commenters, etc. That is why this plugin works so reliably.

    == ‘Quick Cache’ vs WP Super Cache ( Main Differences ) ==

    * Quick Cache uses a combination phase ( with less code ) and NO mod_rewrite rules ( no .htaccess file is required ). Super Cache requires an .htaccess file with mod_rewrite rules that serve GZ files. Quick Cache works right out of the box, so it is MUCH easier to install. All you have to do is activate the plugin and enable caching. All of its other options are already pre-configured for typical usage. Using an .htaccess file is 100% optional, and it’s for GZIP compression only.

    * Quick Cache provides a complete set of decision engine options for its entire methodology. Super Cache offers On, Half On and Off. It has fewer options on the back-end panel. Even though Quick Cache is pre-configured for typical usage, it is important for a site owner to have full control at all times. Even those advanced settings that tend to scare novice users away; those have all been included with Quick Cache. Quick Cache teaches you advanced techniques with its examples and built-in documentation for each option.

    * Quick Cache maintains absolute control over who sees cached pages. Super Cache allows browsers to cache-the-cache. In other words, some control is lost, and people who ARE logged in may see (not-logged-in) versions of pages. This technique gives Super Cache its name though. It makes things Super Fast. However, that may not be practical for some database-driven sites that are updated all the time and have lots of different plugins installed. If you offer membership or provide special content for members, you may want to try Quick Cache.

    * Quick Cache provides you with the ability to customize the Salt used in cache storage. Super Cache does not provide this capability. It could be done with instruction, but you would need to dig into the code for that. The ability to easily customize the Salt used in cache storage is very important. Many sites offer unique services and serve special versions of certain files. The ability to control how different versions of pages are cached, is critical to advanced webmasters that need to tweak everything and customize the caching engine to their specific needs.

    General Installation notes can be found here. In addition, remember to set the Mutex Option (in Quick Cache Configuration) to Flock for a shared hosting environment. Note that some database caching plugins can actually decrease speed in a shared hosting environment, and should not be used in conjunction with Quick Cache. Check the cache folder to make sure that old cache files are successfully being deleted. For example, if you set the cache expiration time to one hour, you should not see any files from yesterday in the cache folder. And never leave the cache folder (or any web folder) publicly writable. Only the server needs to access it.

    The beauty of Quick Cache is that it makes GZIP compression (for website images) entirely optional and independent of Quick Cache operation. Many shared webhosts disable mod_deflate their Apache servers because it uses a lot of server CPU power. This means your website’s speed cannot be further increased (in addition to caching). Quick Cache will still function regardless.

    What Caching plugin do you use (or intend to use)?

    View Results

    Loading ... Loading ...

     

    Share
  • Subversion for a Casual WordPress User…Promises and Challenges

    Date: 2012.02.03 | Category: Wordpress | Response: 1

    There are a couple of things that have made WordPress such a popular blogging platform. Being Open Source, WordPress source code is available for developers to customize and extend. In the process, new bugs and security holes are discovered, and new requirements are considered. In return, WordPress code gets frequently updated to meet changing needs. WordPress also provides a level of abstraction for the casual user that is not found in any other blogging platform. Without writing a line code, the casual user can experiment with thousands of themes and plugins that provide added functionality to WordPress.

    The downside is that the code for WordPress, as well as its themes and plugins is never static. WordPress code gets updated several times each year. Themes usually get updated less often. But some plugins can get updated every week!

    The WordPress Dashboard informs the user when a new WordPress update is available. It also informs the user if new theme and plugin updates are available. The most convenient option is to configure file permissions and file group ownership such that the “Update” links can be clicked from within the Dashboard. This requires FTP credentials and the updates are downloaded and installed in the background. However, this is sometimes not possible on some servers that are keen on security (PHP Safe mode restrictions).

    In addition, updating via FTP, whether through the Dashboard or through a client like Filezilla can be fairly slow. Especially when it comes to updating WordPress code. This means your site will be offline for some time. Updating WordPress code manually through an FTP client requires deleting specific old files, and there is always the danger of deleting the wrong files, which can brick your blog. Updating/Installing plugins via FTP is fast and easy. But suppose if all twenty of your plugins got outdated. This means you would have to download the latest version of each of them to your Desktop, unzip them and upload them. This can be fairly time consuming.

    Now imagine the rigmarole if you are entrusted with updating several WordPress blogs.

    For the casual user, the lure of using Subversion is being able to update WordPress using a single command. A Subversion update only adds and overwrites pertinent files, and therefore takes the fraction of time an FTP update does (around 15 seconds). In addition, a Subversion update automatically takes care of deleting unnecessary files in a less error prone way. But there are five issues when it comes to switching to Subversion.

    Firstly, Subversion can only be used on a WordPress blog that was installed via Subversion. Switching your existing blog to Subversion is not easy. And it can get more difficult if your blog was installed into the root directory of your server, instead of a sub-folder. In that case, you may as well back up each and everything and do a fresh WordPress install using Subversion.

    FTP View of a Subversion WordPress Installation

    An FTP view of a Subversion WordPress Installation. Notice the .svn folder. .svn folders can be found in each and every file folder of the Subversion WordPress Installation. These folders contain .svn files which store version information about the WordPress files. An FTP WordPress Installation, or a WordPress theme or plugin installed via FTP does not contain .svn folders or files.

    Secondly, updating themes and plugins via Subversion requires command-line acrobatics, for each and every theme and plugin, and in the end, may be more time-consuming than installing them via FTP (these are the additional themes and plugins that are not bundled with WordPress).

    Thirdly, Subversion requires that you correctly enter the version number of the latest version you wish to update to. The process is far from automated, and Subversion cannot automatically find the latest stable release. It can however, automatically find the latest bleeding edge/nightly build/trunk version, which hints that Subversion still is a developer tool. The casual WordPress user is highly discouraged from using such untested versions.

    Fourthly, using Subversion to update WordPress plugins and themes requires that they be typed into command-line in a special format. For example, the plugin “All In One SEO Pack” must be typed in as “all-in-one-seo-pack.” Thankfully, WordPress plugin pages now feature a direct link to the plugin’s Subversion repository, where such information can be found. This is a fairly recent development, and it indicates the growing importance Subversion is playing at WordPress.

    Fifthly, Updating WordPress and updating the themes and plugins are separate processes. So a complete Subversion update consists of three separate processes. Of course, there are those who have tweaked things to create a unified update process. But this is beyond the scope of the casual user.

    I have observed that most WordPress users are implementing a hybrid solution when it comes to Subversion. They have switched WordPress to Subversion and use it to update WordPress. However, plugins and themes are still updated via FTP or the Dashboard. The beauty of Subversion is that it allows such coexistence.

    There are of course, tools such as the Open Source Tortoise SVN, that add an attractive Graphical User Interface to Subversion. Tortoise creates a local repository of WordPress and its themes and plugins on the user’s hard drive. This repository is updated to latest stable releases in the Subversion online repository, and this “updated” local repository is synched with the user’s online WordPress installation but this repository has to be manually synched with the user’s online WordPress installation outside Tortoise SVN, preferably through FTP or command line. Recently WordPress’s Matt Mullenweg made a donation to Tortoise SVN, indicating its growing importance as a preferred SVN client for WordPress for developers committing changes to WordPress code. There are proprietary SVN clients available as well, that are more advanced than Tortoise SVN.

    The issue with most SVN clients is that things can become tacky when it comes to handling multiple WordPress installations. In such a case, the user would be expected to build a local repository for each and every WordPress site that he or she has (or maintains). This means updates can be done only from the computer where the repositories were installed. And again, installing a new plugin on a whim may still be easier via FTP, than through the client interface. Assuming your FTP client remembers your credentials, installing a new plugin traditionally is only a matter of clicking (and this remains one of the feature attractions of WordPress).

    The Ideal Subversion Client Updating Client; A Tentative Wish list for a Casual WordPress User

    Given that SVN clients may ultimately emerge as the key to managing WordPress updates, there are some things I would expect from an ideal Subversion client Updating client.

    1. An ideal Subversion client will not install local repositories on a user’s hard-drive. Local repositories are a vestige of developers, who needed them to commit changes to the source code. Instead, the Subversion client will automatically install/update to the user’s web server from WordPress Subversion repositories. It will be somewhat like giving a Graphical User Interface to the command-line acrobatics presently used (which unlike SVN clients, do not create local repositories on user hard drives).
    2. Upon being pointed to a user’s WordPress installation, an ideal Subversion client will be able to automatically detect all versions of WordPress, plugins and themes used.
    3. Upon being pointed to a user’s WordPress installation, an ideal Subversion client will be able to convert the WordPress installation to a Subversion WordPress installation. It will also be able to convert themes and plugins installed via FTP/Dashboard to Subversion.
    4. Upon being pointed to a user’s WordPress installation, an ideal Subversion client will automatically check what stable versions are available for WordPress, as well as its themes and plugins. Updates should be offered through a Graphical User Interface, that only involves clicking, and no typing.
    5. An ideal Subversion client will allow a unified update process for WordPress as well as its themes and plugins at the same time.
    6. An ideal Subversion client will allow easy installation of new themes and plugins. This will require some kind of interface with the WordPress themes and plugins directory.
    7. Upon being pointed to another WordPress installation, an ideal Subversion client will be able to repeat all of the above successfully.

    I know this is too much to hope for, and too soon. But from the perspective of a casual WordPress user, this is the need of the hour.

    Share
  • Why Subversion is not a complete way to update WordPress

    Date: 2012.01.29 | Category: How to, Reviews, Trends, Wordpress | Response: 10

    While WordPress offers the functionality of upgrading core files, themes and plugins via the Dashboard, this feature cannot be used with some webhosts who are keen on security. Upgrading via FTP is time-consuming and error prone. FTP is also not very secure. To quote one webhost, “Its 2012, and you shouldn’t be using FTP for anything.” Subversion offers the promise of one-click one-command, lightning-fast, server side upgrades. Is Subversion the way to go or has Subversion yet to grow up for the casual WordPress user? Please note that this posting is more of a documentation of experiential learning in an area that really needs documentation. This is not to be read as a manual. And I am not in a position to offer support.

    Note: For an Introduction to Subversion, please read my article on its promises and challenges for the casual WordPress user.

    What is Subversion?

    Subversion is a version control system for software. The basic concept is to host the most recent copy of the software on a publicly accessible web server, known as a repository. Using a few shell based commands, a user can download or upgrade to the latest version of the software. A user can also downgrade to a previous version of the software if he or she finds that previous release more stable. A developer can also access the latest “nightly build” of the software for testing purposes (referred to in subversion as the “trunk” version). All approved developers of the software can commit changes to the trunk version of the software in real-time, making the trunk version of the software a working copy of latest code changes. This is especially helpful for software like WordPress, whose total developers number in four digits.

    For a long time, repositories were the only painful way to get software and patches for Linux (in the interest of security). Later distributions of Linux added GUIs to make this process more interactive. However, Linux now allows downloading and installing software from websites, provided the installer file has a .apt extension.

    How is subversion different from FTP?

    FTP involves dumping files from your own computer onto the web server. Subversion works strictly on the web server side (and must be supported by your web server). You issue shell commands to the web server to download software onto your web server.

    There are complex ways to make Subversion work locally as well. For example, you could download and install the Tortoise SVN client, which creates a repository of desired software on your hard drive. And this in turn, is synced with your web server. The Tortoise SVN client provides a very intuitive interface for Subversion. We won’t be using it because it is strictly a client. It can be used for browsing Subversion repositories and downloading them to your local hard-drive. And one WordPress user has managed to find a convoluted way to automate WordPress updates using Tortoise SVN. He created his own Subversion repository in his webspace, which in turn downloads wordpress as well as select themes and plugins from the official WordPress Subversion repository. And by doing this, he updates a customized WordPress installation. However, this requires creating special folders for WordPress in the root, and enaging in .htaccess acrobatics to deal with these folders. And Tortoise SVN can only be used to download repository files to your hard drive (its a client, remember). It cannot be used to directly transfer/FTP them to your webspace. This means that your updated WordPress files will have to be FTP’d back to your webspace from your hard drive. And this defeats the purpose of making installation and upgrade strictly web based. And its not as simple as it sounds. Certainly, Tortoise SVN’s interface is very alluring, especially the ease with which svn:externals can be modified. But until FTP is integrated with Tortoise SVN, I would not recommend it for automating WordPress updates. It is a tool for committing code to projects, and thats what its best at.

    How is a Subversion WordPress Installation different from a Traditional FTP one?

    A Subversion WordPress Installation has a folder called .svn in the main root directory. Similar .svn folders can be found in the Themes and plugins directory, as well as for each and every theme and plugin folder.

    The .svn folders store files with the extension of .svn. They contain version information about WordPress and its components. This information is necessary for future Subversion upgrades or downgrades.  These files can be downloaded via FTP and viewed with an editor such as Notepad++. But it is not possible not recommended to edit these files in any way. Doing so can “break” Subversion upgrades. It is also not recommended to move them around using FTP, as they store path information which may not be correctly updated.  These files are only meant to be handled using a shell-based command line interface. Removing these files makes your WordPress installation identical to a traditional FTP one.

    A Subversion WordPress Installation is expected to be only upgraded through subversion. Later doing an FTP upgrade of the Subversion WordPress installation will not impact WordPress functionality in any way. But Subversion will get broken and may not be used again. Installing themes and plugins via FTP on a Subversion WordPress installation will not impact the functionality of these components in any way. Neither will it break Subversion for the core WordPress installation. And neither will such themes and plugins be lost when WordPress is upgraded via Subversion. Likewise, such themes and plugins can only be updated via FTP, not Subversion.

    What are the advantages of Subversion

    The primary advantage of Subversion is for developers, who need access to latest “bleeding edge” versions of WordPress, WordPress plugins and WordPress themes. There is no other way of accessing this stuff.

    For the casual user, WordPress can also be installed for the first time using Subversion. Compared to an FTP install, a Subversion install takes only a fraction of the time (around 15 seconds). Upgrading WordPress via Subversion also takes around 15 seconds. And requires only entering a command. This means your blog will be offline for a lot less longer. And this can be done remotely, as long as you have the right credentials. Upgrading WordPress via FTP requires care. The latest version needs to be downloaded and unzipped. Some files and folders in the existing installation have to be deleted and new ones are then uploaded to replace them. There is always the danger of deleting the wrong files, which can jeopardize the blog.

    How to Install WordPress via Subversion

    Once you have made sure your host supports Subversion, all you need to do is to connect to your FTP account using a terminal. A free software such as Putty can be used for this purpose.

    1. Connect to your website by typing your FTP credentials into the terminal window
    2. In a browser, go to WordPress.org and note the version number of the latest stable release (in this case, it is 3.3.1).
    3. Go to your root folder using the cd (change directory) command.
    4. If you want to install WordPress into a folder such that your blog will be accessible at example.com/blog, type
      • mkdir blog
      • Then navigate to it by typing cd blog
    5. If you want to install WordPress to the root directory, ignore the previous step.
    6. Type svn co http://core.svn.wordpress.org/tags/3.3.1 .  Note the trailing dot preceded by a single space.
    7. Files will start being downloaded and unzipped. You should be done in less than a minute.

    Needless to say, Subversion is not the only way to make a fast install of WordPress. A non-SVN version can also be installed via command line using the following procedure,

    1. Connect to your website by typing your FTP credentials into the terminal window
    2. In a browser, go to WordPress.org and note the version number of the latest stable release (in this case, it is 3.3.1).
    3. Go to your root folder using the cd (change directory) command.
    4. If you want to install WordPress into a folder such that your blog will be accessible at example.com/blog, type
      • mkdir blog
      • Then navigate to it by typing cd blog
    5. If you want to install WordPress to the root directory, ignore the previous step.
    6. Type wget http://wordpress.org/latest.tar.gz
    7. Files will start being downloaded. To unzip them, type tar -xzvf latest.tar.gz
    8. Then remove the zipped file typing rm latest.tar.gz

    Once you are finished installing via Subversion, wget or plain old FTP, make sure you are in the WordPress directory, and type the following commands to set up permissions properly:

    • chgrp web index.php
    • cd wp-content
    • mkdir uploads
    • cd ..
    • chmod -R 775 wp-content
    • chgrp -R web wp-content
    • mkdir tmp
    • chgrp web tmp
    • chmod 775 tmp

    To enable media uploads via the WordPress Dashboard, you will need to change some group ownership permissions

    • chgrp web wp-admin/async-upload.php
    • chgrp web wp-admin/media-upload.php

    Further information on activating your WordPress install and connecting it to your MySQL database can be found here.

    How to convert an existing WordPress Installation to Subversion

    This is beyond the scope of this article. Please note that converting existing blogs to Subversion can be nightmarish if WordPress was installed in the root folder of the public directory. Although WordPress provides detailed steps and further information can be found, some web hosts do not allow renaming/swapping of the root directory.

    How to upgrade WordPress via Subversion

    Only a WordPress Installation that was installed via Subversion can be upgraded using Subversion.

    1. Connect to your website by typing your FTP credentials into the terminal window
    2. In a browser, go to WordPress.org and note the version number of the latest stable release (in this case, it is 3.3.1).
    3. Go to the folder that contains the WordPress installation using the cd (change directory) command.
    4. Type svn sw http://core.svn.wordpress.org/tags/3.3.1/ . Note the trailing dot preceded by a single space. Note that this is slightly different from the earlier install command.
    5. Files will start downloading and unzipping. You should be done in less than a minute. Unlike an FTP upgrade, an SVN upgrade only downloads and updates specific files and components that have been upgraded, and is therefore less time consuming.
    6. Login to your WordPress Dashboard using your browser and make sure everything is OK.

    How to install additional plugins via Subversion

    This is the part where Subversion falters. The WordPress Subversion installation comes bundled only with the Akismet plugin. To install additional plugins, you have to engage in command line acrobatics.

    1. Go to WordPress.org and note the latest version of the plugin (In this case, 1.6.13.8).
    2. Go to the WordPress plugin Subversion repository and note the name of the plugin. For example, the plugin All in One SEO Pack will be listed as all-in-one-seo-pack.
    3. Download and install Vim on your computer. Installing text editors on your computer will do no good because the text editor must run within the shell environment. Find out from your webhost what shell-based text editors he/she has installed on the server. If Pico is installed, your are in luck as it is fairly intuitive. On the other hand, Vim is fairly difficult to understand. Don’t bother learning to use it because we will only make use of it in an indirect, limited way.
    4. Connect to your website by typing your FTP credentials into the terminal window
    5. Go to the folder that contains the WordPress plugins using the cd (change directory) command.
    6. We need to set Vim as the command line text editor. Type export SVN_EDITOR=vi (Or export SVN_EDITOR=pico if you are using pico).
    7. Type svn propedit svn:externals . Note the trailing dot preceded by a single space and the single quotation marks.
    8. This will open an editable file in command line. Interestingly, a graphical FTP program like Filezilla shows that a new .tmp file in the plugins directory is created when this command is typed. This file can also be edited from within Filezilla (using Notepad++), but it will disappear when the edit is finished (either through Notepad++ or command line). This confirms that a graphical FTP program is indeed unsuitable for Subversion. Before you proceed, please note that you will have to use Vim-specific (or Pico specific) keyboard commands. The mouse will not work. A handy guide to Vim-specific commands can be found here.
    9. Go to the line below it using Vim-specific (or Pico-specific) commands and type
    10. all-in-one-seo-pack http://plugins.svn.wordpress.org/all-in-one-seo-pack/tags/1.6.13.8/
    11. Save the file by typing Vim-specific commands ( : followed by x followed by [return]). Or type Pico-specific commands if using Pico.
    12. Type svn update
    13. Go to your WordPress Dashboard and activate the plugin.

    How to install additional themes via Subversion

    This is another part where Subversion falters. The WordPress Subversion installation comes bundled only with two basic themes. To install additional themes, you have to engage in command line acrobatics.

    1. Go to WordPress.org and note the latest version of the plugin (In this case, 1.2).
    2. Go to the WordPress theme Subversion repository and note the name of the theme. For example, the theme Coraline will be listed as coraline.
    3. Download and install Vim on your computer. Installing text editors on your computer will do no good because the text editor must run within the shell environment. Find out from your webhost what shell-based text editors he/she has installed on the server. If Pico is installed, your are in luck as it is fairly intuitive. On the other hand, Vim is fairly difficult to understand. Don’t bother learning to use it because we will only make use of it in an indirect, limited way.
    4. Connect to your website by typing your FTP credentials into the terminal window
    5. Go to the folder that contains the WordPress themes using the cd (change directory) command.
    6. We need to set Vim as the command line text editor. Type export SVN_EDITOR=vi (Or export SVN_EDITOR=pico if you are using pico).
    7. Type svn propedit svn:externals .  Note the trailing dot preceded by a single space and the single quotation marks.
    8. This will open an editable file in command line. Interestingly, a graphical FTP program like Filezilla shows that a new .tmp file in the themes directory is created when this command is typed. This file can also be edited from within Filezilla (using Notepad++), but it will disappear when the edit is finished (either through Notepad++ or command line). This confirms that a graphical FTP program is indeed unsuitable for Subversion. Before you proceed, please note that you will have to use Vim-specific (or Pico specific) keyboard commands. The mouse will not work. A handy guide to Vim-specific commands can be found here.
    9. Go to the line below it using Vim-specific (or Pico-specific) commands and type
    10. coraline http://themes.svn.wordpress.org/coraline/1.2/
    11. Save the file by typing Vim-specific commands ( : followed by x followed by [return]).  Or type Pico-specific commands if using Pico.
    12. Type svn update
    13. Go to your WordPress Dashboard and activate the theme.

    How to upgrade additional themes and plugins via Subversion

    When you upgrade WordPress via Subversion, only the Akismet plugin and the two default themes will also be upgraded. The additional themes and plugins have to be separately upgraded via command line acrobatics.

    1. Login to your WordPress Dashboard. Your dashboard should indicate which plugins/themes are out of date and what are the version numbers of the new version. Alternatively, this can be done by checking the WordPress plugin and theme Subversion repositories (which is safer, because Subversion can only update to version numbers listed in the repository; For example, the WordPress Dashboard may indicate the new version as version 2.31 whereas the correct format (as listed in the repository) is 2.3.1.
    2. Download and install Vim on your computer. Installing text editors on your computer will do no good because the text editor must run within the shell environment. Find out from your webhost what shell-based text editors he/she has installed on the server. If Pico is installed, your are in luck as it is fairly intuitive. On the other hand, Vim is fairly difficult to understand. Don’t bother learning to use it because we will only make use of it in an indirect, limited way.
    3. Connect to your website by typing your FTP credentials into the terminal window
    4. Go to the folder that contains the WordPress plugins (or themes) using the cd (change directory) command.
    5. We need to set Vim as the command line text editor. Type export SVN_EDITOR=vi (Or export SVN_EDITOR=pico if you are using pico).
    6. Type svn propedit svn:externals .Note the trailing dot preceded by a single space and the single quotation marks.
    7. This will open an editable file in command line. This is the same .tmp file you previously edited to add additional plugins (which should be listed in the file). Or if you are updating themes, it is the same .tmp file you previously edited to add additional themes (which should be listed in the file). Before you proceed, please note that you will have to use Vim-specific (or Pico specific) keyboard commands. The mouse will not work. A handy guide to Vim-specific commands can be found here.
    8. Go to the line on which your plugin/theme is listed using Vim-specific (or Pico-specific) commands. Then move your mouse to the version number using Vim-specific (or Pico specific) commands. And replace the existing version number with the new version number, using Vim-specific (or Pico-specific) commands.
    9. Save the file by typing Vim-specific commands ( : followed by x followed by [return]). Or type Pico-specific commands if using Pico.
    10. Type svn update
    11. Go to your WordPress Dashboard and make sure everything is right.

    Conclusion

    While updating WordPress through SVN is a breeze, the same does not apply to updating (or installing) additional themes and plugins.

    Nowhere is the casual WordPress user near the dream of updating WordPress and all plugins/themes using one command. Rather than a step towards automation for the casual user, SVN as it stands today, is still a developer tool that is best suited for updating to the “trunk”versions. Updating to latest stable releases requires manually entering the version number of the latest stable release. There is no command for automatically updating to the latest stable release.

    Clearly, Subversion for WordPress has a long way to go before it can truly replace FTP as a solution to update WordPress. In fact, installing/updating additional themes via FTP may be less time consuming in certain cases (Putty does not remember login credentials). Also, there is quite a margin of error when typing in text via command line, using the convoluted Vim (or Pico) interface.

    The precarious typing also takes out the joy of trying out new plugins on whim.

    There are of course, complicated ways to create a unified update process for both WordPress and additional themes and plugins. These are clearly beyond the scope of the casual user.

    But until Subversion for WordPress grows up, a hybrid solution can be pursued. While WordPress may be be installed and updated via Subversion, additional themes and plugins may be installed using FTP. The two can coexist, and even updating WordPress through Subversion will not affect the functionality of the additional themes and plugins installed via FTP.

    Further Reading (Subversion How-To’s)

    What WordPress has to say on Subversion

    Upgrading WordPress via Suubversion

    Useful SVN Commands

    Installing additional plugins via subversion

    svn:externals command line wizardry (1 & 2)

    What is your stance on Subversion for Wordpress?

    View Results

    Loading ... Loading ...

    Share
  • Piwigo and Zenphoto; a Comparative Review

    Date: 2012.01.15 | Category: Reviews, Wordpress | Response: 16

    Open Source Software for web-based photo galleries has been around for a very long time. Web based photo galleries mean different things for different people. The casual user feels no compulsion to go Open Source and host his or her own photo gallery, thanks to Flickr®, Picassa®, Photobucket® and Facebook®. But apart from  privacy and ownership issues, these services are fairly limited when it comes to integration with blogging platforms. For example, Photobucket® only allows its users to post a slide show of their photos in a blog post. A clickable thumbnail gallery cannot be inserted into a blog post as of now. And Photobucket® has the annoying tendency to automatically resize images to save bandwidth (at the expense of quality). For example, a 1.5 MB DSLR image will end up becoming a 70KB image once its uploaded to Photobucket®.

    For me, experimenting with Open Source web-based photo galleries began when I began to realise the limitations of WordPress when it comes to photoblogging.

    When WordPress started off, photos were more or less an afterthought. Photos on WordPress were given some advanced functionality by plugins. The best I could find was the nextGEN gallery by Alex Rabe of Germany, which seems to be partly inspired by oldtime photoblogging favourite, Coppermine.

    Everything was great with nextGen gallery, until I wanted to add just a little more content to photo descriptions. I discovered that it was impossible to add a hyperlink into the image description field (unless I was willing to hack some components). For those interested in pursuing this path, here’s a link.

    Even WordPress admits its helplessness when it comes to photos, suggesting that users change their site theme to a photoblog theme, or use a WordPress plugin that is compatible with an outside web-based photo gallery.

    Since I am an occassional photoblogger, changing the site’s theme to a photoblog theme was not an option. Therefore I started on my quest to find an ideal Open Source web-based photo gallery. I had some very specific criteria.

    1. Maximum compatibility with WordPress, especially when it came to inserting image galleries into a blog post.
    2. The ability to add HTML content to a photo’s description.
    3. The ability to add Copyright info to a photo’s description.

    With these criteria in mind, I found Wikipedia very helpful in narrowing down on Piwigo and Zenphoto. Apparently, these two Open Source web-based photo galleries have the most features. A close third would probably be Coppermine.

    Please note that my comparative review is based on Piwigo 2.3.2 and Zenphoto 1.4.1.6. Things are changing fast in this area and this comparative review should be considered outdated in a few months.

    It is interesting to note that while WordPress development has diverged from photoblogging, Open Source web-based photo galleries now draw cues from Wordpress’s famous “five minute install” and theme/plugin architecture.

    Piwigo and Zenphoto; History

    Both Piwigo and Zenphoto have been around for more than five years. Zenphoto is relatively newer (they don’t have a Wikipedia page). Zenphoto developers appear to be based in America while Piwigo developers appear to be clustered in France. It appears that Zenphoto is more small scale than Piwigo, in terms of code volume. This is quite surprising because I found it more feature-rich and more sophisticated. Both Zenphoto and Piwigo have had security vulnerabilities in the past (all appropriately patched). But Zenphoto appears to have had more than its share of bad press.

    Piwigo also offers full fledged photo hosting service (in the fashion of WordPress.com).

    Piwigo and Zenphoto;  Installation

    I ran into installation issues related to PHP on my host server and file permission settings with both Piwigo and Zenphoto.

    Preinstall Screen of Zenphoto
    Zenphoto gives a thorough preinstall analysis

    In the case of Piwigo, I had to shoot in the dark because there were no preinstall checks. In the case of Zenphoto, a preinstall screen pretty much summed up all of my issues, giving me specific pointers on troubleshooting.

    Newbie Tip: Never Install Piwigo or Zenphoto onto your existing WordPress database. Create a new database. And better yet, install on a subdomain instead of your WordPress domain.

    Piwigo and Zenphoto; Support

    I consider support for Open Source software as a courtesy and therefore my expectations were low.

    But within a day of posting my problems on Piwigo and Zenphoto support forums, I recieved direction from their support staff.

    Zenphoto appeared to have some (non-impacting) technical issues with their forums. They also have a system of moderating newbie posts.

    Piwigo and Zenphoto; Features

    Both Piwigo and Zenphoto were able to superbly meet requirements 1 & 2 (adding html content to individual images). But I found Zenphoto to be more sophisticated and advanced (detractors may use the word “dizzying”). There is the ability to fine tune everything. For example, Zenphoto has the option of enabling secure logins, (provided the server supports OpenID) whereas Piwigo does not. In addition, the bundled themes that come with Zenphoto are very clean and sophisticated. Zenphoto even has special themes that can replicate your original WordPress blog themes!

    When uploading image files via FTP, Piwigo requires that thumbnails be also created and uploaded to a subfolder with the prefix TN-. This requires batch processing of image files by a local image editor such as Adobe Photoshop Essentials. The alternative is to avoid uploading images via FTP and instead use a special upload program (Ploader) created by Piwigo. Zenphoto has no such requirements.

    Piwigo and Zenphoto; WordPress Integration

    Zenphoto initially appeared promising when it came to WordPress integration. After all, there were four WordPress plugins for Zenphoto, compared to just one for Piwigo.

    But the first Zenphoto plugin for WordPress is no longer under active development. Another one “may” support Zenphoto later on. One plugin (ZenphotoPress) that appeared promising works as intended, but only if zenphoto is hosted on the same site as the wordpress blog. Another plugin allows Zenphoto integration on another blog by reading the public RSS feed of the Zenphoto gallery (provided that it is enabled). But it does’nt appear compatible with the latest release of Zen photo.

    Piwigo Button in WordPress TinyMCE
    PiwigoMEDIA WordPress plugin allows easy insertion of images in a Piwigo Gallery, as well as entire thumbnailed albums.

    This left me with no way to go but Piwigo. The Piwigomedia Plugin utilizes the TinyMCE interface and works exactly as intended. It does not duplicate images in the Piwigo gallery. A demonstration can be found at the bottom of this page.

    Conclusion

    While Zenphoto clearly has sophistication and features, Piwigo has best managed to achieve WordPress Integration while offering an impressive, yet not dizzying array of features.

    What web-based PhotoGallery software do you prefer?

    View Results

    Loading ... Loading ...

    Share
  • The Easiest way to Insert Tables into a WordPress blog post

    Date: 2009.04.27 | Category: Windows Live Writer, Wordpress | Response: 8

    no-tables-here

    As WordPress users may be aware, the Write Post dashboard in WordPress does not give the option for creating tables.

    The alternative is to paste tables as pure HTML. This will only work as desired when pure HTML is inserted. Pasting the HTML of a table created in Google Docs appears to work flawlessly. On the other hand, creating a table in Microsoft Word, saving it in HTML, and then pasting the HTML will get you the table, but there may be all sorts of inconsistencies. Such as the table spilling over the entire blog page and the loss of format elements.

    Another alternative is to use a WordPress plugin that can import tables created in Microsoft Excel.

    An expert-only alternative is to manually modify the WordPress Write Post dashboard to include table features! It is possible.

    But so far, I have found that the easiest way to create tables in a WordPress blog post is to take advantage of the advanced format options available in Windows Live Writer.

    This table was created in Windows Live Writer. Isn’t it cool?

    TangerinefinalGIF

    1. No more messing with HTML
    2. WYSWIG editing
    3. No more tweaking plugins


    WindowsLiveWriterTable

    Of course, The simple Table Editor packaged with Windows Live Writer is no match for the one that comes with Microsoft Word. For example, you cannot edit the colors of the table borders or the cell backgrounds. You cannot merge cells. But you can adjust the height of rows, columns and cells. You can adjust the alignment of values in the tables. You can add/remove rows and columns on a pre-existing table. You can insert pictures into the table as well. This is definitely a more convenient workaround until WordPress gives us a table feature. The picture on the left is a screenshot of the dropdown menu under “Table” in Windows Live Writer version 14.0.8064.206.en.

    Share

What is a techtangerine?

The original tagline of this site was: "Tips, Tricks, DIY, Hacks and Rants by Hamad Subani." Since then, techtangerine has become a place to unload highly original meditations, musings and opinion on the tech world. In a nutshell (or tangerine?) this is about giving back to the web.

Get fresh techtangerine

Keywords

Topics