Migration process (8)
No, you can just give us a copy of the database yourself to perform the migration. Nevertheless, if the site is online and publicly accessible please provide the URL since this will help us to test our generated WordPress site when performing the migration.
No. You can keep existing WordPress data. Just tell us to make sure the migration won’t overwrite any of your existing WordPress content. Let us know you wish this feature from the beginning to make sure there won’t be any problem when importing the data.
No, you can take the result of the migration and use it in your local installation to test the new site before going live.
An SQL export file of your current CMS database can be very large, specially if it includes cache tables. If zipping the file (you’ll be amazed of the compression rate for SQL files) does not decrease the size to a manageable size (e.g. under 30 MB which is the maximum size allowed by GMail now), the simplest way to send the file is by using one of these free (or at least with a free trial) online services such as:
In all of them, you upload the file using the web form they provide and they send an email to the person who needs to receive the file with a download link valid for a few days. DropBox is also an option for intermediate size files.
Obviously, a complementary solution would be to reduce the size of the export file by making sure to only include the important tables in the export process and/or to empty the cache tables before starting the export.
As a general rule, you should always backup your site before any change, and a migration is not an exception. Having said this, we perform the migration on our own servers and, unless you say so, we will not modify your current database but will just send you the generated SQL file. Then, it’s up to you to decide whether to backup the site before importing such file (again, our recommendation is to do so!).
Each migration is different and must be configured individually. Regardless what you read/ find online, there’s no “one size fits all” migration. In order to provide a great service we always specialize first the migration process to your specific requirements and configuration. We are absolutely convinced this is necessary to guarantee your satisfaction with the generated WordPress site.
WordPress is well-known for its huge set of plug-ins that extend its behaviour in any imaginable way. As part of the migration process we may need to make use of some of these plug-ins to mimick as close as possible the functionality of your current site.
In what follows we provide a non-exhaustive list of the plug-ins we are recommending and that we have worked with as part of earlier migrations. Of course, you´re free to choose your own set of WordPress plug-ins but if you´re not sure which ones are the best for you, we would like you to consider the ones we are listing here since we know well their advantages (and limitations). Note that we are only including plug-ins that may be needed to complete a migration (i.e. plug-ins that the migration process initializes according to the configuration of the CMS to be migrated), this does not pretend to be a complete list of useful WordPress plug-ins.
The Redirections plug-in is used to create a set of 301 redirection rules that will automatically redirect visitors accessing the site using the former site URLs to the new ones (since in most cases it’s not possible to ensure the WordPress URLs are exactly the same as the old ones). A workaround is to use Custom Permalinks that allow to define a specific URL pattern for each post, offering a flexibility similar to the one that Drupal has by default.
Galleries and images
The new gallery shortcode in WP may be good enough for you but in case you need a more powerful gallery mechanism to mimick your current gallery settings, we usually work with the NextGen and Portfolio slideshows plug-ins
Video and audio files
WordPress can automatically embed a number of video formats but if yours is not in the list, the wordpress video plug-in will for sure solve the problem. For audio files, we recommend the oEmbed HTML5 audio plug-in.
If you want to move over from your current site all meta descriptions, meta keywords, SEO title,… used to annotate your posts, try WordPress SEO by Yoast
WordPress has no default forum module. To migrate your forum to WordPress we strongly recommend bbPress. Simple and flexible at the same time.
Many sites have extensive profile information (e.g. twitter handle, cell number,…) for each user which can’t fit in the very limited set of default user fields in WordPress.BuddyPress is a very feature-rich plug-in to manage your users in WP. If you prefer a simpler solution only focusesd on storing this extended profile information, wp-member and profile builder could be the right choice for you.
Internationalization is not part of the WP core. If you need to migrate a site available in different languages, we would recommed the WPML plug-in
Custom types / fields
This one depends a lot on your specific requirements. In simple cases, you may be fine without a plug-in (integrating the source custom fields in the body of the worpdress post, or populating the post metadata with them and configuring the theme to retrieve and process them accordingly). In more complex scenarios, plug-ins likeadvanced custom fields or Custom PostType UI may come in handy.
Do you have posts co-authored by several people? These two plug-ins: co-authors (yes, it still works) and co-authors plus may help. The second is newer and has more options while the first one is simpler (i.e. it just uses the postmeta table to link the posts with the several authors while the second one creates one new category per user and links those categories with the corresponding posts which IMHO is not so neat).
Content export / import (8)
How to achieve a complete Joomla export content
All the data about your posts, pages, comments, users… in your Joomla site is stored in a database. Therefore, getting a full copy of your Joomla data to get ready for your Joomla to WordPress migration is as easy as exporting the data of the Joomla database. The export is usually a .sql (or .mysql) text file with the set of CREATE TABLE and INSERT SQL statements that would allow you to recreate the database structure and content in another site.
There are two ways to export your Joomla content file:
– From Outside Joomla, using any database export tool like phpmyadmin
– From Within Joomla, using one of the available backups extensions, like the Akeeba backup extension
Let’s take a closer look at both options.
Export from outside Joomla: PHPMyAdmin
PHPMyAdmin is a free tool to manage MySQL databases (most likely, your Drupal is using a MySQL backend, if not check what database export tools are available for your system). PHPMyAdmin is available from your control panel. Once inside phpmyadmin, you just need to select the Joomla database on the left column.
After selecting the database just go to the ‘export’ tab and select the tables you’d like to export.
Export from within Joomla: Backup module extension
An alternative option is to install a backup Joomla module/extension like the Akeeba backup extension.
Then, you can just log in Joomla and use the Components menu to select the Akeeba backup. In the configuration menu, select ‘Full Site Backup’ in the ‘Backup type’ option. Then click on ‘Backup now’ to start the backup. Once the backup has finished, go to ‘Administer backup files’ to download the backup file to your computer.
We hope you will find this information useful and that you will be able to easily export your Joomla content. If something is not clear or missing, please let us know and we will improve the explanation.
You followed these instructions to import the SQL file and no errors were reported during the import process (typically you’d see a green message saying something like “X commands were successfuly executed”). Still, when you refresh your WordPress site you don’t see any new post/page/… there.
- You imported the file in the wrong database. This can only happen if you are using the “from outside” option to import the file and you didn’t check which database was hosting your WordPress site. So please get back to the import instructions and repeat the process.
- Your WordPress installation is not using the standard WordPress prefix (“wp_”) and you forgot to tell us your prefix (maybe you didn’t even know) so you end up with two sets of WordPress tables: the ones your WordPress site is actually using and the ones created during the import which are blissfully ignored (as in the image on the left, the “wp_” ones are the tables generated during the migration, the rest are the WordPress tables in use). In this case, you’ll need to drop the “wp_” tables and we’ll need to rerun the migration process to generate a new SQL file that matches your custom prefix.
A big difference of WordPress wrt others CMSs like Drupal is the fact that WordPress does not allow users to upload/change their profile picture. The reason being that the profile picture of a user is not managed by WordPress itself. Instead, WordPress relies on the Gravatar (global avatar) service to retrieve and show the picture corresponding to a given user.
The benefit of gravatars is that you can share the same profile picture among most of the blogs, forums, … where you participate. The disadvantage is that you need to register in Gravatar and upload your picture to see it in your WordPress.
This is the reason why user migration from Drupal, Joomla and others to WordPress will not migrate the profile picture of each user to WordPress. If the migrated user is already registered in Gravatar (based on the email information) his/her picture will immediately appear in WordPress. If not, s/he will need to register and upload the picture there.
Of course, if migrating user pictures is a must for you, there are WordPress plug-ins that provide an alternative functionality. We can help you choose one and study the additional migration features you’ll need to use/initialize it.
By default, all WordPress content-related tables are dropped and recreated as part of the migration process, wiping out all the existing data, and thus, avoiding conflicts with any sample data entered by before the migration.
The same process cannot be employed when migrating users. Otherwise the migration would remove the admin user information entered when installing WordPress and you wouldn’t be able to log in your own site. This is why, the .sql script containing the users migration data adds the new users but respects the existing admin user in the WordPress site.
Nevertheless, the script assumes that the admin user (id = 1) is the only existing WordPress user. If there are other users please remove them before importing the file. Alternatively, you could provide us with a copy of your WordPress database and we could configure the migration to make sure it respects all existing content.
If no custom menu is defined, the default WordPress behaviour is to show all pages as menu items. Obviously, specially if your site has plenty of pages, this default approach may not work for you.
To remove this WordPress menu and create your own just go to Appearance->Menus and add your own menu.
All the data like pages, posts, users, comments and forum threads in your Drupal site is stored in a database. Therefore, getting a full copy of your Drupal data is as easy as exporting the data of its database. The export is usually a .sql (or .mysql) text file with the set of CREATE TABLE and INSERT SQL statements that would allow you to recreate the database structure and content in another site.
There are two ways of getting this export file:
- From Outside Drupal, using any database export tool like PHPMyAdmin
- From Within Drupal, using any of the available backup modules, e.g. Backup and Migrate
Let’s analyze both ways.
From outside Drupal using PHPMyAdmin
The free tool PHPMyAdmin is easy to use to manage MySQL databases (most likely, your Drupal is using a MySQL backend, if not check what database export tools are available for your system). You can access this tool from your control panel. Once you have gained access to the tool, select all the files of the database you need from the left column (you may have several databases installed in your site, to know which one is actually storing its content you may want to check the settings.php file, usually located in the subdirectories sites/default or /sites/default/files of your Drupal installation; look for a line like this one $db_url = ‘mysql://username:password@localhost/databasename’).
After selecting the database just go the export tab and select the tables you’d like to export.
From within Drupal through Backup and Migrate Module
An alternative option is to install a backup module like Backup and Migrate. Then, you can just log in Drupal and use the module menu to select the tables to export, the destination folder for the export file and so on as shown below (your options may vary depending on the version of Drupal and the module you’re running).
We hope you’ll find this information useful. If something is not clear or missing, please let us know and we will improve the explanation.
If you requested the Content Migration Service, you just got a .sql file with your new WordPress data ready to be imported. To make sure everything goes smoothly please follow these steps:
1 – [if you are using redirection rules] Install the redirection plug-in. Do not change any configuration option, just install it and activate it. After, set the permalink variable for the site to /%postname%/ in Settings -> Permalinks
2 – [if your migration includes a forum] Install the bbPress plug-in. Do not change any configuration option, just install it and activate it.
3 – Import the .sql file in the database that your WordPress site is using (some further instructions on this). IMPORTANT: remember that, unless explicitly agreed beforehand, importing the file will wipe out the existing information in your WordPress content-related tables. The rest of the tables will be respected (check with us if you have questions regarding which exact tables will be affected). If you contracted the user migration feature remember that all users except for the user with id=1 (i.e. the user created when installing wordpress) will be removed (read more on this). If you are surprised to see all pages appearing as menu items, read this. Remember that creating a backup of your database before applying any sql script on it (ours or any other) is always a good practice.
4 – Copy and paste all image files from the “/sites/default/files” folder (or the folder you’re using to store the media files, we can help you to locate the exact folder) in your Drupal site to the wp-content/uploads folder in WordPress. Respect the same subdirectory structure if any, i.e. a Drupal image file in “/sites/default/files/sub/X.png” should be moved to wp-content/uploads/sub/X.png
Data, such as pages, posts, comments, forum threads and users of your new WP site generated during the migration is safely stored in a SQL file.
To retrieve all such data into your WordPress dashboard, you have only to import the SQL file in your WordPress database.
To import this file you can choose between two options:
- From Outside WP, through any database import tool, as for example PHPMyAdmin .This is the way we recommend most.
- From Within WP, through one of the (few) available restore modules.
Let’s see both options.
First option: From outside WordPress through PHPMyAdmin.
PHPMyAdmin is an easy and free tool to correctly manage MySQL databases and it also is the official database backend for WP. This tool is available on your control panel. Once you are inside the tool PHPMyAdmin select the files of the wordpress database that you find on the left column. If your site contains several databases and you´re not sure which one is the one WP is installed on, open wp-config.php and look for a sentence like define(‘DB_NAME’, ‘this is the name of your database’).
After selecting the database just go the import tab and select the SQL file to import.
Second Option: From within WP through Adminer plug-in
An alternative option is to install a WordPress plug-in that allows us to select and execute a SQL file from within the WP dashboard. For this our recommendation is to install the Adminer plug-in (WordPress version of the Adminer tool, kind of a competitor of phpmyadmin (as the Adminer people say in their web page: “Replace phpMyAdmin by Adminer and you will get tidier user interface, better support for MySQL features, higher performance and more security.”).
Once installed, you’ll find the Adminer option under the Tools Menu. Once you click on it you’ll have the option to execute Adminer in a separate tab
and the Adminer interface will immediately pop up. As with phpmyadmin, you have the list of tables on the left. The right hand side show the data/structure of the selected table.
In the upper left corner, you’ll see the two most important options, the DUMP button (to export the data of the database) and, the option we were looking for, SQL command (to execute a SQL sentence, possibly importing it from an external file). Upload here your file and Adminer will take care of executing all SQL commands in it.
Another option would be to use a Backup&Restore plug-in (perhaps surprisingly, the number of plug-ins for doing backup largely outnumbers the number of plug-ins that can also restore the database from a backup file). Among the few plug-ins that offer a Restore feature we have WP-DB Manager, Xcloner and UpdraftPlus (our favourite one, BackWPup recently stopped offering the restore feature).
We hope you’ll find this information useful. If something is not clear or missing, please let us know and we will improve the explanation.
Pricing and Billing (3)
All migration services should be paid as follows:
– 30% immediately prior, as a condition precedent, to starting Phase 2 (as described for each Service), and
– the remaining 70%, immediately prior, and as condition precedent, to starting Phase 3 (as described for each Service).
Please, read the Terms & Conditions for more details.
YES! MigratetoWP.com is happy to make its (small) contribution to make the world a better place (check the list of NGO/NPOs we have helped so far).
We offer huge discounts in all our migration packages. Check with us if you qualify*.
In exchange, we ask to be able to announce our probono collaboration (in this website, in our twitter account, …) and that you do the same. Some examples would be a mention or link in your site, a blog post announcing the move to WP and mentioning that we helped you in the process and/or publicity through your social sites (twitter, facebook,…). You don´t need to do all these things (though that would be absolutely great!) but at least some of them.
*We reserve the right to freely decide which NGO/non-profit can benefit from our probono work. Third parties can be involved in the discussions but it is mandatory that the agreement to these conditions comes from the organization itself. Proof of the organization legal status could be requested.
The title, content, excerpt, publishing date, draft status,… of each page is copied to a new WordPress page.
In case your current site is in Drupal, you may choose whether you want to transform Drupal stories to WordPress pages or to WordPress posts. This will be discussed with you during the first stages of the migration.
This feature only includes the core data of each page (e.g. for Drupal 6 the data stored in the node and node_revisions tables). For sites using custom content fields please check this additional migration feature. Content is moved over exactly as it is stored in the corresponding table in the original CMS.
Webforms, views, scripts, shortcodes, php excerpts, etc in pages are translated as such, i.e. the corresponding posts in WordPress will contain exactly the same code. If you need a different behavior here, we are able to process any of these fields and transform them in order to be transferred to WordPress.
The new WordPress page will have the same HTML content as your corresponding current site, but obviously the visualization of that content in WordPress may differ (depending on your WP theme, the CSS you use, …).
The title, content, excerpt, publishing date, draft status, … of each post is copied to an equivalent WordPress post. Posts are linked to the corresponding migrated comments and categories/tags, if any.
The basic migration only includes the core data of each post (e.g. for Drupal 6 the data stored in the node and node_revisions tables). For sites using custom content fields please check this additional migration feature. Content is moved over exactly as it is stored in the corresponding table in the original CMS.
Webforms, views, scripts, shortcodes, php excerpts, etc in posts are translated as such, i.e. the corresponding posts in WordPress will contain exactly the same code. Adapting that code to work with the WordPress system is not part of this basic feature.
The new WordPress post will have the same HTML content as your corresponding site but obviously the visualization of that content in WordPress may differ (depending on your WP theme, the CSS you use,…).
If you need to migrate custom fields or any other complex characteristic to WordPress, please let us know and we will process them during the migration. You won’t left anything behind.
All comments are cloned and added to the corresponding WordPress post/page, including the information about the comment author, status and creation date.
If you are using Disqus, we can transfer your comments to your new WordPress installation as natural WordPress comments or, alternatively, configure your Disqus in WordPress.
All internal links (i.e. links to a relative path inside your server) to images, videos and other media files could become broken during the migration if you stick to the standard WordPress folder structure (different from your current site).
By default, WordPress assumes that media files are in the “wp-content/uploads” folder. Therefore, we update the internal references to all media files to this folder. Move the files there and they will come back to life immediately.
During a basic migration we update the HTML links (i.e. <img> tags) in the body of the posts/pages but it does not upload the referenced images in the WordPress Media Library nor adds the images as featured images for the posts. Contact us if you are interested in any of these features. We are able to move the files ourselves and establish featured images, if required.
If your current CMS configuration stores media files in a non-standard location and/or they are referenced using absolute paths let us know. And, for sure, you may also decide to keep your current media folders (e.g. to avoid moving the files around). In that case the URLs to those files will not be modified during the migration. Alert us before starting the migration if you prefer this option.
If your current site is in Drupal, term taxonomies can also be migrated as WordPress tags. Or, even better, you could choose the vocabulary in Drupal to tag posts and pages in WordPress, while using the term taxonomies to categorize them. This would allow you to have a double classification system for your data: tags and categories. Note that, unlike categories, WordPress tags cannot be organized in hierarchy, so you would lose that information during the migration of your Drupal’s categories to WordPress tags. Although, in WordPress, tags can connect horizontally both post and pages, which is great for your SEO strategies.
Drupal categories are migrated as WordPress categories. We keep the same category hierarchy in Drupal (if any). In WordPress, categories cannot be classified in vocabularies so categories of different Drupal vocabularies will be imported altogether. If category names are repeated in Drupal they will be slightly modified in WordPress (e.g. adding a “_”) due to a unique slug constraint in WordPress
Import all users to your new WordPress site. Name, email, bio, home page,… are imported. Depending on your current CMS (e.g. Drupal 6 but not Drupal 7) you can even keep the same password. Otherwise, you just need to tell your users to ask for a new password the first time they log in.
If you are requesting a Drupal migration, depending on the permissions the user had in Drupal, one of the predefined WordPress roles will be assigned to him/her. WordPress offers a limited set of information fields per user (in contrast with the rich user profiles you can have in Drupal) so your Drupal fields will be mapped to the predefined ones when possible. Additional Drupal fields will be migrated as user metadata (wordpress table usermeta) if desired.
Depending on your specific needs, the additional feature of migrating users to a BuddyPress installation could be suggested to complement the user migration.
Remember also, in case your current site uses Drupal CMS, that WordPress uses gravatars as profile pictures so user pictures from Drupal are not migrated over (if that´s a must for you we can discuss about possible WordPress plug-ins that could simulate this functionality as a complementary migration feature).
Most likely, it won’t be possible to guarantee that your new WordPress site keeps exactly the same page/posts URLs of your current site. WordPress offers limited possibilities to create the URL pattern for your site posts and this pattern will be applied to all of them without exception (for example, in Drupal, each post is assigned a full individual URL address so it’s easy to change the URL pattern depending on the type of post; instead in WordPress each post only stores a URL-friendly version of the post name, the full URL is created by WordPress adding the post name to the permalink structure common to the whole site).
To avoid damaging drastically the SEO of your site and losing all visitors trying to access your site using the old URLs, you should redirect all page/posts URLs of your existing site to the corresponding URLs in the new one. Our migration services take care of this task.
The solution we propose assumes that the domain name of your new WordPress site will be the exactly the same as the one used by your current site. In this case, we will use the Redirection plug-in to write the “301” redirection rules to redirect users trying to access the site using the old URLs to the new corresponding WordPress ones. The WP URLs must use /%postname%/ as permalink structure (or at least one of the standard permalink structures offered by WordPress) for the redirections to work adequately.
If that’s not the case (i.e. WP will use a different domain name or folder) it’s still possible to write the redirections (now modifying the .htaccess file of your Apache server or the web.config one if you use IIS). Contact us if this is your situation and we will evaluate the situation and if we deem it possible, provide a separate quote for this scenario.
A word of caution: redirections may not work with URLs using non-latin basic characters or other characters not recognized as valid by WordPress in its URLs. If that may be your case, let us do some tests with the kind of URLs employed in your site to make sure that we will be able to make redirections work for you (depending on the results of the test you may recommend to go for .htaccess redirection strategy instead). Also, in case of Drupal, titles should not contain duplicates.
Though usually not so important, you may want to redirect as well the links to categories/tags (so that people using your current site category/tag URL are redirected to the corresponding category/tag URL in WordPress). If that’s the case let us know and we will study your case.
By default, Drupal offers a few basic content types: page, blog and story (or articles, depending on the Drupal version you’re in).
Nevertheless, many Drupal installations include user-defined content types (e.g. you could classify your blog posts as reviews, surveys, opinion, reports,…). Our migration services make sure that Drupal nodes belonging to one of these custom content types are also processed during the migration and automatically transformed into standard WP pages (for Drupal nodes of type page) or WP posts (for all the rest).
Please note that this only covers defining the appropriate post_type attribute for each migrated post. It does not cover the migration of specific information attached to that type of posts. If needed, you can include our advanced custom types support or the custom content fields support in the migration.
Get a list of all your custom types and choose whether to transform them into standard WordPress post/pages or map them to one of your WordPress custom post types.
Please note that this only covers defining the appropriate post_type attribute for each migrated post. It does not cover the migration of specific information attached to that type of posts. If needed, we can discuss on migrating your custom content fields.
Many sites, such as Drupal ones, allows to add custom fields to nodes (i.e. posts/pages/stories) depending on the type of the node (e.g. for “audio” nodes, you could define as custom fields the name of the song, the artist, the CD,…). This information is not stored as part of the node but in an additional table structure. Therefore, a simple migration of the node body would lose all this extra information.
Our services allow you to convert also custom fields from your site to WordPress either as WordPress post meta-data or directly adding this information in the body of the post/page.
The use of WordPress plug-ins offering a more advanced custom fields functionality may be subjected to an extra fee, check with us for more information.
Our migration services are able to take care of assigning featured images to your posts so that, among other things, your theme can display the featured image thumbnail in the post index.
WordPress sets an image as the featured image for a post by linking the id of the image (as assigned by WordPress when uploading the image in the Media Library) with the internal id of the post.
We can migrate your galleries using the standard WordPress gallery shortcode . This standard support is powerful enough to cover the needs of most migrations.
Generally, to migrate a gallery it is needed to first upload all your images to the WordPress media library. We’d provide further instructions on that.
WordPress does not offer a core forum functionality as some other CMS, such as Drupal, does but it is still possible to replicate forums using one of the available WordPress forum plug-ins, like the BBPress 2.x forum, which is the one we strongly recommend though other WordPress forum plug-ins could also be used if desired (check with us the alternative you have in mind to see if it could work).
Let us know if apart from migrating the forum data you would also like to redirect the URLs of all forum posts to the new one. This needs to be analyzed case by case since forum modules / plugins usually follow a very free form URL pattern that may make difficult their redirection.
WordPress does not directly support multi-language sites. If your site needs to be available in different languages, you can either migrate all posts either as independent posts (i.e. a post available in your current site in languages A and B will be migrated as two independent posts, one written in A and the other in B) or use one of the available multi-language WordPress plug-ins to simulate the same functionality you have now in your current CMS (i.e. equivalent posts in different languages are linked together; a language selector takes care of displaying the post version corresponding to the selected language).
Our migration services will take care of migrating your multi-language site either as independent posts or linked ones using the powerful WPML plug-in (we are open to work with other multilingual plug-ins if you prefer another alternative, check this possibility with us).
By default, the migration process assumes the target WordPress site is a fresh installation and removes all existing content (by “content” we mean pages, posts, comments,… configuration tables are respected) before adding the new one. This is necessary to prevent the new data to clash with the existing ones (which, for instance, could cause errors to duplicate identifiers).
Nevertheless, the migration can be adapted to protect your existing WordPress content. We are able to take as input, apart from the site-to-be-migrated, your current WordPress site and makes sure that the converted data is added on top of the existing one without affecting it.
When using Disqus your comments are not stored in your current database but in the external Disqus servers. Therefore, a normal migration won’t be able to convert your Disqus comments in WordPress comments.
Nevertheless, since for some of you it was important to be able to import in WordPress ALL your comments, we are able to take the export XML generated by Disqus with your comments and insert them all in WordPress, linking them to the corresponding posts.
Migrate your current newsletters to WordPress using the WP Newsletter plug-in.
Convert all your current newsletters and newsletter subscribers to WordPress. Make sure you don’t lose your loyal followers when migrating to WordPress and ensure they keep getting email notifications of your site updates!
Migrate your current polls to WordPress using the WP-Polls plug-in. Migrate the questions, the set of possible answers for each question and the number of votes each answer got. Then, configure the plug-in and let WP-Polls to do the magic of creating the results graphics for you.
Tired of seeing duplicated categories on your WordPress site (with all the side-effects this provokes, like not being able to easily count all the posts of a “category” since in fact, that category, is repeated several times, each one used to classify a subset of all relevant posts for the category)?
We offer the possibility of consolidate all these repeated categories by 1 – removing the duplicates and 2 – assigning to this single category/tag all posts that were before assigned to one of the duplicates.