Saturday 30 March 2013

InnoDB Defined as an Unknown Table Engine

Symptoms


If InnoDB is not set for the MySQL database server, the following appears in the logs:
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '‘have_innodb’' at line 1

Cause


The parameter skip-innodb may have been disabled in the MySQL configuration file. Starting from JIRA 4.3 and above, the InnoDB storage engine would have to be set as MySQL's default storage engine as to avoid data corruption

Resolution


Check to see whether you have InnoDB support enabled:

mysql>  show variables like 'have_innodb';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| have_innodb   | NO    |
+---------------+-------+
1 row in set (0.00 sec)

If the value above is DISABLED, then you would need to enable InnoDB.

Open up MySQL's configuration file. On various platforms, the configuration file may differ in file name and location:
        Windows: $MYSQL_INSTALL_DIRECTORY/my.ini
Linux/Unix: /etc/mysql/my.cnf

If the parameter skip-innodbis uncommented/exists, then just comment it out:
# skip-innodb

Shutdown MySQL server, delete/rename the MySQL logs to refresh the entire server's logging, and restart MySQL server:

Linux:

# /etc/init.d/mysql stop

# rm /var/lib/mysql/ib_logfile*

# /etc/init.d/mysql start

Windows:
Go to $MYSQL_INSTALL_DIRECTORY/data and either delete/move the log files with the prefix ib_logfile.

Comparison between shared and reseller web hosting



Comparison between shared and reseller web hosting

Shared hosting is usually used as personal web space for a single domain. You are able to host as many subdomains as you want which could be reached by the following:
Reseller web hosting is an excellent way for web designers to host multiple DOMAINS in one place, and a great way to start a top web hosting company of your own. As a reseller, you host your own clients’ sites on our servers and handle the technical support and billing responsibilities for your clients.

* The price of reseller hosting plans are lower than shared hosting plans.
* The inventory you get in reseller hosting plans are much higher when compared to shared hosting.
* outsource the reseller hosting support, you will have more time to focus on your work then spending time on hosting support.
* There is better manageability of account with reseller hosting as you have one hosting account to manage all clients.
* Reseller hosting accounts can be re branded to say that you are the hosting company who is providing these services to end user.
* A reseller hosting account can also be integrated with packages like modernbill / H-sphere to have a better billing system.
* Reseller hosting plan are most affordable and unique hosting plan which offers higher inventory and complete automation than shared hosting plan.

Most personal and small business users will have no use for a reseller account, a reseller account is useful to those users who have a number of web sites and want to save money, as a reseller account can be cheaper than purchasing multiple shared hosting account.

With a reseller account you can also sell hosting, so this can be a relatively cheap step into the hosting business. You have the flexibility of controlling your own clients, creating, suspending and terminating accounts. You also have the knowledge that the server is being maintained for you, so you only have to worry about your clients and web site.

If you own a number of web sites, using a reseller account can save you money, and you can create accounts when you need them and share the resources between your web sites easily. You can find reseller hosting accounts with plenty of bandwidth and disk space for around $25 – $50 a month, which can be a big saving if you have a number of web sites needing hosting.

You also don’t have to worry about the maintenance of the server, since the web host should have this covered. You should also receive technical support included with your account.

If you have plans to start to own web hosting business, a reseller account can be an easy first step in the hosting industry. It is a relatively low cost solution, meaning you can concentrate primarily on building your business slowly and generate a steady monthly income. One of the biggest mistakes new hosts make is try to accomplish too much in a short period of time. This can lead to unhappy customers and evidently losing clients.

Potential clients may not be totally confident purchasing a hosting account from a reseller, because you in affect are the middle man. If a problem arises with the server or a customers account, they need to contact you and if you are unable to deal with the problem yourself, you would in turn have to contact your host. This can be a long process from initially receiving the first support request to getting the problem resolved. However if you have proper customer support in place this shouldn’t be a major problem.

As a reseller like I said above you have limited access to admin functions, and if you have experience with the control panel and server software you may find this annoying. The only thing I can suggest is asking the host if it would be possible for them to enable your account more with admin privileges. The worse thing the host can say is ‘no’, so it’s worth a try.

Shared web hosting is a type of web-hosting where you buy web-space for your personal websites from web-hosting companies. Reseller web hosting is a type of web-hosting where you buy bulk of space and can resell it to for profit.

A shared account is when a bunch of websites share a server and they are all hosted off from it. A reseller account is the same, except you get so much space and so much bandwidth that you can do whatever you want with it . With the reseller account, you can host unlimited domains and sell space to your friends at your given price.



Improving website loadtime



How to make your website load SUPER FAST!!!

As you settle in to build or update your website with BlueVoda, what’s going through your mind? No doubt thoughts of a dynamic, feature-rich website with loads of beautiful, high resolution images and lashings of JavaScript to entertain and delight your visitors? And why not? After-all this is the generous age of fast internet … What can go wrong?

In truth there are quite literally still millions of dial-up internet users out there. Remember that your website exists for the benefit of your visitors and customers and a fraction of them will have slow internet connections. Just because a visitor has a slow internet connection doesn’t mean they don’t want to buy things from your e-commerce store or enjoy your website. They will click away very fast if they find your website doesn’t load quickly enough. If anything, as the internet has become faster, attention spans have gotten shorter. Your page loading time will even improve your search engine ranking now that Google uses site speed in their ranking algorithm. For all these reasons, we at VodaHost have prepared some easy tips to help you get your website is off the mark before its competitors:

1. Graphics
Images and graphics are the main culprit when it comes to slowing down a website’s page load time. Always say it with plain text where you can or use small thumb-nails instead of the full graphic. Remember that even a massive website that is all plain text will load significantly faster than even one single largish image. It is nice to show off the artistic qualities of your design but if it is at the expense of your visitors experience then it is detrimental. You should also try to use image-manipulation software to make your images the right size for the page. Try out PIXResizer, for example. You should avoid re-sizing your images from within BlueVoda without re-rendering them at the right size because the web browser will still have to load the whole image and then just squish it when it comes time to render it; this will take time. Try and avoid having duplicate images to by keeping all the images for your website in one folder because your website should, as much as possible, load from the cache (memory) of your visitor’s computer. Identical images with different file-names will get in the way of this. You should also try and avoid using animations and use a static, properly re-sized, image where possible.

2. Tables
Try and minimize the use of tables in your website if you can. Your web browser (Internet Explorer, Firefox et al) doesn’t display the contents of a table until it has loaded all the elements within it, so if your entire website is contained within a table, it’s gonna take a while to load. If you must use tables in your website, create as many different tables as you can. A different table should be employed for at least the header, body and footer of your website. That way, at least part of the web-page will appear to your visitor should they have a slow internet connection. Consider this, instead of tables, use CSS to keep your page organized.

3. Scripts
Some of the scripts out there can be fun but in an attempt not to mince words on the subject, it’s fancy-shmancy. Little applications that show the user what the weather is doing in their part of the world, for example, are fairly pointless and slow down their web-surfing experience. If your visitor wants to know what the weather is doing outside, they can look out the window. You should consider scripts to be a luxury item and the rule here is, if it isn’t essential, loose it!

4. Videos
Adding videos to your site can also slow down your website significantly. If you absolutely must stream, make sure your videos are small in file size. A really fantastic way to save on website speed is to embed videos into your site that you have uploaded to YouTube. You can get the HTML code from your YouTube video and then use the Insert HTML button in BlueVoda to embed the video into your web-page by copying in the code. Embedding videos in this way also saves on the scripts you’ll have to add to your site for the video player to work and means that your website will function faster. The more you distance the content of your site from the HTML file that “builds” it, the faster your site will load. As an added bonus, the link to Google’s YouTube will even help the Search Engine Optimization (SEO) of your site and the more links to YouTube, the better!

Optimizing your page load time for your visitors will mean them a better experience and they will return to your website. Making a website for your visitors is extremely important. You must consider all the options and always optimize your site for them. Streamline your site, spread out your content neatly and stick to simple designs. All the really fast loading sites do…

Thursday 14 March 2013

Giving WordPress Its Own Directory

Many people want WordPress to power their site's root (e.g. http://example.com) but they don't want all of the WordPress files cluttering up their root directory. WordPress allows you to install it into a subdirectory, but have your blog exist in the site root.

As of Version 3.5.1, Multisite users may use all of the functionality listed below. If you are running a version of WordPress older then 3.5.1, please update before installing a Multisite WordPress install on a subdirectory.

Moving a Root install to its own directory


The process to move WordPress into its own directory is as follows:

  1. Create the new location for the core WordPress files to be stored (we will use /wordpress in our examples). (On linux, use mkdir wordpress from your www directory. You'll probably want to use "chown apache:apache" on the wordpress directory you created.)

  2. Go to the General panel.

  3. In the box for WordPress address (URL): change the address to the new location of your main WordPress core files. Example: http://example.com/wordpress

  4. In the box for Site address (URL): change the address to the root directory's URL. Example: http://example.com

  5. Click Save Changes. (Do not worry about the error message and do not try to see your blog at this point! You will probably get a message about file not found.)

  6. Move your WordPress core files to the new location (WordPress address).

  7. Copy (NOT MOVE!) the index.php and .htaccess files from the WordPress directory into the root directory of your site (Blog address). The .htaccess file is invisible, so you may have to set your FTP client to show hidden files. If you are not using pretty permalinks, then you may not have a .htaccess file.



  • If you are running WordPress on a Windows (IIS) server and are using pretty permalinks, you'll have a web.config rather than a .htaccess file in your WordPress directory. For the index.php file the instructions remain the same, copy (don't move) the index.php file to your root directory. The web.config file, must be treated differently then the .htaccess file so you must MOVE (DON'T COPY) the web.config file to your root directory.



  1. Open your root directory's index.php file in a text editor

  2. Change the following and save the file. Change the line that says:
    require('./wp-blog-header.php');
    to the following, using your directory name for the WordPress core files:
    require('./wordpress/wp-blog-header.php');

  3. Login to the new location. It might now be http://example.com/wordpress/wp-admin/

  4. If you have set up Permalinks, go to the Permalinks panel and update your Permalink structure. WordPress will automatically update your .htaccess file if it has the appropriate file permissions. If WordPress can't write to your .htaccess file, it will display the new rewrite rules to you, which you should manually copy into your .htaccess file (in the same directory as the main index.php file.)




Codex




Codex tools: Log in




Giving WordPress Its Own Directory


Languages: EnglishFrançais??????????(Add your language)








Contents


[hide]



Many people want WordPress to power their site's root (e.g. http://example.com) but they don't want all of the WordPress files cluttering up their root directory. WordPress allows you to install it into a subdirectory, but have your blog exist in the site root.

As of Version 3.5, Multisite users may use all of the functionality listed below. If you are running a version of WordPress older then 3.5, please update before installing a Multisite WordPress install on a subdirectory.


Moving a Root install to its own directory


The process to move WordPress into its own directory is as follows:

  1. Create the new location for the core WordPress files to be stored (we will use /wordpress in our examples). (On linux, use mkdir wordpress from your www directory. You'll probably want to use "chown apache:apache" on the wordpress directory you created.)

  2. Go to the General panel.

  3. In the box for WordPress address (URL): change the address to the new location of your main WordPress core files. Example: http://example.com/wordpress

  4. In the box for Site address (URL): change the address to the root directory's URL. Example: http://example.com

  5. Click Save Changes. (Do not worry about the error message and do not try to see your blog at this point! You will probably get a message about file not found.)

  6. Move your WordPress core files to the new location (WordPress address).

  7. Copy (NOT MOVE!) the index.php and .htaccess files from the WordPress directory into the root directory of your site (Blog address). The .htaccess file is invisible, so you may have to set your FTP client to show hidden files. If you are not using pretty permalinks, then you may not have a .htaccess file.



  • If you are running WordPress on a Windows (IIS) server and are using pretty permalinks, you'll have a web.config rather than a .htaccess file in your WordPress directory. For the index.php file the instructions remain the same, copy (don't move) the index.php file to your root directory. The web.config file, must be treated differently then the .htaccess file so you must MOVE (DON'T COPY) the web.config file to your root directory.



  1. Open your root directory's index.php file in a text editor

  2. Change the following and save the file. Change the line that says:
    require('./wp-blog-header.php');
    to the following, using your directory name for the WordPress core files:
    require('./wordpress/wp-blog-header.php');

  3. Login to the new location. It might now be http://example.com/wordpress/wp-admin/

  4. If you have set up Permalinks, go to the Permalinks panel and update your Permalink structure. WordPress will automatically update your .htaccess file if it has the appropriate file permissions. If WordPress can't write to your .htaccess file, it will display the new rewrite rules to you, which you should manually copy into your .htaccess file (in the same directory as the main index.php file.)



Using a pre-existing subdirectory install


If you already have WordPress installed in its own folder (e.g., http://example.com/wordpress), then the steps are as follows:

  1. Go to the General panel.

  2. In the box for Site address (URL): change the address to the root directory's URL. Example: http://example.com

  3. Click Save Changes. (Do not worry about the error message and do not try to see your blog at this point! You will probably get a message about file not found.)

  4. Copy (NOT MOVE!) the index.php and .htaccess files from the WordPress (wordpress in our example) directory into the root directory of your site—the latter is probably named something like www or public_html. The .htaccess file is invisible, so you may have to set your FTP client to show hidden files. If you are not using pretty permalinks, then you may not have a .htaccess file. If you are running WordPress on a Windows (IIS) server and are using pretty permalinks, you'll have a web.config rather than a .htaccess file in your WordPress directory.

  5. Move (DON'T COPY) the wp-config.php file to your root directory.

  6. Edit your root directory's index.php.

    1. Open your root directory's index.php file in a text editor

    2. Change the line that says:
      require('./wp-blog-header.php');
      to the following, using your directory name for the WordPress core files:
      require('./wordpress/wp-blog-header.php');

    3. Save the file.



  7. Login to your site (if you aren't still already). The URL should still be http://example.com/wordpress/wp-admin/

  8. If you have set up Permalinks, go to the Permalinks panel and update your Permalink structure. WordPress will automatically update your .htaccess file if it has the appropriate file permissions. If WordPress can't write to your .htaccess file, it will display the new rewrite rules to you, which you should manually copy into your .htaccess file (in the same directory as the main index.php file.)


Since the site is not working for some of these steps, it is best to make this change at a time of low activity, e.g., the middle of the night.

If you already have content in your site, see when your domain name or URLs change for how to deal with references to the old URL that will remain in the database.


Pointing your home site's URL to a subdirectory


In some cases, you may have a WordPress site that changes significantly every year, such as with a conference website. If you want to install each year's version of the site in a subdirectory, such as /2010, /2011, and /2012, but have the root domain (yoursite.com) automatically redirect to a particular subdirectory (usually the latest), follow this technique:

  1. Install WordPress in a subdirectory, such as /2012.

  2. In your root folder (not the subdirectory folder), download and open your .htaccess file.

  3. Add the following to your .htaccess file:


RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www.)?YourDomain.com$
RewriteRule ^(/)?$ blog [L]


  1. In the above code, change the "YourDomain.com" value to your root domain.

  2. In the above code, change the "blog" value to the subdirectory.

  3. Save and upload the .htacess file back to your root directory.


Now when users to go your root domain (yoursite.com), it will automatically redirect to the subdirectory you specified. When you want to redirect to a new subdirectory, such as the conference site for next year, just update the .htaccess redirect code.

Move Your WordPress Files Out of the Root Directory

I usually recommend that people install WordPress at the root directory of their sites. Even if you intend to mostly use WordPress for a blog, and run it at /blog/, you can still do that with WordPress at the root through some simple settings. But just because WordPress is installed and controlling your site from the root, doesn’t mean that the WordPress core files need to be located at the root.

 

You may want WordPress installed in a subdirectory just to keep that root directory of your site clean. There are a lot of files that power WordPress and keeping them all at the root can be an eyesore:


You Can Install WordPress in a Subdirectory and Still Control the Root


Yep that’s right. You’ve probably seen the preference for it a million times and never really thought twice about it (if you are like me). It’s under Settings > General:



That first setting, WordPress URL, give you the opportunity to set where the actual WordPress files are, and use the second setting to point where you want the root of your site to be. This means you could create a new subdirectory (say, “wordpress”), put all your WordPress core files in there, and still control the root. The codex has a nice step by step on this, but I’ll cover it quickly here as well.

  1. Move (or intially put) ALL of the WordPress core files into a subdirectory. (e.g. “/wordpress/”

  2. Change the General settings (see pic above) to the proper new locations.

  3. Copy the index.php and .htaccess file back to the root

  4. Open the index.php file and change the line: require('./wp-blog-header.php'); to require('./wordpress/wp-blog-header.php'); . If you use a different subdirectory, obviously “wordpress” would be whatever you named that subdirectory.

  5. Log into the backend. Note that you probably used to log in at /wp-admin/ but it will be /wordpress/wp-admin/ now.

  6. Go to Setting > Permalinks and save that section, rewriting and updating your .htaccess file

  7. Make sure all is well on the Front End.


Security


Since I would think very few sites do this, you are getting the bonus of security by obscurity. Bots scrounging around your site probably will never find the WordPress core files since they are in a subdirectory that isn’t referenced publicly anywhere.