Closed (won't fix)
Project:
AddThis
Version:
7.x-4.x-dev
Component:
Code
Priority:
Major
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
23 Jan 2012 at 22:45 UTC
Updated:
15 Jun 2015 at 20:19 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
gnugetIMO 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.
Comment #2
matglas86 commentedThanks gnuget. I think you are right. I shall ask the project maintainer to release a alpha version.
Comment #3
matglas86 commentedHi 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.
Comment #4
gnugetAwesome!
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?
Comment #5
matglas86 commentedI 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.
Comment #6
gnugetI 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.
Comment #7
matglas86 commentedDid 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?
Comment #8
gnugetYes, 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.
Comment #9
matglas86 commented@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.
Comment #10
matglas86 commentedI 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?
Comment #11
gnugetYeah, I agree about to close this issue
Comment #12
matglas86 commented