Create an upgrade path from Facebook-style Statuses (D6)

Here is an initial (untested) patch. Still to do: update Flags, Rules, Mollom, Pathauto, Userpoints, and maybe Services and Views database records that reference "facebook_status" instead of "statuses."

(By the way, I decided it was too much trouble to rename the submodules, especially since their names in code are not user-facing. It will happen one day, but not today.)

Here is an overview of the status of integrations with all modules that FBSS supported.

Expected to be Working, No Remaining Upgrades Needed

User Relationships
Flag Friend
Input filters (core)
SMS Framework
Domain Access
Shorten URLs
Timeago
ImageCache Profile

I have reason to believe that all of these integrations are fully working. Upgrading from D6 to D7 does not require manual steps from the site administrator to upgrade these integrations; additionally, either no automatic upgrade steps are required or these steps are already included in the patch in #1.

Expected to be Working, Manual Upgrade Steps Required

Rules
Views
Pathauto

People will have to recreate any custom Rules and Views or modifications to the default Views as part of the D6 -> D7 transition. There's really not much we can do about this. We only provide one default Rule which is useless and disabled by default, and I recommend that we remove it.

All Pathauto users will need to completely reconfigure their Pathauto settings after upgrading from D6 to D7 because of the changes to Token in D7.

Expected to be Working, Manual Theming Changes May Be Required

User profile (core)
Author Pane
Statuses (itself)

Statuses provides variables to the user profile and author pane theming templates. The names of these variables have changed. Similarly, the names of variables for the statuses-item.tpl.php template have changed, and CSS classes and IDs are different, so CSS and template changes may be required.

No Longer Supported

Activity (#1415020: Activity integration is broken)
Notifications (most likely - #1255280: Document alternative to Notifications integration)
Modal Frame (no D7 version - #1591586: Remove Modalframe integration)
Mentions (no D7 version)

There is no explicit Mentions integration in Statuses.

Partially or Mostly Working, No Remaining Automatic Upgrade Tasks

Devel Generate (#1481764: Devel Integration with Stauses and fbss_comemnts)
Twitter / OAuth (#1469142: share status Twitter error)
Taxonomy (core - #1350292: Tags view doesn't adopt correct vocabulary)
Services

Working, Automatic Upgrade Tasks Remaining

Flag

The "content_type" column in the {flags}, {flag_content}, and {flag_counts} table needs to be updated for the facebook_status -> statuses transition.

Partially Working, Automatic Upgrade Tasks Remaining

Mollom
Userpoints

Mollom correctly judges whether a post is ham or spam, but it does not correctly display a CAPTCHA if it is unsure. Furthermore no entries appear in the {mollom} table for statuses.
In the {mollom} table, the "entity" and "form_id" columns need to be updated for the facebook_status -> statuses transition.
In the {mollom_form} table, the "form_id" column needs to be updated for the facebook_status -> statuses transition.

Even though hook_userpoints() appears to be deprecated (although the nodes and comments integration module is using it) and even though hook_userpoints_info() hasn't been implemented, it appears that Userpoints is more or less working. However even if no changes are required to the integration itself, we need to update the "operation" column of the {userpoints_txn} table during the upgrade process.

Not Working

Quant

The Quant module integrates with Statuses (instead of the other way around) and it hasn't been upgraded to take the name change into account.

Unknown

Context
Views Bulk Operations
Ctools
Heartbeat
Trigger (#1565402: Leftover D6 Trigger integration causes incompatibility with Commerce module)

It might be dangerous to use Context integration; the only place it's used is to change where contexts apply, and done incorrectly this could cause WSODs or other unexpected results. Most likely no one uses it right now, so I would not mind removing it.

Statuses has explicit integration with Views Bulk Operations from D6, but I think that is no longer necessary in D7 and should be removed. Most likely VBO already works with Statuses since it depends primarily on Rules and Views.

Statuses provides a Ctools content type as a convenience for Author Pane. I don't know if it is working, but I think Author Pane doesn't use it in D7 anyway, and it's redundant with the Statuses block. It's also a common source of questions, so we should remove it.

The only direct support that Statuses provides for Heartbeat is 3 lines of JavaScript. As I understand it, Heartbeat takes care of the rest. I have not tried mixing Heartbeat with Statuses, but from what I understand, it should work.

Trigger integration existed mainly to support Activity integration, and it is removed from D8, so we should go ahead and remove it.

In summary, these are the tasks extracted from the previous comment that don't already have issues associated with them:

Services integration has problems
Mollom integration has problems
Userpoints integration probably needs some improvements
Integration with Context, VBO, Ctools, and Trigger should be removed
The one default Rule we provide should be removed
VBO integration needs to be tested

Additionally, we should post a patch for the D7 branch of Quant to fix its integration with Statuses.

Finally, in this issue, we need to add upgrades for the Flag, Userpoints, and Mollom modules to the patch in #1.

This patch includes upgrades for Flag, Userpoints, and Mollom.

Remaining tasks in this issue include opening issues for the problems discussed in #3 and testing that the attached patch actually works.

Great. Obviously the hard part of testing this is setting up D6 with all the integrated modules and then once you start the port if something breaks it's hard to just roll back...

I'm really busy this week so if it takes me awhile to respond that's why.

facebook_status table was not renamed to statuses. Both facebook_status and statuses tables are present. While upgrading we will remove the facebook_status folder and add the statuses folder, I think we are missing something here(or Am I missing anything.)

The usual upgrade process is:

• Disable all contrib modules and switch to a default theme like Garland.
• Upgrade core.
• Enable the D7 version of contrib modules and run update.php.
• Remove any unused D6 contrib modules.

I think that most likely Drupal doesn't think it needs to run the new upgrade function for Statuses since as far as it is concerned it is a new module. (Same for Statuses Tags, but the other submodules have the same names, so they should be fine.) We might be able to resolve this simply by renaming the upgrade function to facebook_status_update_7100(). If not, the upgrade process will need to happen during installation.

first enable the statuses module then enable the submodules one by one, please do not enable all the modules in one shot.

Other than possible memory limit issues I don't think this should be a problem.

However we will be hit by another problem, i.e. here we are installing the statuses module not re-enabling, so statuses installation will create the statuses table and facebook_status_update_7100() will try to rename the facebook_status table to statuses.

Copying the data could take an unacceptably long time for sites that have millions of statuses. We should consider manually creating the statuses table if needed in the install function. The hook_schema() implementation would have to be renamed, and then the hook_install() implementation would look something like this (pseudocode):

function statuses_install() {
  if (db_table_exists('facebook_status')) {
    // Upgrade process
  }
  else {
    // Some variant of drupal_install_schema()
  }
}

Since the schema is created before the install hook runs, another alternative would be to simply delete the {statuses} table before running the upgrade process if the {facebook_status} table exists. That might be easier although kind of wasteful.

But the problem with this method is how can we make this process synchronous? i.e. running the update script after the complete installation of statuses and other submodules.

Most likely the upgrade process will need to be called from statuses_install() instead of automatically invoked.

Nope. we will have problem with installation of fbss_privacy submodule. Cause privacy module will try to alter the schema of statuses table, so first we need to install the statuses and then the sub modules one by one.

Yes, but it looks like Drupal enables dependencies before dependent modules, so Statuses should always be installed before Statuses Privacy.

Finally we need to do another process, deleting the entry for facebook_status and facebook_status_tags module in system table once the upgradation is done.

This is not strictly necessary, but might as well I suppose.

Looks good to me, just a few minor things:

+++ b/statuses.install
@@ -10,7 +10,23 @@
+  // Upgrade the facebook_status to statuses if its available

it's :-)

+++ b/statuses.install
@@ -10,7 +10,23 @@
+  if (db_table_exists('facebook_status')) {
+    facebook_status_upgrade();
+  }

This is clever; I like it (though I would prefer the function be named _facebook_status_upgrade()). My one concern is whether Drupal will know to drop the schema when Statuses is uninstalled as it may still associate it with FBSS. Not sure what to do about it if so, just one more thing we need to test.

+++ b/statuses.install
@@ -10,7 +10,23 @@
+    $schema['statuses'] = _statuses_statuses_schema();
+    $schema['statuses_contexts'] = _statuses_contexts_schema();

This can probably be just one function, _statuses_schema()

I've been really busy too...

Maybe there is a way to tell Drupal that a schema is actually associated with the new module, by changing it directly?

Thinking about this again, I think it would be okay to just copy the data. It's a simple solution and it really shouldn't take more than 30 seconds even with millions of records on a low-resource machine. The database API doesn't have a way to do that with prepared statements but I believe all the databases Drupal supports have INSERT INTO {table} SELECT syntax so it shouldn't be a big deal. At least it will work for the vast majority of sites and save us the headache of doing special schema stuff. I believe this is the route other modules have taken although looking quickly I can't find a good example.

Reroll of #6 with suggestion from #17. Basically we move the content from the FBSS tables to Statuses tables and then drop the FBSS schema. Not yet tested although for obvious reasons I'd like to commit this as soon as we can.

Also, I addressed the issues brought up in #3:

Drop default rules
Drop Context module integration
Drop CTools integration
Drop VBO integration
Drop Trigger integration
#1263268: Mollom / captcha not visible after wrong input when using AJAX
#1663504: Services integration is broken
#1685442: Userpoints integration uses deprecated API

Thanks for testing.

Had a look at the patch in #18 and having the migration does not fire off when placed into a hook_update. However, placing it into another function and calling via hook_install seems to do the trick.

Hmm. Not sure why that would be, but I guess doing it that way is okay. However the patch you provided doesn't include most of the necessary stuff from #18. I will make an effort to reroll this weekend.

The submodules readme states that it isn't necessary to rename all of the submodules to the statuses naming convention - however when you have both facebook_status and statuses in your modules folder, only the fbss modules are recognized in the module list. This could potentially be quite confusing to end users, as the submodules (other than tag) won't show up until the facebook_status folder is removed. Thoughts?

I actually have no problem with this as long as the release notes say that you have to delete the old FBSS folder after upgrading. Normally you would need to do that to upgrade a module anyway.

The patch in #22 still leaves out a lot from #18. The attached patch is #18 with the fix (more or less) from #20. Also attached is an interdiff between this patch and #18 so we can see what changed.

I'm fairly confident in this one. If it looks like this works let's get it committed and push out a beta!

Whoops, here's a version with some extra comments about why we are using hook_install() and not just a normal hook_update_N().

Whoops.

Updated patch attached.

+++ b/submodules/statuses_tags/statuses_tags.install
@@ -113,3 +122,47 @@ function statuses_tags_uninstall() {
+      db_update('taxonomy_vocabulary')
+        ->fields(array(
+          'description' => t('Contains #hashtags used in Statuses.'),
+          'module' => 'statuses_tags',
+        ))
+        ->condition('module', 'facebook_status_tags')
+        ->condition('vid', variable_get('facebook_status_tags_vid', -1))
+        ->execute();

I'm assuming the 'machine_name' field was removed from being updated here because that's what was causing the integrity constraint violation? That error would have been due to the unique key on the 'hashtag' column, indicating that there was already a vocabulary with that machine name (normally the one we just added in statuses_tags_install()). That actually exposed a bug: I called the upgrade path after creating the new vocabulary when the upgrade path should have run first. Fixed in the attached patch (along with interdiffs to #27 and #28).

Committed fix to dev!

I created #1708256: Write release notes for 7.x-1.0-beta1 and once that is finished up we can tag and publish the release. (@mathankumarc, would you like to do the honors?)

Still we need to consider deleting the entries for old schema in system table.

Doesn't affect anything; might as well leave it. If we messed something up in the upgrade path I just committed, those system table records would let us know if FBSS had ever been installed previously, which we may need to know in order to fix things.