Login or Register to Ask a Question and Join Our Community

Sponsored Content
Full Discussion: Update on vB3 Migration to Discourse - Issues and Status of BBCode Transformations
The Lounge What is on Your Mind? Update on vB3 Migration to Discourse - Issues and Status of BBCode Transformations Post 303045818 by Neo on Tuesday 14th of April 2020 04:48:22 AM
Old 04-14-2020
Update:

This migration is moving along. @Scrutinizer has been a great help with debugging the bbcode migration, writing Ruby methods to preprocess various bbcode situations which arise in the conversion to markdown.

For examples:

There was some newlines being added to code blocks, so we added some post-processing REGEX search and replace to tidy these up. This was a purely cosmetic change but @Scrutinizer is more annoyed by these cosmetic details than me, and so he wrote some Ruby code to fix it. We are very fortunately to have @Scrutinizer working with me on this.

The same is true for some "bbcode abuse" where in the past over the years, some people copy-and-pasted some bbcode into the forum or others just loved bbcode so much the embedded bbcode everywhere, sometimes nesting bbcode is strange ways. We have also slayed most of those dragons.

We are getting very close. We cannot promise 100% of every possible combination of bbcode-mangles in the vB3 forum will be perfect, but it will be very good, a few orders of magnitude from the initial release, hands down.

Currently I am rebaking all the post again on the staging server. That is a process which takes 12 to 14 hours. For those who may not be familiar with this, here is a short summary:

The vB3 forum (indeed most, if not all, LAMP-based forums) process(es) the pagetext in the database on the fly (when the page is summoned by the client, e.g. the web browser).

However, Discourse stores the pagetext as "raw" and then it cooks the raw into HTML to be rendered. This of course makes the site faster since the code is already rendered and stored in the DB "cooked".

The downside to this, of course, is that it takes longer to "cook all this" during migration testing (reprocessing the raw for bbcode mangling); but lucky for us, after migration is done, it's done.

BTW, this is the same way I serve our forumman pages. Man pages are also cooked and the cooked pages are stored in the DB to make them render faster, so this technique is nothing new.

OBTW, those man pages will stay here in the legacy vB3 forums; until we decide if and/or when to write a plugin to port these to discourse.

That's it for now.
This User Gave Thanks to Neo For This Post:
vgersh99
 

6 More Discussions You Might Find Interesting

1. Shell Programming and Scripting

Shell Script migration issues

Hi All, We will be doing a Solaris 8 to Solaris 10 migration migration, just wanted to know if there are any known / common issues arise from this migration from Shell script point of view. I tried searching this site but mostly post are related to SA's question and jumpstart, etc. If there's... (4 Replies)
Discussion started by: arvindcgi
4 Replies

2. HP-UX

Migration - Compiler Issues.

All, We are migrating an application from HP-UX B.11.00 to HP-UX B.11.31 and both of them have the same informix version - 7.25se. However the compilers are different on both servers. HP-UX B.11.00 - has B3913DB C.03.33 HP aC++ Compiler (S800) HP-UX B.11.31 - has PHSS_40631 1.0 HP C/aC++... (2 Replies)
Discussion started by: helper
2 Replies

3. Programming

How to track table status delete/update/insert status in DB2 V10 z/os?

Dear Team I am using DB2 v10 z/os database . Need expert guidance to figure out best way to track table activities ( Ex Delete, Insert,Update ) Scenario We have a table which is critical and many developer/testing team access on daily basis . We had instance where some deleted... (1 Reply)
Discussion started by: Perlbaby
1 Replies

4. What is on Your Mind?

Status of Migration of Moderation Systems

First a bit of history .... A number of years ago one of our admins built a number of plugin systems for moderation, including (1) a voting system, (2) a "user feelings" system and (3) a confidential posting system. During this time, I was busy on other projects, not very active in the forums,... (1 Reply)
Discussion started by: Neo
1 Replies

5. What is on Your Mind?

VBulletin 3.8 to Discourse on Docker Migration Test Take Two

OK. Like we all do, we learn a lot from tests, test migrations, and so forth. Today, I started from scratch on test migration 2, armed with a lot more knowledge, The main differences are as follows: Installed discourse plugin ruby-bbcode-to-md before starting the install Modified... (30 Replies)
Discussion started by: Neo
30 Replies

6. What is on Your Mind?

VBulletin 3.8 to Discourse on Docker Migration Test Take Four

Test Build 4 on New Server, with changes identified in discourse test builds 2 and 3, primarily: Insuring ruby-bbcode-to-markdown is enabled. Removing line breaks from ICODE to markdown in migration script. Added vbpostid to posts in discourse to setup migrating vb "thanks" to discourse... (28 Replies)
Discussion started by: Neo
28 Replies

LEARN ABOUT DEBIAN

vzmigrate

vzmigrate(8)							    Containers							      vzmigrate(8)

NAME

       vzmigrate - migrate a container between two OpenVZ servers

SYNOPSIS

       vzmigrate [-r|--remove-area yes|no] [--ssh=ssh_options] [--rsync=rsync_options] [--keep-dst] [--online] [-v] destination_address CTID

DESCRIPTION

       This  utility  is  used	to  migrate  a container from one (source) Hardware Node (HN) to another (destination) HN. The utility can migrate
       either stopped or running container. For a stopped container, simple CT private area transfer is  performed  (rsync(1)  is  used  for  file
       transfer). For running containers, migration may be offline (default) or online.

       This  program uses ssh as a transport layer. You will need to put ssh public key to destination node and be able to connect to node without
       entering password.

OPTIONS

       -r, --remove-area yes | no
	      Whether to remove a container area on source HN for the successfully migrated container. Default is yes.

       --ssh=options
	      Additional options that will be passed to ssh while establishing connection to destination HN.

       --rsync=options
	      Additional options that will be passed to rsync(8).  You may add options like -z to enable data compression  if  you  are  migrating
	      over a slow link.

       --keep-dst
	      Do  not  clean  synced  destination container private area in case of some error. It makes sense to use this option on big container
	      migration to avoid syncing container private area again in case some error (on container	stop  for  example)  occurs  during  first
	      migration attempt.

       --online
	      Perform  online (zero-downtime) migration: during the migration the container hangs for a while and after the migration it continues
	      working as though nothing has happened.

       -v     Verbose mode. Causes vzmigrate to print debugging messages about its progress.  Multiple -v options  increase  the  verbosity.   The
	      maximum is 3.

EXAMPLES

       Migration of CT 101 to 192.168.1.130 with downtime:

	  vzmigrate 192.168.1.130 101

       Online migration of CT 102 to 192.168.1.130:

	  vzmigrate --online 192.168.1.130 102

EXIT STATUS

       0 EXIT_OK
	      Command completed successfully.

       1 EXIT_USAGE
	      Bad command line options.

       2 EXIT_VE_STOPPED
	      Container is stopped.

       4 EXIT_CONNECT
	      Can't connect to destination (source) HN.

       6 EXIT_COPY
	      Container private area copying/moving failed.

       7 EXIT_VE_START
	      Can't start or restore destination CT.

       8 EXIT_VE_STOP
	      Can't stop or checkpoint source CT.

       9 EXIT_EXISTS
	      Container already exists on destination HN.

       10 EXIT_NOTEXIST
	      Container does not exists on source HN.

       12 EXIT_IP_INUSE
	      You attempt to migrate CT which IP address(es) are already in use on the destination node.

       13 EXIT_QUOTA
	      Operation with CT quota failed.

SEE ALSO

       rsync(1).

COPYRIGHT

       Copyright (C) 2001-2010, Parallels, Inc. Licensed under GNU GPL.

OpenVZ								    28 Jun 2011 						      vzmigrate(8)
All times are GMT -4. The time now is 12:53 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy