Migrating Wikispaces Content to WordPress

Wikispaces Is Closing

 

Please note – as Wikispaces shuts down some of this blog entry will be invalid. I also have went with a migration to Dokuwiki instead of WordPress so the demo links no longer work for the WordPress migration.

Wikispaces logoUnfortunately the site Wikispaces.com is shutting down, leaving a lot of us who have wiki’s there high and dry.  What did we expect, I suppose – it was free.  And now a lot of us need to find new homes for our wiki’s.

The problem is Wikispaces’ wiki format is somewhat proprietary so it’s not just a matter of exporting or migrating the site elsewhere, it’s just not that easy.  They do offer exports/backups of our sites in the form of static files like PDF’s and plain HTML files as well as what seems like various formats corresponding to different wiki formats.  Yet these latter file types are usually not 100% compatible with the formats they are exporting to, plus with the trouble of using command line sequences and figuring out exactly how to do that it is going to be prohibitive to most users.

So a lot of us, including a lot of those in education who were using Wikispaces, were out of luck.

One company came along – Civihosting, and created a tool for importing Wikispaces wiki’s into a Dokuwiki format hosted on their servers.  This is likely a great tool for those who have large wiki’s, and need them up and running right away with a minimum of muss and fuss.

Addendum 4/20/18 – A few more companies have come forward with Wikispace migration tools for their services; some of which may or may not work that well.  One that seems to be relatively economical and has been getting good reviews is Mywikis.com, they look very promising.

Addendum and side note – 5/29/18 – I love WordPress, but a few people mentioned that it wasn’t very wiki-like in the editing department and I set about doing a conversion to Dokuwiki as another test.  This was complex to convert but once I got it done it worked quite well and very nicely – so for interested I can also set up your Wikispaces wiki on on Dokuwiki too.  Here is our JeffCoWiki demo running on Dokuwiki.  Now, back to the posting…

A friend (Art) and I took over a historical wiki covering our local area, mostly historical but also a general ‘everything about Jefferson County’ wiki.  Occasionally a few people would register and make some edits, which was good, but I think for the most part Art and I entered the vast majority of data into the wiki, and I think Art by far added the most.  It has grown to 880+ pages.

When we found out that Wikispaces was shutting down in the near future we decided to start looking at alternatives.  We both did a lot of research and I did a lot of installing of various wiki’s in an attempt to try to import our wiki into them, with no success.  In a few cases a person more well-versed in a particular wiki format and command line options for its obscure import software may have been able to do the job but I was not.

I was able to set up a static test site by unzipping the HTML exports from Wikispaces and simply dumping the contents into a directory on a server.  It worked fine, but it is totally static and we definitely wanted to allow trusted contributors to add content.  So it was good for archival/temporary purposes but no good for long-term use.

We resigned ourselves to the fact that we might have to copy and paste every single page into another page on another site.  Not something we wanted to do, nor either of us had time to do – especially since links and such would have to be changed on every single reference, photos uploaded, etc.

I don’t like to refer to myself as ‘expert’ in anything, but I am very knowledgeable in WordPress.  I love WordPress, and about 30% of the Internet uses it for websites now.  I use it for all of my websites and you’re reading this blog on WordPress right now.

So I wondered if there was a way to import the large number of static HTML files from the Wikispaces export into WordPress.

Sure, I could create a Page or Post in WordPress, click the “Text” tab in the editor, paste a file into it, save it, and then go to the next one but, just like the idea of copying and pasting into another site; it was going to take a long, long time and there would have to be a of editing.

I started looking around and I found a plugin that imports any number of HTML files from a directory on the same server as the WordPress Installation.  

I’m a geek so my heart fluttered a little, I have to admit.  This was the answer to our problem, just maybe.

It turned out to be; I believe, though we are still testing it.  And unfortunately  it wasn’t just a simple matter of clicking a few buttons.  It was much more involved and was a fair amount of mucking about and experimentation to get things to work right.

But once I did get it right it was beautiful – a fully functional, fully trusted-visitor-editable wiki in WordPress.  And frankly it looks and works better than it did on Wikispaces, not to mention that in the future we can take advantage of all the functions of WordPress.  

I decided to look around and found that others were looking for solutions too, like on the Wikispaces-Refuges group.  While the Civihosting tool is the answer for some it may not be for everyone so I thought that I would share the fact that I had come up with an alternative, albeit it’s not anywhere as easy nor quick as the Civihosting one.

I decided to share the instructions here as I believe that information should be free.  But I also know that a fair number of people are not going to have the basic knowledge nor time nor interest in doing this.

So before I share the info I want to mention that for a fair wage I would be happy to do this for others, or help them – contact me here if you are interested.

A few notes here – I use”directories” here to mean both file storage structures on your own computer’s hard drive as well as the hard drive or SSD of a server, some people may call them “folders” or “sub-directories” – all the same.  Secondly I use the capitalized ‘Pages’ and ‘Posts’ to mean WordPress structures, and lowercase ‘pages’ as a general term for website pages, pages from a Wikispaces site, pages exported from Wikispaces, etc.

What You Will Need

*Firstly you need hosting and WordPress installed somewhere.  Most good hosting services have a one-click or easy installation of WordPress.  You don’t want to try this on WordPress’  free hosted platform – whether it would work with their paid plans I don’t know.  

I recommend Hostgator, Bluehost, or Justhost for hosting.

I would recommend a brand new blank WordPress installation as I think there is going to be some trial and error and resetting to get things to work right.  Theoretically you should be able to do this in an existing WordPress install with other content already in place, but if you import hundreds of files and need to start over again it is going to be harder to do if you already have content there.

For those who don’t want to invest in hosting yet, you COULD use a free hosting site for testing – like http://byethost.com or http://freehostia.com or whatever.  As long as they work fine while you are testing.  I just tested this on Byethost.com and it worked fine, but they are a little flaky; as many free hosting companies are.  Good for testing perhaps.

*Secondly you need an HTML export from Wikispaces. If you don’t know how to do this keep reading.

*Thirdly you need an FTP program (Filezilla is excellent and free – https://filezilla-project.org/download.php), or you may be able to use your hosting panel’s built-in File Manager.  Some File Managers let you upload multiple files easily – that’s what you need to be able to do, if your host’s file manager doesn’t let you do this you’ll need to use an FTP program.  If using and FTP program you need your login credentials for the FTP account.

*Fourthly you are probably going to need a text editor that will load multiple files and be able to search and replace across those multiple files – all without having to go to each individual file to do a search and replace.  If you have a smaller site with few pages you can probably just do the files individually.  We had 880+ pages so it was integral to be able to do a mass search and replace across ALL files at once.  Notepad++ works fine and is free.  Familiarize yourself with it a bit after installing it (or whatever you are going to use to edit multiple files).

*Fifthly – you probably should have some basic knowledge of WordPress and using it, as well as a basic understanding of file structures and URL’s and uploading and unzipping and maybe a little knowledge of HTML…  You don’t have to be an expert in any of these but you need to understand the basics.

So On To It…

The first thing you want to do is export a zipped HTML file of your entire wiki.  Go to your wiki, click Settings and then “Export/Backups” and it should default to HTML, if not select it under Content Type.  Leave the file type as ZIP and then click Export.  Download the file (it may take a bit if you have a lot of stuff to export) and open it – it will either open in a Windows’ explorer-type of window or it will open in whatever archiver program you have associated with ZIPs.  7-Zip is a good free unzipper.

Wikispaces screen

Create a directory on your hard drive to hold these files and copy or extract everything in the zip to this directory, including subdirectories included in the ZIP (make sure your archival program will duplicate the directory structure so  that everything isn’t jumbled together).

When it is finished if you take a look at the directory that you extracted the ZIP to you will see that your entire wiki is there – the wiki pages are in HTML, your photos and docs are in a FILES subdirectory, your entire master style sheet is in the STATIC subdirectory, and all of your discussions are in the DISCUSSION directory (in JSON format – more about this later).

Directory

Now either connect to your hosting using an FTP program or go into your hosting control panel and access the File Manager there.  Create a directory on your hosting space in the same root as your WordPress installation, but not inside your WordPress Directory (unless you installed WordPress directly to your root directory on the server, though really it’s okay where you ever you put it as long as it is on the same server).  In other words the directory you create will show up in the same directory that contains the WordPress directory.  This isn’t a big deal as long as you know where the directory is, as you’ll eventually want to delete it.

So it might look like:

wordpress
html

If you installed WordPress directly to your root directory the HTML directory can be mixed in with WordPress’ directory and files.  As I said – no big deal as long as you know where it is and delete it afterward.

Enter the directory you created and upload everything from the directory on your harddrive containing everything from the previously unzipped file wiki HTML file.  Upload everything including the FILES directory as it will import all of your photos and such too.

Once that is finished uploading close your FTP program for the time being log into your WordPress Dashboard, click ADD NEW under PLUGINS.  In the search box enter ‘HTML Import 2‘ (created by Stephanie Leary) and scroll the screen down until you find the plugin, install and activate it.  

Using WordPress for your wiki works just fine, but to make it work even better and more like a ‘regular’ wiki also install Yada Wiki plugin (by David McCan).   This plugin allows you to link wiki pages together with the titles of the wiki pages.

I would recommend also installing the “Reset WP” plugin (by Nikunj Soni) so you can experiment with a fresh database and settings each time until you get things right, as you are probably going to be changing some settings here and there and wiping everything if things aren’t correct.

Once those plugins are installed and activated go to Settings in your WordPress Dashboard, select “Permalinks” and select “Post name” then go down and click “Save Changes“. 

Now you are ready to go into the import plugin.  Go back to Settings and click “HTML Import“. 

At this point I would recommend using a note pad (either on your computer, phone, tablet, or on real life paper) so that you can keep track of the settings you use and the results.

On the first tab at the top at the HTML Import screen you will need to enter the absolute path to the subdirectory where you uploaded your HTML files and such.  There is a hint and part of it should be filled in, you’ll need to take out some of what is filled in and refer to the hint to figure out your absolute path.  The path should consist of the hint after you replace the ending part, where your WordPress directory is installed, with where your HTML files are stored.  

If the hint shows /home2/server/public_html/wp and the directory where you installed your HTML files is called ‘html‘ then the absolute would be /home2/server/public_html/html

Under “Old site URL” enter the complete URL of where your HTML files are stored, not really important as you won’t be using this for redirects anyway.

Beside “Default file” you can file in home.html here.

For ‘Preserve file names‘ I left this off, thought I experimented with it a bit. 

Click “Save Settings“.

Click the next tab at the top called “Content“, I selected “Import entire file” here but I don’t think it matters.

Beside “More content options” I selected “Import linked images” (this will import all of your images and put them into your imported pages and everything – there won’t be any need to mess with importing them separately) and “import linked documents” (if you have anything beside graphics).

Next select “Update internal links” (this latter didn’t seem to do anything but if it works for you it will save a lot of extra work).

 Click “Save Settings“.

On the next tab – “Title & Metadata” select “HTML tag” beside “Select title by“. 

If you want the name of your wiki preceding the name on each Page or Post (or Yada Wiki page) in your browser’s title bar than you can skip “Phrase to remove from page title:” but I would recommend opening any one of the HTML files from your wiki into a text editor, and look at what is in the <TITLE> tag.  Your wiki’s name will probably be in every single HTML file – if you don’t want them displayed with the title of each Page or Post (or Yada Wiki page) enter the name, a space, the dash, and another space into “Phrase to remove from page title:“.  On our wiki the title looked like this:

<title>JeffCoWiki – Jefferson County Pioneers</title>

So I entered “JeffCoWiki – ” into the “Phrase to remove from page title:

Alternately you could remove this from each file using the mass search and replace methods shown below, using a text editor.

You can try it on a few imported pages and see how it looks but I would recommend removing the title, as it’s annoying.

HTML Import screenFor the ‘Import files as” I highly recommend selecting Yada Wiki pages (Wiki Pages – if you did not install the Yada Wiki plugin this will not be a choice).  For the rest of the options on this page you should be able to leave them as-is unless you want to use a specific template for the Pages/Posts/Wiki Pages that are created.

Before trying the Yada Wiki plugin I experimented with converting the HTML imports into Pages as well as Posts.  If you are not using the Yada Wiki then you probably want to go with because A) you can display and edit tags, categories, edit dates, etc – otherwise if using Pages B) when you add editors/contributors their WordPress dashboard bar along the top of the screen will default to creating new Posts when clicking New. 

Click “Save Settings“.

Make sure you have a notepad and write down your settings and results, as I mentioned above. 

Near the top of the screen you should see a message that says ‘Settings saved. Ready to import files?“.  

On the next screen make sure where it says “Your files will be imported from” has the correct URL – though right now we aren’t going to use this but you might want to check on it anyway.  This is where your HTML files were uploaded to on your server, just to remind you.

Now I would suggest importing one or two files and see how things look, and what you want to try and do here is to find a couple of files that would have links to each other so that you can check internal linking.  You may want to refer to your original Wikispaces site or look through a few of the HTML files on your hard drive, etc to find a few pages that have links to each other or some type.  Depending on your wiki and how you had things organized there may or may not be many of these, I suppose.

To import a couple of files for testing this select “a single file” and then click “Choose File“, which will bring up a regular dialog box where you can select a file on your hard drive from the directory where you originally unzipped the HTML files.  This only lets you choose one file at a time so you have to go back to HTML Import and click Save Settings (without changing anything, or add “?import=html” to your admin URL) to get the “Ready to import files?” link at the top again.

You may want to do this a few times to get a couple of files to play around with.

Now go to one of the Pages or Posts or Wiki Pages (if you installed the Yada Wiki plugin) that you imported (view them via the link shown after you import or by going up to “Pages” or “Posts” or “Wiki Pages” in your WordPress Dashboard and clicking “View” under one) that you know has links to another Page or Post or Yada Wiki Page that you uploaded.  Click one of the links that should take you to another uploaded Page or Post or Wiki Page.  If your wiki HTML files are like mine (where the original Wikispaces page titles/link have spaces in them) you’ll notice that these links try to take you to a Page or Post with spaces in the filename.  

As far as I can tell the plugin is supposed to fix whatever links are in each imported Page/Post/Yada Wiki Page to show the correct link of other files imported, in this case Page/Post/Yada Wiki Page names with spaces should be replaced with dashes.  It does not on the test installations that I tried.  

WordPress does not work with spaces in its Post/Pages/Yada Wiki Page titles/url’s so it will replace them with dashes internally. 

I have seen a few Wikispaces sites that seemed to have +’s or no spaces in the filenames, in those cases you may be able to skip much of the below instructions as pertaining to replacement of spaces.

So now we are getting to the tricky part and this will probably take some trial and error and experimentation, so be patient.  If you didn’t have a lot of pages to import you COULD skip this whole search and replace section and import your files en mass at this point and edit each Page or Post or Yada Wiki Page manually.

Mass Search & Replacing

Also see the comment posted in the Comment section below by Tom Holden on a better search and replace procedure  which should eliminate external links from being found and changed, if needed.  

I will explain how to replace the spaces in the internal filename references in a bit but I also noticed that once I corrected the spaces and converted them to dashes, the URL’s wanted to load into my server’s root directory, which was wrong for my installation.  You may not run into this problem if you installed your WordPress in your server’s root, but if you installed it in its own directory then you may have to fix not only the spaces in the filenames but also prepend the full address for before the internal links.  If you are not sure you can do it anyway as it won’t hurt anything.  

It’s a lot easier than it sounds, to do this.

At this point you will need to break out the multi-file editor.  See the beginning of this post for info on what you need.

In your multi-file editor load all the HTML files from the directory on your hard drive where you had unzipped them (but not anything from the sub-directories at this point).  You can usually use the editor’s Open Dialog box or select all the files in the directory using a file manager window (CONTROL-A or COMMAND-A on a Mac) and drag them into the editor.

If you have a LOT of files this may take a few minutes to load, be patient.

In the HTML files you will find the internal links to other pages look like this –

<a class=”wiki_link” href=”Adams%20Center.html”>Adams Center</a> (hamlet)<br />

So what we need to do is take the ASCII code ‘%20‘ (which means a space) and convert that into dashes so that all internal links will be correct to conform with how WordPress saves internal links.  

Find your editor’s Replace option, in Notepad++ it is under the Search menu.   Enter %20 in the Find field, and a dash (-) in the Replace or ‘Replace with‘ field (depending on what editor you are using).   In Notepad++ click  “Replace All in All Opened Documents“, if you are using some other editor you will have to find the option to apply this to all opened files.

Multi-File editor screen

The replacement process should be fairly quick, once it is finished check a few files to make sure everything is correct.  

It may be worth it at this point to do a simple search in your text editor for things like other ASCII URL encoding characters in the form of ‘%26‘ (which would be the ampersand character for example) that references an internal link.  Either change them manually in each file or do another mass search and replace if you find it happening a lot in the HTML files; replacing them with their actual character equivalents.  In other words use %26 as the Find, and & as the Replace.  Look for common things like %28 (left parenthesis), %29 (right parenthesis), etc and replace them with the actual characters as above.  Here is a good reference.  You may or may not have any of these characters as part of your Wikispaces page titles, depending on how you and your contributors named things so don’t be surprised if you find none of these characters in the internal references to other pages in your wiki.

Now to change the overall location to be correct. 

Again, if your wiki files do not have spaces in the filenames you can skip the above, but you may still need to adjust the overall URL’s for internal links.

So you should have something like this – 

<a class=”wiki_link” href=”Adams-Center.html”>Adams Center</a> (hamlet)<br />

Now you want to insert the WordPress installation’s full address before each internal link.  Only the internal links of course, we don’t want to accidentally change any external links if you have references to outside websites, if we can help it.  To do this:

Go back into Replace and enter “<a class=”wiki_link” href=” (without the outside quotes) into the Find What field and in the Replace with: field enter “<a class=”wiki_link” href=” followed by your WordPress’ full address with a trailing slash, like this –

<a class=”wiki_link” href=”http://somesite.com/

or this –

<a class=”wiki_link” href=”http://somesite.com/wordpress/

Check this replace box over to make sure everything is correct and then click “Replace All in All Opened Documents” or equivalent.

Once it has finished heck a couple of the files to make sure everything looks right.

Remember – if you totally screwed something up you can always extract the original ZIPPED HTML files again, and refer to your notes.

Go back to your WordPress installation, go to Settings and click “HTML Import” then click “Save settings” at the bottom and look for the ‘ready to import files?” link at the top.  Again, upload and try a few files here that are linked to each other (possibly you want to delete any previously uploaded test pages).  If everything has been edited correctly any internal links should work just fine.

If all is not well check your Permalinks setting in WordPress, and go to the Page or Posts or Yada Wiki Page editor in WordPress and take a look at your internal inks to see what is happening.

If all did go well either go into the Page or Post or Yada Wiki Page editor in WordPress and delete the Pages/Posts/Yada Wiki Page that you had uploaded, or use the ‘Reset WP‘ plugin to reset everything (you’ll need to log back in and re-enter all of the settings you wrote down in the earlier step, back into the HTML Import plugin).

Now that you know things have been edited correctly on your computer and the individual files uploaded look fine – you will need to re-upload all of your HTML files into the directory you created previously, overwriting what you had originally uploaded.  In fact you may not have really needed to uploaded them originally.  But at this step when everything was looking fine I liked trying a few dry runs by uploading everything a few times and them making some changes here and there, resetting, and re-uploading them.  But you don’t have to do this if you do not wish, but if you didn’t before now is the time to.

In HTML Import (again, click Save settings to get the link to come up along the top or add “?import=html” to your admin URL) you can now leave ‘a directory of files‘ selected and click Submit.

After awhile (depending on how many files you have) it will finish, giving you some status updates for any problems found.

Take a spot check view of some of the Pages or Posts or Yada Wiki Page that you imported, and make sure the internal links are working correctly.  If they are not you may have to use the Reset WP a few more times to play around with changes and make any replacements or corrections in your text editor, re-entering your HTML Import settings from your notes as needed.  It may take a few times to get everything working right if you are not very familiar with some of the process of using WordPress, editing HTML, etc.  Look for any more internal links that add ASCII characters to file names and change them to their non-ASCII equivalents (as shown above, if you find that you have a lot you might find it easier to do another mass search and replace and reset everything again and re-upload/re-import).

Once things are working well you can disable and delete the HTML Import plugin and Reset WP plugin.  If you are sure all is well you can also delete the HTML directory off your server (you still have your edited files on your computer of course).

All of your internal images should be embedded in their proper places, all internal links should work, and rudimentary formatting should be in place (paragraphs, image sizes, etc).

Now you’ll want to cleanup any problems you can think of or run into.  One may be external links that had a space in their website/webpage names.  The search and replace process we used earlier will have replaced those with dashes, so you’ll want to use WordPress’ Page or Post or Yada Wiki Page editor to fix anything like that.  Anywhere images or documents referenced externally should be checked for broken links, certain things like JavaScript and various embedded functions from external websites may need some help – sometimes in the form of switching back and forth between WordPress’ “Visual” and “Text” editor tabs.

If you imported everything in Posts or Yada Wiki Pages instead of regular WordPress Pages you might want to change some master Post-type items to Pages instead – like the Home Page (home).  Personal preference here whether you do or not.  You can use the plugin Post Type Switcher to do this (or comparable plugin) , otherwise the only way to convert a Post to a Page or Yada Wiki Page (or vice versa) is to copy its content from its current type to a new one of the type that you want it to become.  If you change post types in WordPress you do not have to change any links as it does not distinguish between Post types and Page types or Yada Wiki Pages  in the internal links to them.  Just make sure that you do not have both a Page and Post or Yada Wiki Pages with the same name.

Once that is finished (which may be quick, or may not be!) you will want to check your index/home page for the site.  In the previous steps in the HTML Import plugin we set ‘home.html‘ as your home page.  

Likely this is going to be missing some things, like the menu that was displayed in Wikispaces along the sidebar.

Create a new menu in WordPress corresponding to the menu you had on Wikispaces – either referring to your original Wikispaces’ site or loading the file ‘space.menu.html‘ into your browser to view what it looked like.  Most WordPress themes allow a sidebar so once you create your menu and save it, you can go into the WordPress Widgets and insert a menu into the sidebar, or assign your menu to your theme’s main navigation area which is probably going to be a more modern horizontal menu.

I did a little of both – I created two menu’s; one for the sidebar and one for the top horizontal position with different menu purposes/items in mind. 

I also created yet another menu with links to user registration, login, log-out, profiles, etc. that would appear in the sidebar for editors.  In the WordPress settings I made sure that no one could post anonymously, and that all registrations have to be approved by an admin – to keep spammers out.

Other widgets to perhaps add to your sidebar – Search (though you may have this option in your top menu and not want to duplicate it), social media links, top pages and comments, and things along those lines.  Take advantage of the things you can do with WordPress that you couldn’t with Wikispaces!

Check out your theme’s settings in Customize under Appearance in WordPress.  In your original UNZIPPED directory you will find a sub-directory called “static” which has your Wikispaces’ style sheet.  You can refer to this as well as your original Wikispaces site for colors and styles for your WordPress theme.  How you do this may depend on the theme but usually you will find this under WordPress’ Appearance and then Customize.

I also recommend installing plugins like Jetpack, a security plugin like Wordfence, bbPress for a discussion forum (there are many plugins that go with this to enhance it also, and you might want to put a little work into integrating it into your wiki), a related posts plugin like Contextual Related Posts, a user editor like User Role Editor (this will give you better control of what your users and contributors can and can not do), if needed Post Tags and Categories for Pages so that you can have categories and tags for Pages just like for posts – if you imported everything into Pages instead of Posts (though these will not display publicly on Page type without a little code hack), and a backup plugin of some sort (there are many but I like Updraft and BackWPup), and perhaps a revision display/control plugin (still looking at various ones for this).

You can also easily switch and test themes – there are thousands, though I recommend Cryout Creations themes – they are extraordinary.

After playing around a bit with the home page, additions, menus and themes and all the rest you should have at least a working, usable wiki at this point.  WordPress is awesome, but you can spend hours customizing and adding to it.

Yada Wiki Plugin

Yada Wiki Pages screen

If you installed the Yada Wiki plugin (by David McCan) you will have some additional nice Wiki-style options in the WordPress editor bar (while in the Yada Wiki page editor) as well as expanded functions that make your new wiki act more like Wikispaces (and other wiki’s) do.  You might want to check out the video tutoial on using it.

One of the things that it does is it gives you and your editors/contributors the ability to quickly select other internal links via a button in each Wiki Page, very similar to how Wikispaces was set up (versus having to fill out the entire link when using the usual WordPress Insert/Edit Link button). 

Yala Wiki links enter windowClicking the Add Wiki Link button brings up a link window, which allows you to start filling in the link name.  If there is a page with that name it auto-completes it and you can just click “Insert Shortcode” (or add a more description name in the box below called “Show:”).  If the page has not been created as yet a link is created that will only show to a user who is logged in and has permission to edit pages, to all others it just shows the text name with no link (as there is no page there yet).   

For those who are logged in and have their permissions set to edit the Wiki Pages the link is clickable and takes them to the Wiki Page creation screen, again similar to Wikispaces.

The Yada Wiki plugin also gives you the ability to add a Table of Contents and shortcodes to insert it into other Pages/Posts/Yada Wiki Pages, a sidebar widget, and more.

There are a few options, like the option to turn on or off the ability to quickly link to Wiki Page links both in Posts and Pages as well as Wiki Pages.  Read the instructions if you need more info.  i highly recommend using this plugin for your wiki.

A few things to finish this up.

If you relied on tags while using Wikispaces there does not seem to be any way to export these from Wikispaces.  You will probably need to enter these manually for each Page or Post or Yada Wiki Page, referring to your Wikispaces site as you do so perhaps.  Or just not worry about them for now and allow WordPress’ own search to find subjects you and your visitors are looking for. 

Your member list is not exported either so you probably want to contact each of your members on Wikispaces who have edited and participated in contributing to your Wikispaces’ wiki and get them to register on your new WordPress site, which is easy.  You may want to provide links via the main WordPress menu, a secondary menu, sidebar links, or something like that to make it easier for people to find out how register, log in, and update their profiles.

Comments and discussions are exported in JSON format, and saved in the ‘discussion’ directory in the ZIPPED HTML export from Wikispaces.  There’s plenty of converters, or you can use a mult-file editor to convert it into HTML or strip out any codes and paste them in directly.   Or use a JSON converter like http://json2table.com/ or perhaps this better one – http://json2html.varunmalhotra.xyz found by Tom H.

We did not have very many discussions, and a few could be discarded anyway, so I added them to an ‘Archived Discussions’ Page.      

As time goes on I may tweak this blog post (or in some cases correct it), and add to it.  While I have tested all of the above a few times with additional test installations of WordPress as well as a couple of other’s exports I can not guarantee that you may not run into other issues, or heck – maybe it just won’t work for you at all. 

And for a little bit of self-promotion here – as I mentioned earlier in this post I am available to convert and set up a similar WordPress copy of your wikispaces wiki for you, or a Dokuwiki conversion (see my addendum note near the beginning of this post and here is our JeffCoWiki demo running on Dokuwiki), just contact me.

If you need a place to talk about migration or just commiserate you can join us at https://wikispaces-refugees.groups.io 😉

Until Wikispaces shuts down you can see our original wiki at Jefferson County NY Wiki at Wikispaces.com and for the time being you can check out our Jefferson County NY Wiki testing/temporary holding WordPress export here.

If you have any questions or comments or corrections please drop me a comment below.  Good luck.

 

 

12 Comments:

  1. What a great read! I agree with you 100% it’s all about WordPress now. 100% of my sites professionally and personally are run with WP.

    Thank you for saving me about 20 hrs of research on this topic. I have a few clients that will be calling me soon about this. Maybe I can send them your way 😉

  2. Thanks, and glad you enjoyed the post!

  3. Great stuff Marc and with every detail covered. I have about 4 or 5 Wikispaces to consider migrating, wondering about trying a WP multisite to house them together, share the themes, plugins, etc.

  4. Marc, I’m working my way through your excellent instructions but I have yet to import. For the replacement of %20 et al in internal links, I used Notepad++’s Regular expression search and replace rather than the Normal. Simply searching for “%20″ can hit external links that should not be changed. So I use the following:
    Search: (href=”[^:^”]+)%20
    Replace: $1-
    The ^: prevents any http: like strings from being found, indicative of an external link, although and it should not miss any pages because I think it was a forbidden character for titles.

    The find & replace operation has to be repeated until it reports 0 occurrences found because it replaces only 1 instance of %20 in the URL each time.

    The terms can be readily changed for other values, for example, the left parenthesis:
    Search: (href=”[^:^”]+)%28
    Replace: $1(

    A search term that shows all remaining occurrences of % codes in the hrefs:
    Search: (href=”[^:^”]+)%
    Once its result set is small enough, manual editing is efficient for the outliers until this search shows 0 occurrences.

    Do links to image and other non-page files have to be changed? If so, then the above procedure could be revised, e.g.,:
    Search: (src=”[^:^”]+)%20
    Replace: $1-
    and so on…

    • Very nice! Thanks – I will add a note to my post to point people to this comment for a better search and replace for those who need it.
      Yes, any internal image/document/file links for anything stored on the Wikispaces site must be changed also.

  5. 1. In addition to making the internal links have “-” instead of “%20” et al, they need to be stripped of the “.html” suffix.

    2. In my case, 000webhost installed WordPress in the root and I uploaded files to /wsfiles. Importing as Wiki Pages, I found that prefacing the internal links with the relative path “../” worked correctly.

    Combining these two into a regular expression search and replace across all html files:
    Search: wiki_link” href=”([^#^:^”]+)\.html
    Replace: wiki_link” href=”../$1

    However, the media and other files in the servers’s wsfiles/files subfolder are not being imported so I will have to play more with that. OTOH, importing a single file from the pc does import the media files from the pc.

    • You shouldn’t need to strip andy .HTML off the files, the importer will handle that, make sure you have Permalinks switched to “Post name” and all should be good.
      For the media and other files make sure in HTML import that you have the options ‘Import linked images’ and ‘Import linked documents’ turned on.
      I’ve imported my own and various other wiki’s now and so far it’s all worked perfectly.

      • I’m not stripping the extension from the files, rather from the URL in the internal link. I uploaded one change at a time. It wasn’t until the internal link in an HTML file looked like this that the imported link in WP point to the imported page:
        Source List Query
        This did not work:
        Source List Query

        I do have the options on to import linked images and documents and it works as expected when importing a single file from the local drive but does not when importing a directory of HTML files from the web host. No media is imported into the Library and the link to an image looks like this:
        https://xxxxxx.000webhostapp.com/Source-List-Query/files/RMtrix_tiny_check.png

        I know that I can ultimately fix the link by search & replace on the Pages but the first step is to get the files to import. They do from the local drive, one HTML file at a time, but it seems you can only import a directory of HTML files from the server and that’s where the importing of linked media et al files fails.

        000webhost is running PHP7.1, default database engine is InnoDB on MariaDB 10.1

        The Import HTML 2 plugin also seems to be flaky. Sometimes left with a blank window or one which says “HTML files importing”. I’ve taken to deactivating and reactivating between import attempts although I am not sure there is any benefit.

        Thanks for any insights…

        • Hmmm, I know in the comments for the HTML Import plugin others have had similar problems as you are so it may have to do with the configuration of the host, and beyond our control.
          I think you could shortcut the media problem somewhat by just dragging and dropping all of your media files into the Media | Add New upload screen and then using mass search and replace on your HTML files to point them to where WordPress put them.

        • I’ve made some progress without resorting to the bulk add of the media et al files and am seeing linked image files and a linked .docx file being imported into the Library when a page is imported.

          For the image files, I had to preface the exported URL with a slash:
          <img src="files/RMtrix_tiny_check.png" became
          <img src="/files/RMtrix_tiny_check.png" and as served the address is:
          https://xxxxx.000webhostapp.com/wp-content/uploads/2018/03/RMtrix_tiny_check-4.png
          The importer does import the file into the database, attached to the imported Page and the image link on the Page is to the attached image.

          For the linked non-image file, .docx, in the "files" subfolder of the Wikispaces HTML export and uploaded to the "files" subfolder of the /wsfiles directory, the same thing applied:
          href="files/Alternate%20Name%20Typo%20Steps.docx" became
          href="/files/Alternate%20Name%20Typo%20Steps.docx" and as served, the URL is
          https://xxxxxx.000webhostapp.com/wp-content/uploads/2018/03/Alternate-Name-Typo-Steps.docx

          The importer took care of the conversion of %20 to "-" for the hyperlink.

          So, having defined the Directory to import in the HTML Import settings to be "/storage/ssd4/898/5229898/public_html/wsfiles", I think that becomes the root for import but the importer does not see "files/…" as a valid path and wants "/files/…"

          • The holiday weekend has interrupted my flow and the last thing that happened was that I realised HTML Import 2 behaves poorly importing a directory of many files and, maybe, inconsistently. I didn’t realise that there was a progress report or log until I imported a server directory of but 1 file – I had seen it when importing 1 file from the local drive but whenever I tried the directory of 267 pages all I got was a blank screen, except once. So being more patient, I had yet to see a log again until I tried breaking the directory import into sets on the order of a hundred files. Now it starts reporting after some 20 seconds (maybe the free host is slow…). Got a full log on the 1st batch but it has hung with the second batch at “Fixing relative links”, the very last step. Unfortunately, it does not say what it got hung up on.

            The third and final batch of 59 went okay.

            The log reports some errors in not being able to find certain media files. I now have a list of 31 to go through. One of the causes may have been previous edits to the exported HTML files for links containing URL encoded characters such as %20 getting into links to files. More digging to do but getting closer to a full transfer of all but the Wikispaces Discussions & Comments.

            In this process, I’ve found a couple of bugs in the Wikispaces HTML Export, reported at https://wikispaces-refugees.groups.io/g/main/message/57 . I spent a lot of time fixing these but one should not have to!

  6. Another issue I have run into with HTML Import 2 is one that may apply to any transfer to a host that prohibits and blocks certain file types. In my case, I found that the FTP service blocks the upload of .bat extensions. This was not immediately apparent because they constitute a tiny fraction of the total. And the HTML Import 2 log was not leading me to the cause. When I imported a single page from the local drive it reported that the linked .bat file which was on the local drive could not be found on the server. Yet Filezilla also reported that the file was successfully uploaded. But I could not see it in the server’s file list. It wasn’t until I renamed the .bat file to .bat.bak that it then uploaded and stuck to the server. I was able to rename it on the server back to .bat and it remained (at least for the time being). The HTML Import from the local drive was then successful at bringing the file into WordPress.

    As this could well be a common practice across many hosts, it is advisable to change the names of files with extensions such as bat, cmd, exe to have the further extension .bak, before uploading to the new host. But that also means changing the links thereto in the pages. Therefore, the sensible place to do so is on the Wikispaces site itself, even though it is a very clicky process. Then all subsequent backups/exports have that risk eliminated.

    That said, exe and dll files were imported by HTML Import 2 – only the bat files have been identified as an issue.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.