By including a content type that is optimized for this module, new users can easily get up and running in moments by simply enabling a featurized content type and view. Developers can leverage the devel module to generate timeline content.

I included a "Media Link", which is just a URL and is not currently supported by this module, in addition to a "Media Image", as the current implementation supports only an Image field (ಠ_ಠ). I did not include tags.

CommentFileSizeAuthor
#1 views_timelinejs-feature-1855528-1.patch21.5 KBfluxsauce

Comments

fluxsauce’s picture

fluxsauce commented
Status: Active » Needs review
Issue tags: +Usability, +views, +Documentation, +features
StatusFileSize
new views_timelinejs-feature-1855528-1.patch21.5 KB

I had to fix #1855560: Define options for view plugin which will allow view to be exported before I was able to export the feature.

In order for this to work out of the box on a fresh site install:

projects[views_timelinejs][subdir] = contrib
projects[views_timelinejs][download][type] = git
projects[views_timelinejs][download][url] = http://git.drupal.org/project/views_timelinejs.git
projects[views_timelinejs][download][revision] = d64de3e6656833fa9c7e6de18629646e517c3e07
projects[views_timelinejs][patch][] = http://drupal.org/files/views_timelinejs-notag-1855350-1.patch
projects[views_timelinejs][patch][] = http://drupal.org/files/views_timelinejs-nouri-1855440-1.patch
projects[views_timelinejs][patch][] = http://drupal.org/files/views_timelinejs-noimagenourl-1855526-1.patch
projects[views_timelinejs][patch][] = http://drupal.org/files/views_timelinejs-optiondefs-1855560-1.patch
projects[views_timelinejs][patch][] = http://drupal.org/files/views_timelinejs-feature-1855528-1.patch
drush -y si
drush -y en devel_generate
drush generate-content 50 0 --types=timeline_date

This will create a page at /timeline , but will not create a menu item.

operinko’s picture

operinko commented
Status: Needs review » Fixed

The feature that FluxSauce supplied seems to do the trick more than fine.
I don't see a reason to provide a hard-coded content type in the module, but packaging a feature submodule seems like a sensible idea.

fluxsauce’s picture

fluxsauce commented

I don't see a reason to provide a hard-coded content type in the module

Well, to be honest, that's what I would prefer; that way, if there are any customizations, users don't end up with conflicting features. This is "good enough" for now in my opinion; I'll revisit a formal content type later. Thanks!

operinko’s picture

operinko commented

Well, my main reasoning is that this is supposed to be an abstract addon to views that can be used by practically any content type.
Packaging a new content type with this would just serve to generate overhead.

If someone wants to use the currently packaged feature, they can enable it to create the content type.
If they, at some point, want to customize and override the feature, they can disable that feature and export their own configuration anyway.

If you have some ideas on why a forced content type would be better, by all means let me know :)

fluxsauce’s picture

fluxsauce commented

just serve to generate overhead.

I disagree; by providing an optional content type as a submodule, much like the feature, a site admin or developer can chose to use the guaranteed working content type that's configured out of the box.

Software development isn't just making it work, it's also about usability and making a compelling, easy-to-use product that others can easily use. Steve Krug - "Don't Make Me Think".

If they, at some point, want to customize and override the feature, they can disable that feature and export their own configuration anyway.

Unfortunately, it's not that simple. To demonstrate, I'll use http://drupal.org/files/1855590_make.txt because it has all the dependencies.

drush make 1855590.make sandbox --prepare-install --yes --no-gitinfofile --no-patch-txt --working-copy
cd sandbox
drush -y si --account-pass=admin --db-url=mysql://root:root@127.0.0.1:9306/sandbox
# Enable Timeline JS feature.
drush -y en views_ui views_timelinejs_feature
# Change content type.
drush -y field-delete field_timeline_media_image
# Disable feature
drush -y dis views_timelinejs_feature

Notice that I disabled the existing feature; if I didn't, I wouldn't be able to add the content type to a new feature.

  • Login (admin:admin).
  • /admin/structure/features
  • Click on Views. State is disabled.
  • /admin/structure/features/create
  • Name: Custom Timeline Feature
  • Package: Views
  • Version: 7.x-1.0
  • Edit components: Content types: node - Timeline Date
  • Download feature
  • Extract, place in sites/all/modules
  • drush -y en custom_timeline_feature
  • /admin/structure/features
  • Click on Views. Custom Timeline Feature is now in Default state, but Views TimelineJS Feature is in state Conflict. If you look at the list of views, the Timeline view is no longer there. You can manually re-enable the Views TimelineJS Feature:
  • drush -y en views_timelinejs_feature
  • /admin/structure/features
  • Click on Views. Now both features are listed as conflicting and Views TimelineJS Feature is Overridden.

This "works", but it's sloppy and it's not best practice. By creating a true content type in an optional submodule, it can be featurized without conflicts.

operinko’s picture

operinko commented

Ah, good points :)
I'll add that to my TODO list.

Basically, it should be an optional sub-module that provides a content type with the basic fields.
I'm just wondering if I should put a Link field to it or not, since it's not a dependency on the main module.

For some reason it would seem a bit harsh to add extra dependencies on the sub-module (that is, it should have the bare minimum amount of fields to make it work, right?)

operinko’s picture

operinko commented
Status: Fixed » Needs work
fluxsauce’s picture

fluxsauce commented

I'm just wondering if I should put a Link field to it or not, since it's not a dependency on the main module.

I would say it's not a problem. Dependencies are pretty normal, it prevents duplication of effort. Additionally, http://drupal.org/project/link has 182202 has sites currently report using this module, it's pretty ubiquitous.

Actually, I can do both the content type and the view without a feature, which will (ironically?) remove the dependency on features.

juhaniemi’s picture

juhaniemi commented

IMO there are very few reasons to provide any hard coded content type in Drupal 7 era and up. Drupal is elastic and flexible, content types are fieldable, even content created by this module shouldn't be removed if this module is uninstalled and replaced by a similar module. That's why I would absolutely vote for feature submodule if we want to provide a simpler way to start kicking with this module. Or are we talking about the same thing?

fluxsauce’s picture

fluxsauce commented
Status: Needs work » Fixed

IMO there are very few reasons to provide any hard coded content type in Drupal 7 era and up.

I outlined the problem with using features in http://drupal.org/node/1855528#comment-6837450 - it works great until you try to adapt it.

If you provide a content type in code, it can be featurized without conflict, and content wouldn't be removed (that would have to be explicitly implemented in hook_uninstall) upon removal.

Another advantage of hard coded entities is speed and flexibility, which I will freely admit is not needed in this instance.

As it stands, the feature I wrote is now committed and works. The discussion was whether featurizing was optimal, or just "good enough." I feel it's "good enough" and I can live with it, as you feel it's optimal over a content type.

Automatically closed -- issue fixed for 2 weeks with no activity.