Move some sub-modules into separate projects

Problem/Motivation
First of all, I am really sorry for the inconvenience.
This is a tough decision that has been bothering me for quite a while. I intended to postpone it till Slick 3.x, but the underlying problem is not making it any better.

This not only happens to Slick, but also Media, Scald, Masonry, etc. So nothing new.
Some take years to decide, some quicker.

However I'll do my best to make the transition as smooth and easy as possible. So hopefully nobody gets hurt with this.

The main reasons behind this decision are:

• Having slick_views inside Slick 2.x makes the move to Slick 3.x a bit harder, as Slick 3.x will not have it.
• And renaming it as a separate project to views_slick is not a better option.
• Also having one in the package and the other separated with the same name is not good option either as it will add another extra maintenance which is already inevitable with slick_fields by now.

Hopefully having slick_views outside the slick 2.x also allows it to get matured properly. So it is not only about being slimmer.

Final structures
What about slick_fields, et al?
slick_fields and slick_ui are kept within Slick 2.x till full release.
slick_devel and slick_example are moving to separate projects when time allows, hopefully prior to another proper/beta release. The last two can also stick to the package if it is too much for separate projects. I would appreciate second opinions.

2.x will have slick_fields and slick_ui.
3.x will have slick_ui.
3.x will see, and break apart slick_fields into 3 separate projects, only when it is out and time allows:

• slick_image
• slick_media
• slick_field_collection

Why not slick_fields is also removed? I have no abundant energy to break it apart now, nor in the immediate future. The above is the best that time allows since 3.x is non-existent yet now.

If anything I am not aware of, or any better idea, or you have a strong opposition, please let me know.

Proposed resolution
Move the following into separate projects:

• slick_views, a placeholder is created
• slick_devel
• slick_example

Remaining tasks
Delete old 3 sub-modules from slick 2.x package.
Create separate projects named as three above accordingly.

Priority tasks

1. slick_views
   • Delete slick_views from slick 2.x package.
   • Create a separate project named slick_views.
   • To avoid WSOD at front end, be sure to run update.php which clears the registry, and or clear cache completely.
2. slick_example
3. slick_devel

Below are the breakdown of the slick_views moving. The rest of sub-modules should be less trickier.

Possible data loss
None. It is all about restructuring/ moving around modules properly.

Possible problem
Slick views blocks are temporarily gone, maybe WSOD at that particular page.
Visiting Slick Views UI should be WSOD, so refrain.
Please see Solutions below for smooth transition.

How hard is the possible problem
Hitting "Clear all caches" button, or drush cc all accordingly, should clear the issue.
Also added a hook_update() for beta2 users to clear registry to ensure no WSOD after updates via UI.

Solutions

1. Prior to updating and placing the new slick_views outside slick, be sure to open cache clearing admin page:
   - admin/config/development/performance
2. Start extracting the new slick, and place the new slick_views module outside slick directory.
   Deleting entire old slick directory and placing new is recommended.
   However if the update is replacing old directory, be sure to delete old slick_views as the new one outside.
3. Hit "Clear all caches" button. It should be safe now. A hook_update() is also provided for beta2 users when doing updates via Drupal UI.

Slick views should be back.

API changes
None

Profit
Not only modular and slimmer, but also separated projects away.

Non-Profit Disadvantages
It is no longer a one click download.

Recommendation
If just start building slicks with slick_views, it is recommended to use the separate project slick_views outside the package anytime, and drop the one inside it. This may help transition better to beta2, or later.