Multi-site multi-language Markdown-styled WordPress network

adminWordPress0 Comment
12 min. reading

I’ve set myself quite big goal. To setup:

  • multi-site WordPress network (with top-level domain mapping),
  • with multi-language support,
  • that will use Markdown,
  • with auto-generated table of contents, based on headers and
  • with “coming soon” / “under construction” page for not ready sites.

To achieve my goal, I needed a bit tweaked version of WordPress (network) plus a bunch of plugins.

WordPress network

It all started with installing a standard WordPress edition and converting it into network. These Codex articles were quite good lecture for this:

I had no troubles converting my first blog into network and I was doing a clean install with no plans to migrate any existing blog into newly created network. Thus, I skipped following articles:

Basically, everything what I had to do, was to:

  • login to my blog’s FTP server,
  • add define('WP_ALLOW_MULTISITE', true); to wp-config.php,
  • refresh browser,
  • go to Administration > Tools > Network Setup.

Then I followed on screen instructions.

Plugins

To the list of four plugins selected by me to achieve my goal (details below) I’ve added two “standard one”, that is antispam and stats:

  • Akismet 2.5.6,
  • WordPress.com Stats 1.8.5,
  • WordPress MU Domain Mapping 0.5.4.2,
  • Polylang 0.9.4,
  • Markdown QuickTags 0.8.2,
  • Markdown on Save Improved 2.2,
  • underConstruction 1.08.

Here is detailed info on steps, I took or issues I run into, when installing each of above steps.

Akismet & WordPress.com Stats

Website: WordPress.com Stats + Akismet.
Reason: Spam prevention and blog stats analyse.

Akismet is build-in, but WordPress.com Stats must be downloaded and installed separately. No special work must be done here, except for providing API key for both. Plus registering all my new blogs within Stats network.

For Akismet, enter it upon request (message displayed on every page that API key need to be provided) or use Plugins > Akismet Configuration on every page you to secure from SPAM with Akismet. Must be done manually for each page in blog network. Can’t be done generally for whole network at once.

For WordPress.com Stats, also enter API key upon request or use Settings > WordPress.com Stats. Also must be done manually for each blog, which stats you want to analyse. Can’t be done network-globally.

WordPress MU Domain Mapping

Website: WordPress MU Domain Mapping.
Reason: Possibility to use top-level domains instead of sub-domains or paths in WordPress network.

After installing this plugin, do not Network Activate it! Due to some error in this plugin current version, it must be enabled manually for each site, for which you want to add domain mapping.

It can’t be enabled globally for entire network, because you won’t be able to see dashboard subpage for this plugin in each blog (Tools > Domains Mapping).

You can always use Settings > Domains in Network Administration page, but adding domains through that module is less convenient then using panels in each blog.

Before activating this plugin in each of your blogs:

  • copy wp-content/plugins/wordpress-mu-domain-mapping/sunrise.php to wp-content/sunrise.php,
  • remove comment from the line define('SUNRISE', 'on'); in wp-config.php or add this line, if it gone.

Then go to Settings > Domain Mapping in your Network Admin Dashboard and add your server’s IP address in first field there.

If your server does not automatically translates www.domain.com into domain.com, then you have to play around all that CNAME stuff (second field in this section). Mine does, so I skipped this part.

To learn how (and for what) to use all checkboxes in this section, please consult finest Otto’s Blog post.

Please note, that it is 2,5 year old and mostly outdated. Don’t read on too much about other things except checkboxes meaning. Especially forget about installation part, as it contains many misleading information (because is very old and plugin has migrated).

For any installation issues, consult proper section in the plugin page itself.

After adding IP address of your server and setting configuration, activate this plugin in each of your blogs. Once, it is active, you can access Tools > Domain Mapping section in all your blogs and add preferred domain for each of blog.

Polylang

Website: Polylang.
Reason: Plugin to store and manage multi-language posts on your sites.

This one stores as many language versions of each post, page etc. as you want within post taxonomy itself. Other plugins allows to switch language versions, each stored in different network, site. If you want to add new language version, you create new network’s site.

With Polylang you can keep different language versions within post or page and each blog’s element can have different set of language version (not everyone have to be in every language).

When trying to use this plugin I run into two issues (described below). After thinking-over this a little bit, I have changed the idea of my blogs network (from poly-language to having separate site for each language), so I did not needed this plugin anymore.

Even so, I decided to give you some description of problems I have found, as you may also run into them:

First problem was, that even though language selection was remembered across navigation to other posts or pages and remained correct, it was always reset to default English language whenever user clicked logo or entered direct blog URL (domain).

Next, I’ve set language to each blog and in general section it worked fine — i.e., when I selected one language, I saw only posts that have the same language set; when I switched to another language, list of posts were correctly changed, again to display only those, which have currently selected language set.

Things got a little bit wrong, when I clicked on any month in Archive section — I don’t know why, I saw posts mixed, some from current language (not all!) and some from other ones. This is the most important disadvantage that lead me to a decision of uninstalling this plugin.

I’ve reported these issues to plugin author, but — as I mentioned — I resigned using this plugin, so I did not follow that issue report anymore after.

Markdown on Save Improved & Markdown QuickTags

Website: Markdown on Save Improved + Markdown QuickTags.
Reason: Two plugins for writing WordPress posts in Markdown style (which I love!).

There are a lot of plugins for WordPress doing so. I’ve chosen Markdown on Save Improved, because it stores Markdown formatting in a separate column, which requires only one conversion (during save, as name suggests) and allows turning off plugin anytime (like I would ever think about it! :]), getting back to HTML version in one click.

Other plugins replaces HTML style with Markdown in the same (default) post body column (which is bad after all) or does on-the-fly conversion (like famous WP-Markdown plugin) from HTML to Markdown (on save) and back (on display). Which is not only much slower, but also can produce strange results, as Markdown-to-HTML conversion is experimental in most cases.

As for Markdown QuickTags, all was fine. I only missed a little bit some common tags (complete absence of header tags — either # or - / =). But that was just a very minor disadvantage.

Using main Markdown on Save Improved is also painless. One just have to remember that direct Markdown edit is enabled by default only for new post / pages etc. As for existing one, option “Disable Markdown formatting” in “Markdown” section is check, which means, that even if you enter new Markdown tags into that text, it will be ignored. You have to unchecked that option and manually convert all HTML tags to Markdown ones or let the plugin do this automatically.

Auto conversion was experimental in version I first time installed, and could be done two ways — either by checking “Convert HTML to Markdown (experimental)” and updating post or clicking “Markdownify” button bellow main edit field to do on-the-fly conversion and directly correct mistakes, if any.

Plugin renders HTML code basing on your Markdown and saves it to base content column in the database, while writing Markdown code to separate one. This lets you deactivate or even throw the plugin away and don’t loose anything on your formatting (after delete / deactivation, base content column will be used, while with plugin enabled, it is overwritten with Markdown contents from extra column).

This means, that processing Markdown happens directly before saving post. The bigger the post or page is, the longer processing time is. So you have to get used to a progress indicator, that you’ll see every time writing posts / page or doing some similar operations on it. But… it isn’t that much annoying after few times! :]

underConstruction

Website: underConstruction.
Reason: The “under construction” / “coming soon” functionality.

As I mentioned (did I?) there are many plugins that provides “coming soon” or “under construction” functionality. There are also many themes that do the same, but in this case, they “lock” everything (lock = theme itself displays nothing except “coming soon” notice), including login form, which was not an option for me. I wanted a solution that will keep unregistered viewers away, until blog isn’t finished, but will let me or other editors to login, to continue blog development.

If there are many plugins, then why did I choose underConstruction? For a few reasons. First of all, instead of bloating me with hundred of fields and options to build up my own customized look of “coming soon” page, it simply allowed me to enter whole HTML, along with inlined styles. That was a good option, as default text that comes from this plugin is just awful! :] But there were other reasons.

Other reasons? It is only one known to me plugin that:

  • can be forced to allow logins of users with only certain access level (for example: Editors and above),
  • instead of displaying “comming soon” page, can do HTTP 300 Redirect or throw HTTP 503 Service unavailable error,
  • has IP Address whitelist, where you can define IP addresses that will always bypass through “coming soon” page,
  • can be enabled separately, does not force you to enable or disable entire WordPress network at once.

All other plugins, that I tested, turn-off frontend (redirects to login page) once activated, so can’t be network activated for all sites (which is quite handy).

underConstruction does not display (or redirect to) WordPress login page. Instead, it shows you “coming soon” page, where you can manually put a link to wp-login.php script to login yourself to “blocked” page.

Conlusion

With the exception of polylang plugin (I drooped that idea) everything went fine. I ended up with fine working WordPress network, which sites were accessible via top-level domains and with abillity to write posts pages and others using Markdown syntax.

Plus ability of disabling certain network’s pages with “coming soon” notice displayed for unregistered users.

Leave a Reply