Refactor Quotes for Drupal 7 and forward

I'm not sure when this module began, but I'd guess that Taxonomy existed then. I'm not sure why the original author didn't think of using that. I admit that it never occurred to me. Right now, that seems a good idea. The term description could be used for the Biography field. And you get autocomplete and author lists for free.

I have had the idea of recreating this module as a Feature for some time. That makes including default Views easier.

I believe quotes started at or around D4.7, can't remember for sure but it was definitely before 5.0. Taxonomy existed back then and I tried using it for authors but the complexity was unreal and difficult to do.

There are several things that could be simplified. a default view is one of those that could eliminate a lot of redundant code. Using the entity system is another, however, like googletorp pointed out upgrading would be difficult. This is the main reason when working on 7.x version of quotes I kept the file structure as in 6.x.

Another thing which needs to be done is the automated testing now required for 7.x and beyond. Also since the node module in 8.x will be an option for core I believe that if quotes is to survive the major refactor has to occur in 7.x and probably before creating a release candidate.

I may still take a shot at it whenever I have some spare time.

@NancyDru: "I may still take a shot at it whenever I have some spare time."

Let's put together some thoughts about refactoring the code.

• Probably creating a default view could come first and with it we could either create a template tpl or just use cores'.
• Taxonomy terms for the module definitely needs worked on
• Automated testing.
• I'm sure the users of the quotes module would love a UI instead of relying on hard-coded defaults for the layout though most would probably still use the default values.
• I'd love to get this converted to use fields. That though might take some time getting the upgrade scripts to work.

We could also use this issue for incorporation of feature request and turn this into a Meta Issue. And of-course, as always, patches or help is appreciated. I've kinda left 6.x to NancyDru and worked on 7.x, many a time I've though it might be easier starting from scratch.

I have played a bit with tests, but no one would consider me good at it.

Going to a Feature would almost require starting over. The module should get much smaller. I've never liked the bulk import, so I see that as the bigger challenge. That was much easier in D5, but progress is progress.

+1, would be very interesting with a rewrite that could build on what we get "for free" out of most of the other framework building blocks these days (entities, views, taxonomy, UI, etc.)

Without considering the current code/version, but just the concept of "quotes",
which elements are crucial to this functionality and needs to be coded in this module?

Can we make use of the Features/strongarm framework and make a solution that merely helps people establish a "quotes structure" that can be handled by views, Fields-in-core and Entity APi, and then easily moved or re-created on other sites?

Can this module be reduced (positive meaning...) to:
a) establish a quotes structure based on D7 core fields API, taxonomy, views.
b) provide assistance with exporting through Features/Strongarm so quotes (and through views: selected portions/sections/categories) of quotes) can be moved/copied to other sites?

Can this module be made in such a way that it actually can be disabled after it has established the Quotes content structure, to leave the content to be handled by default Drupal modules after installation?

I think this might be possible (and desireable, from a maintenance point of view).

Look at the list of main elements:
- taxonomy (authors) / taxonomy term reference field (quote -> author) (D7 core/Field API + Relation module)
- views + block display (almost all Drupal sites will be using Views)
- (optionally?) custom entity as alternative to normal node (D7 core + Entity API)(perhaps something this module can be extended into on the next version onwards, starting out as normal nodes?)

I do not "see"/understand why a rewrite would need to "make upgrading a lot harder", as mentioned above, if the module was based on the built-in structure of core fields API.

Taxoman, I don't disagree with much of what you say. Indeed I started down that road some time ago. I am not yet fully convinced that taxonomy for authors is the best answer, but it is an idea worth pursuing.

Are you offering to do the rewrite?

If I'm starting from scratch, I might just use the biblio module. Define a Publication type, and a custom view and it seems you're good to go. Just trying to figure out the easiest way to get my current quotes migrated over!

I'm attching a patch to migrate the quotes module to Drupal core modules. Tested with a clean Drupal 7 installation and some dummy test content.

What it will do:

• Migrate nodes to use Drupal core modules.
• Authors and citations are converted to use the taxonomy module.
• Create a new content type to decouple from the quotes module.
• Migrate by the normal update method.
• After upgrading the quotes module can be completely uninstalled and the converted content is not deleted.

What it will not do:

• Migrate any other data except for the title, body, author and citation.
• It assumes that the content type being created does not exist.
• Same with the fields and vocabularies.
• Probably a lot more stuff that I forgot.

Note that I will probably not provide support for this patch. I created it for my own needs but I'm posting it here anyway, should anybody want to build upon it. I will be using it on my own sites soon and then reply here with a follow up.

I've looked over your patch. One question, would it not be better to set the citations up as a field body rather than a taxonomy term. I've yet to try the patch but yes it makes sense to convert this module from a separate entity to use D7 core and retire it.

Quite late of me, but I have improved the patch (and actually got it to migrate the author and citation this time). The citation field is now a regular text field, but the author is still a taxonomy term.

I recently migrated a site with ~1500 quotes using this patch without any problems. It took some minutes but I didn't bother using the Batch API. It behaves the same as the previous patch, including keeping the quotes when uninstalling the module.

Allow me to ask a "stupid" question, it is late here and the brain is not ready to think very hard...:

Given the architecture of D7 with fields, etc. and how much we get out of the box from taxonomy++;
- how far off is this module in terms of possibly being a "feature" with specified configurations of fields rather than a "module" with code functionality?

Or, asked differently:
- what do we get from this module's functionality that we cannot configure and export as a feature ourselves using custom content type and custom fields? Is this module almost redundant in D7?

@JimmyAx,

Tried the patches, both time out at 120 sec (php settings). what version of php are you using along with drupal version?

@leeteq "Or, asked differently:
- what do we get from this module's functionality that we cannot configure and export as a feature ourselves using custom content type and custom fields? Is this module almost redundant in D7?"

Not much presently. It would take the views module for some block settings to work. Looking forward to Drupal 8 this module should be just a configuration Implementation ( feature?).

@ctmattice1
I don't know how large your dataset is, but the patches probably time out as it's simply too large to be processed within the PHP limit. On my sites I have it set to a fairly high value so I don't have that problem. Ideally the patch should use the Batch API to convert the nodes. (Drupal 7.31, PHP 5.4.4, Debian)

@JimmyAx,

Added batch functionality to your patch, however, using php 5.3.3 it throws errors with empty properties. Working on one that will work for 5.3 and up. Plans are to setup the update where the user then has the choice, after the update, to continue to use the standard quotes module with its current structure or to use the updated content type and then do their own thing strictly using drupal core functionality and bypassing the quotes module.

Doing it this way gives further time to define what we want to do with the quotes module.

After getting a working version of an update that places everything under cores control and at the same time keeping the quotes module working decided to go two different routes.

The first will be this diff which batch processes jimmyAx's patch changing the node_type settings to quote. This is for users of the quotes module that wish to use core's functionality. Doing so will also require the views module for displaying any quotes blocks such as a block for random quotes.

Users who patch install with this file, run update.php may then delete the quotes module as all existing quotes will no longer be under its control. Or they may keep it installed and it will function as before with the cavet that it will not be able to access any data entered prior to running update.php and that any data entered through the module will have the same data structure as before.

This is why I will not commit this patch presently to git but instead am working on one that changes the structure similar to jimmyAx's patch but retains the quotes modules original node_type. I an planning to include a new block structure using views for those who have views installed and since drupal 8 already has views built into it.

It will probably be done in stages to insure a smooth transition and when completed this module will mainly function as a feature configuration with limited or no functionality other than the initial display setup.

Any thoughts are wlecome

This issue seems to evolve around migrating existing quotes (upgrade) to Drupal7 core fields system.
Is the title misleading, or will this module still be useful after the migration?

If not, if the point is to move on forward without this module, just using Drupal core features and views, then we should re-title this issue and state that clearly in the issue summary.

And; furthermore, then how about outlining the recommende data structure in the summary, for new folks so they dont waste time watching this issue progress if they could best do it themselves in Drupal with just an easy recipe?

Changing tag.