The 4.x version is in a good state in my opinion to be released as alpha. But there is one thing that is absolutely missing. Its the upgrade path from 6.x to 7.x. I this a blocker for a alpha release or can we do a alpha release and start work on the upgrade path?

If we want a upgrade path. What should absolutely be in there?

- Settings?
- Auto add to content types?
- Block position?

Comments

gnuget’s picture

IMO i think to is better release a alpha version and start to discuss about what is he best path for upgrade.

I think to in this way the module will get more attention and feedback from the users and could be more easy determine which things should be migrated.

matglas86’s picture

Thanks gnuget. I think you are right. I shall ask the project maintainer to release a alpha version.

matglas86’s picture

Hi gnuget the fellows at mearra release the alpha1 version. Lets see what happens.

I also add a reference here to #1478926: Undefined permission 'view addthis' in 4.x version that show something that needs a upgrade path.

gnuget’s picture

Awesome!

I'm really interested on see a stable version of this branch, and will help as much as possible for make it real

I can start to look a way to migrate from a old version, but i have a doubts.

From which version this will be updated? from 7.x-2.1-beta1 to 7.x-4.0-alpha1 ? right now exists a way to migrate from 6.x-3-beta2 to 7.x-2.1-beta1 ? would be a way to migrate from a 6.x version to 7.x-4 version directly?

matglas86’s picture

I would focus on a upgrade path from 6.x-3.0 to 7.x-4.0. There has not been a official upgrade path from 6 to 7.x-2.1-beta1. So it would be a waste to do a upgrade path from there.

Thanks for helping on this. Patches are more than welcome.

gnuget’s picture

I did a quick review into the version 6.x-3.0 seems almost all the options appear into the 7.x-4.0 version, and could be ported without problem.

The problem to i think we need discuss is related with the buttons at the content types, since the new version create a field for displayed the buttons the old version add it automatically without needs to create a field (just was necessary setting up into the settings page).

The most obvios way to migrate this i think is to check for which content types has the addthis buttons and automatically create a field for each content type, but since doing this make difficult uninstall the plugin (#1307084: Document > Uninstalling the module) i don't sure if this will be too intrusive for the users or if would be a good idea. what do you think?

Also, related with the block position i don't think to would be a good idea try to migrate the block position, because the themes in drupal aren't compatible between versions so the most probably is to when a user migrate from D6 to D7 will be in a new theme or maybe a adapted version of his theme but still a different theme with a high probability to have a new regions, or maybe rename the old ones.

So, i will start to check how migrate the settings while we decide what to do with the content types and the blocks.

matglas86’s picture

Did the previous module have different configurations for widgets? If so we need to figure out what the new configuration will be and set that. One obstacle that I already found in other scenarios is that we don't have a global 'preset' with configuration for all content types. This is a different topic but the 6 version uses the same style everywhere right?

gnuget’s picture

Yes, the D6 version use the same configuration everywhere, so just we need take care for migrate the same configuration and apply it into the all content types

The D6 version has almost the same options for the widgets (toolbox or button, which services will display, header background, header color, open on hover etc).

I'm attach a screenshot with the configuration for D6, if you compare it with the D7 version is almost the same.

matglas86’s picture

Issue summary: View changes

@gnuget we are moving to a beta version at the moment. Can we create a list of elements that need migration? Are you willing to help here? The migrations might be seperate tickets with novice on it and as related in this tickets.

matglas86’s picture

I have changed my view on this a bit. We are near drupal 8 now and not many projects will be migrating from 6 to 7 anymore. Would it be better to close this issue?

gnuget’s picture

Yeah, I agree about to close this issue

matglas86’s picture

Status: Active » Closed (won't fix)