Upgrade path 2.x to 3.0

Also happening:
PHP Fatal error: Cannot redeclare linkit_entity_ctools_linkit_get_child()
We need a big red sign on the module page
Completely remove 2.x before going 3.x
or do it like others and leave empty files to overwrite the old ones.

While there isn't any upgrade path from Linkit 2.x to 3.x, will there ever be?

No upgrade path is planned.

But if someone makes a nice patch, I'll take a look at it.

I managed to create an update hook which works for me. am using linkit together with the link fields and ckeditor.

Upgrade path steps:

1. If you have linkit profiles exported in features you should resave them in order to put the settings in the database (all the profiles should be marked as overridden). Linkit profiles are made as a ctools plugin and they are loaded directly from the features and nothing is stored in the DB.
2. Remove the old linkit (v2) module.
3. Download linkit v3
4. Run update.php

Note that I had to delete my browser cache in order to refresh the ckeditor plugins.

it seems that the simple tests of the module are not up to date. But I don't see a problem related with my patch...

Thanks boyan. I look forward to testing this.

1. If you have linkit profiles exported in features you should resave them in order to put the settings in the database (all the profiles should be marked as overridden). Linkit profiles are made as a ctools plugin and they are loaded directly from the features and nothing is stored in the DB.
2. Remove the old linkit (v2) module.
3. Download linkit v3
4. Run update.php

Is the point of these steps to allow you to re-export the feature?

We use LinkIt (2.6) in the Panopoly distro and would like to upgrade it. What I'm trying to understand is whether or not we need to run these steps simply to update our exports in Panopoly or if the users of Panopoly need to do some of these as well.... like saving the profiles to the db before updating Panopoly?

Hi @caschbre,

You are right, that's the point of the steps. If linkit profiles are loaded from the features but not from the db my update hook will do nothing because it changes only the records in the db.
In you case with Panopoly distro you should follow the steps and afterwards you'll be free to update your features.

Ok, great! We're trying to make this upgrade seamless to the user. So we can make our feature fixes in the panopoly module(s) using the steps you outlined. And a user with panopoly installed already can just update the panopoly distro in the normal fashion and they'll be ok since the panopoly features will be updated.

This patch works great! We're going to start using it in Panopoly soon. However, here is a slightly modified version which simply calls registry_rebuild() at the end, so that the LinkitProfile class is immediately available. This affects Features, because it attempts to instantiate the LinkitProfile class, which will fail until the registry is rebuilt.

Since my addition was trivial, I think I can still safely RTBC this. :-)

The test failures really can't have anything to do with this patch, since it only adds a hook_update_N() function...

AWESOME!!! Thanks for all the work. @boyan.borisov and @dsnopek You guys rock!!!

I have commited the patch.

Edit: Sorry, boyan.borisov, just saw that I gave commit author to dsnopek instead of you (you did the largest amount of work). I don't know how to change that.
If you know how I can change that, and if you care, please tell me and I will correct it.

Thanks for committing!

Hrm. I don't think there is a way to change it without reverting the change, and then committing the patch again. So then there will be 3 commits in total in the history, including the one where you credited me and the revert commit. :-/ The Git repos on D.o don't allow you to pull revisions out of the history, which is normally a good thing, but makes these sort of situations difficult.

Cool! I'm really glad that I helped.

well, the only way that I know to change the author of a pushed commit is:
> git commit --amend --author="New Author Name "
> git push --force

Unfortunately this will rewrite the repo history but not sure if this is a problem in this case.
But it's up to you, @anon. The most important is that we have the upgrade path done :)

Yeah, unfortunately, I don't think Drupal.org will let you do a git push --force - at least it didn't the last time I tried (because I made the same mistake in miscrediting a patch ;-)). But if that's changed, I say go for it!

If this is committed maybe you should update the main page where it states that

Known problems
NO UPGRADE PATH FROM 2.x to 3.x

which is no longer true.
And a short description of the required update steps as stated in #5 could help some people too.

About the update fail.

See #2363681: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'weight' in 'order clause'