About this issue: This issue has evolved in a general thread for updates about a major rework of the chart module being considered. Specific bugs, feature requests, and support requests about the chart module should go elsewhere. Subscribe to this issue (using the follow button) for updates about this topic. Below is how this issue started ...

I recently researched various charting solutions available within Drupal. What an interesting choice of modules to pick from (after you find your way in this confusing stuff, even if it was only because of the names of the modules ... or the list of charting libraries to pick from).

I contributed the intermediate result of it via Comparison of charting modules, located in the community documentation. You'll notice that it's quite complete (I think) as it relates to module forena. That's because I recently became a co-maintainer of it. In an attempt to make the comparison more module independent, I recently changed the original location of it (within forena community documentation) to its current location, i.e. a location where all sorts of module comparisons are located.

While working on this comparison, I also discovered this "depreciated" Google Chart Tools: Image Charts" module (though still used in +25K sites, go figure!). As mentioned on its project page, existing users are recommended to migrate to the charts module. Both modules are included in my comparison mentioned above, but because of the apparent popularity (still) of the chart module, I'm planning to soon enhance its visibility in the comparison.

Based on my research, and based on various postings on D.O, I'm planning to start working (contributing) on a charting module for which my main objectives will be:

a) Provide site builder tools (like UI's) for using various charting libraries and/or existing modules, targeted to site builders who don't want to dive in PHP coding.
b) Act like an interface to enable the usage of charting library X on drupal charting module Y.
c) Attempt to reduce the required knowledge and/or effort to make the right choice between the various Drupal modules available for charting.
d) ... (incomplete list).

Not sure at this time to what extend I'll be able to realize these objectives, but at least I want to give it a try. Especially because of my background (and passion) in this area, and because it appears to me as a unique opportunity in Drupal-land that not many people have worked on, or at least not recently.

As a first step, I'm looking for an appropriate namespace of this project. Ideally a name that doesn't add even more to the confusion between all the modules available for charting. And because of the chart module being depreciated now, I'm wondering if the "chart" module could be an option for me to consider. If so I'm thinking of starting a 7.x-2.x version (to not get in the way of any existing 7.x-1.x/6.x-1.x users). If this makes sense, I wonder if I should ask for becoming a co-maintainer of it, or rather file a request to transfer the ownership of the module? Can anybody point me to the appropriate owner/maintainers of the chart module to forward my question?

thank you in advance!
Pierre

PS: any suggestions about who to contact for the charts module to help complete the above mentioned comparison?

Comments

boombatower’s picture

Status: Active » Fixed

Sounds like an excellent plan. Consolidating tends to make it easier to understand and "chart" is the ideal namespace. :) Added you as co-maintainer, we'll see how things go. If any of the other maintainers have a problem with this feel free to revoke and explain.

Also please stick to >=7.x-2.x branch.

Pierre.Vriens’s picture

Title: Chart 2.0 proposal » Chart 2.0
Issue summary: View changes

Thank you Jimmy for accepting my proposal. 7.x-2.x branch is an exact match with what I'm thinking of also. And "co-maintainer" is of course more then enough to try to get this going.

I'm hoping that other maintainers, contributors and/or existing D6/D7 chart users will join this Chart 2.0 party, and hopefully not everybody will assume what Dries explained in his DrupalCon 2014 keynote in Amsterdam as "George will do it" ...

With permission from the other maintainers, I'd like to work on getting the existing issues moving again (+25% 'open' issues, most of them over a year? That doesn't sound to me like a healthy project right now ...). That includes reconsidering some of the closed issues with status such as "won't fixed" or "works as designed", which is pretty sure the correct status in the context of the 6.x-1.x / 7.x-1.x versions. But I think they should at least be reconsidered (and maybe reopened?) in the context of the Chart 2.0 context. Using this approach will also help me to get a better understanding / insight in how the chart users are actually using the module, as well as what the open challenges (missing features?) of it are.

Regards,
Pierre.

Pierre.Vriens’s picture

After some days of crawling the chart issue queue, it has become clear to me that before starting a 7.x-2.x version (to not get in the way of any existing 7.x-1.x/6.x-1.x users) (as I wrote in the original issue here) it seems appropriate to first try to come up with a successor of at least the current 7.x-1.1 version of the chart module. That's the impression I got after discovering the various comments in the exiting chart queue, from quite a few users that seem to be begging for a new official release based on the current DEV version. This DEV version seems to already address quite a few bugs in the most recent official (7.x-1.1) version. On top of that there are quite a few contributions sitting in the issue queue (eg in the format of patches that were submitted), but apparently never committed to the DEV version. Checkout the child issues of #2371075: Chart 7.x-2.x Release for a first attempt to create an inventory of all such issues (but understand this is just a first attempt to come up with such an inventory, there may be missing ones, there may be issues I added in it which for some reason might have to be reconsidered and removed again). Same is true for the most recent official 6.x version, with a similar set of child issues now in #2371567: Chart 6.x-2.x Release.

I'd hope that creating such a new official release (at least for D7, and preferably also for D6) would create goodwill from the existing sites using the chart module (+25K sites still using a D6 or D7 version of it, the most popular charting module, remember!). That goodwill might help to have some of those +25K sites somehow contribute to the real challenge for the chart module: the april 2015 deadline that has come pretty close already. At this time I don't have a complete understanding of the impact for any sites that after this deadline will try to continue to use the current whatever-version of chart. But the current usage statistics of the chart module seems to proof that the existing warning at the top of the chart project page simply doesn't help to stop sites from finally doing something about it. Because of all this, I've also started to think about additional alternatives to be considered for those +25K sites still using the chart module. Because of that, I've identified 2 specific chart issues that could be a valid starting point to help existing chart users to address the imposed deadline:

Don't ask me how to do so, because right now I just don't know (yet ...), but the above issues seem to proof to me that at least there is a partial solution worth to be considered seriously ... I look forward for more feedback about all this, preferably in the format of solutions, but at least some kind of thumbs up (or down, I open for constructive critique).

Pierre.Vriens’s picture

Status: Fixed » Active

Because of my prior comment I'm reopening this issue ...

Pierre.Vriens’s picture

Another module currently depending on the chart module, refer to #2169159: Migrate from Chart module to Charts for details about how they are approaching the famous deadline ... #2366737: Port to Google Chart Tools is a variation of it ...

Pierre.Vriens’s picture

Plazik’s picture

What are the main differences from Charts module?
It already supports 3 chart providers (Google, Highcharts, RGraph) and precipitously grows up https://www.drupal.org/project/usage/charts.

Pierre.Vriens’s picture

@Plazik: the best I know about the differences you're asking about is included in the comparison (see link above). Thanks for mentioning the RGraph library ... yet another library that is worth including in it (where is George?). I don't know the word "precipitously", I'm not native English speaking (and would hope English speaking people try to avoid having people like me requiring a dictionary for basic Drupal communications ...). But yes charts is indeed "growing up". However, not that fast as chart over the past month or so (check the usage stats to understand what I mean).

And don't get me wrong: if I personally would have to make a decision about using charts versus chart, I'd go for the first one. But in the context of the current situation of the chart module (and the recommendation on its homepage to swap/migrate/whatever to chart), these are my questions for which I can't seem to find the answers:

  • What are the steps required to go from chart to charts, ie: how does "a" site anything related to chart replace by the charts equivalent (where is the docu to do so)?
  • What can be done urgently to somehow force current chart users to start doing something to address the imposed April 2015 deadline (different from making the module unavailable for download on D.O).
  • Are the existing 26K sites that today are using chart even aware of this April 2015 deadline?

Note that these questions are NOT related to my original "main objectives" about what I started to call Chart 2.0, but rather something like some kind of legacy issues I discovered related to the current chart module. I'd appreciate if anybody who is more familiar with the chart module then me, could help in addressing these legacy issues ASAP. If that doesn't happen really soon, I'm considering working on a new "recommended" chart release, via the branch I've been authorised for (as mentioned in #1). Such release will only be like a temporary work around for the current April 2015, so don't expect miracles in that release, only a plan b to consider from May 2015 on ... Once such release is available, we can really start working on Chart 2.0 as in my main objectives.

Plazik’s picture

@Pierre.Vriens there are some addition charts modules

  1. d3.js
  2. Webform Chart
  3. Webform Charts
  4. FusionCharts
  5. Highcharts
  6. Easychart
  7. Views Gantt
  8. Table to Chart
  9. Morris
  10. jqplot Charts Library
  11. Poll Chart Block
  12. jsGantt View
  13. Scald: Datawrapper
  14. JpGraph
  15. Google Visualization API

What are the steps required to go from chart to charts, ie: how does "a" site anything related to chart replace by the charts equivalent (where is the docu to do so)?

Upgrade patch does not exist. So the only way going from chart to charts is rewrite dependent modules.

What can be done urgently to somehow force current chart users to start doing something to address the imposed April 2015 deadline (different from making the module unavailable for download on D.O).

Add warning on status page with hook_requirements in new 7.x-1.2.

the best I know about the differences you're asking about is included in the comparison (see link above)

The page contains the current modules features. I've asked about of the future of Chart module.
I'm worry about one thing. You are planning to develop universal chart module with support a large numbers of libraries. But this module has already developed. Charts has API and Views support. That's why I asked about the difference between these two modules.

Pierre.Vriens’s picture

Thank you Nickolay for #9, for mentioning about 10 more modules that aren't included yet in the comparison. We'll have to think of how to also get them added, without making it even more confusing. Anyway, your list confirms my "What an interesting choice of modules to pick from" in my original issue description, don't you agree? And note that we haven't even considered the type of license that comes with each of the supported charting libraries (free, commercial, etc).

About your "Upgrade path does not exist": you're confirming what the current situation is. That's also why I'm suggesting the 2 bullets in my #3 above, using the 2 issues I mentioned there as a starting point. Anybody who has a better proposal, please join the conversation!

About your "... rewrite dependent modules": that seems to me the correct answer for modules who "depend" on chart. But what about sites who just use chart directly (instead of via some module that depends on it)? I'm afraid that for these sites the answer is either "rebuild any chart related content in such sites" or "rewrite your custom module similar to what's needed for modules that 'depend' on chart". It would be nice if anybody with sufficient chart experience could elaborate a bit on this ...

I really like your hook_requirements suggestion, because it would start ringing bells in all those 26K sites today. But that might require that when such 7.x-1.2 version becomes available, we'd also have to change the status of the 7.x-1.1 version to something like "unsupported" I think. The combination of both would be that first the recommended module upgrade shows up, and after the upgrade happened, the hook_requirements does the rest of the job. Please correct me if I'm missing something here. BUT: there is another challenge to move forward with this 7.x-1.2 idea itself: I (more or less) insist on some type of blessing from either the current maintainers, or otherwise sufficient "users" of the chart. In the spirit of "community", I want this to be a kind of joint decission.

About the "future of chart module": at this point I don't know yet, at least not for sure. And I want to leave all options open for discussion. But if I am to decide, I would want to move it in the direction of my original objectives. So that in the end, "chart" might become some type of UI (eg for site builders) that hides the PHP coding that today for some modules seems to be needed to create some type of chart with any of those charting modules available. Obviously combined with potential module dependencies where appropriate (I do not want to re-invent the wheel ...). If in the future then support for charting library X gets dropped and needs to be replaced by library Y, it might be possible to just have the chart module take care of that. Another outcome of it might be that by using chart, you can easily swap between charting libraries, similar to the way that the wysiwyg module gives you options to swap between WYSIWYG editors (hope that comparison makes sense).

About your "worries" in the last paragraph: your absolutely right about what you wrote about charts there. But while working on the Comparison of charting modules, I got the impression that there are other charting modules that might also be a valid alternative to consider. And which module to actually go for, seems to me a case-by-case choice to be made, which depends on all sorts of criteria (like browser support, PDF support, views integration, licensing options, etc). If it still isn't clear: rest assured that I'm not interested in re-inventing the wheel, but instead want to take advantage of whatever is already available.

Pierre.Vriens’s picture

Issue summary: View changes

Yet another charting related module (not include in #9 either): https://www.drupal.org/project/webform_reports

eosrei’s picture

Add warning on status page with hook_requirements in new 7.x-1.2.

+1

It seems like the current 7.x-1.x-dev is stable enough for a 7.x-1.2. I propose adding a hook_requirements ASAP and releasing 7.x-1.2 otherwise unchanged from the current dev. It worries me so many people are still installing this module since I added that notice over a year ago.

Pierre.Vriens’s picture

Great Brad, +100 from me, the sooner the better I think. Do you have time for it in the near future? Otherwise I'd be happy to help you on it. Do you want me to create a new issue specific to what you suggested?

Plazik’s picture

It worries me so many people are still installing this module since I added that notice over a year ago.

You can add class="error" to <p> tag in warning.

But what about sites who just use chart directly (instead of via some module that depends on it)?

Anyway, the API of 7.x-1.x and 7.x-2.x will be complete different. I think the proper patch is impossible to create.

eosrei’s picture

Everyone think the current 7.x-1.x-dev is reasonable to make a 7.x-1.2 out of? Or should I add the hook_requirements patch to a different branch and tag that instead?

Pierre.Vriens’s picture

Brad, how about we continue the discussion of your (great) suggestion about such 7.x-1.2 version via #2371075: Chart 7.x-2.x Release, in which I just added a new comment about your posting there also?

To answer your #15 here: by digesting the open issues recently, I've discovered quite a few comments there like "replace your current 1.1 version by the 1.x-dev version, which is way more stable and includes a lot of fixes".

About the hook_requirements: what's your proposal regarding the severity of the message to be shown, and what would be the content? It appears to me that that is worth a few more exchanges of ideas about it. And also this related idea (if not too difficult to implement): add an admin option to yes/no (default = no) also show some type of warning message on any pages where the chart module is used to render some chart.

To finish: should a similar 6.x "upgrade" be considered, like a 6.x-1.4 ? Still about 4K sites using that version also!

eosrei’s picture

I don't intend to spend any time on any 6.x code again. D6 is already deprecated and will be unsupported the day D8 is released; which will hopefully be before April.

The Charts module provides the majority of the functionality needed for charting in Drupal 7. The main issue I see going forward for Charting in Drupal is that the Charts module needs a D8 fully OOP port. Of course, you are the putting the effort into this project right now while the rest of us are pulled in other directions, so I don't mean to intrude. :D Thanks for your work

Pierre.Vriens’s picture

Interesting update in #2005282: Charts and Graph integration, within comment #3 ... Step by Step, bit by bit ... Anybody else?

Plazik’s picture

This module has 20700 active sites for 7.x version https://www.drupal.org/project/usage/chart
Google Analytics Reports which uses this module has 11800 active sites for 7.x version https://www.drupal.org/project/usage/google_analytics_reports.
I am (as a co-maintainer of Google Analytics Reports module) planning to swich from "chart" module to "chars" because I don't understand when Chart 2.0 will be relesed.

@Pierre.Vriens, if you're planning to develop super chart module for Drupal you should ask for co-maintaning of Charts module.

eosrei’s picture

@Pierre.Vriens, if you're planning to develop super chart module for Drupal you should ask for co-maintaning of Charts module.

This is the best course of action. Chart needs a full rewrite and Charts already handles the needed functionality. BTW: I checked with Quicksketch (Nate) before recommending his module, I'm sure he'd be happy to have help.

Pierre.Vriens’s picture

Waw, I really "like" Nickolay's comment in #19, even though I'm not 100% sure about the co-maintaining part of it: is it a recommendation, a command, a suggestion, something else? Please remember my original objective with "chart" (scroll to the top to read them again). By becoming a charts co-maintainer it appears to me that by doing so I'd somehow give up my attempt to be independent as it relates to which charting module one should go for. From what I understand so far about charts, charts appears to me like a really valid approach to consider. But looking at it from my chart-objectives, there are other modules worth considering also (based on what I learned from my module comparison). Module popularity for me is NOT a criterium when I make choices for our own sites. instead I use criteria as included in the comparison. And "license" options (not even included in it yet) is another criterium. Additionally, any time I'd be contributing to (eg) the charts module, is less time available to have chart moving forward.

On the other hand, any of those charting modules interested in me helping them to become chart 2.0 compatible (oeps, another term to be discussed and/or defined), let me know and I'll try to help where I can. But for that I don't think I need to be a co-maintainer, right?

I like to hear that soon the chart-deadline problem related to D7 is going to be reduced with about 11800 instances, which leaves "only" 20700-11800=8.900 sites to be resolved. However, forgive me that I currently worry about 1 specific issue about charts: #2374185: Plans about current RC1 release of charts?. How to get it resolved soon? While waiting for that to happen, "I" consider that as a (new) red flag for both chart and charts.

About that "super chart" module: personally I don't like the "super" in it, because there are like a dozen of other charting modules that are also 'super'. Maybe something like "common" is more appropriate instead.

Pierre.Vriens’s picture

While I was writing #21 (and the related charts issue I mentioned in it), #20 also got added. And before posting my #21, I quickly scanned the open charts queue (mostly issue titles only for now). Because of that quick scan, I seem to understand (and believe) the "... he'd be happy to have help" in #20 also. Because of that I'll consider it seriously.

But first I want to give it a little bit more thought (let me sleep on it, ok?). What might help influence my decision in moving in the direction as suggested in #19 and #20, is that @Quicksketch (Nate) also adds like a +1 to this issue, or any variation of that to explain/motivate a bit his viewpoints, expectations, needs, etc.

With that, together with #19, #20 and #1 (hope I don't forget any of the other valuable comments, eg as in #18), I'll consider it as an invitation from a representative group of charting related maintainers (experts) that I respect a lot for what they achieved so far. Of course any similar comments from anybody else might help also.

PS: no "super"-chart please, personally I just like "chart" ... Though it might change soon to "chart(s)".

eosrei’s picture

I really "like" Nickolay's comment in #19, even though I'm not 100% sure about the co-maintaining part of it: is it a recommendation, a command, a suggestion, something else?

Neither @Plazik (I had no idea who you were talking about at first ;) ) or I are commanding you to do anything. It's simply our recommendations. There are already, per your research, many Drupal charting modules. Reviving this module with a rewrite effectively makes another one. NIH (http://en.wikipedia.org/wiki/Not_invented_here) is a major problem in tech, see XKCD #927: http://xkcd.com/927/ . Drupal contrib needs simplification which is why I'm happy to reduce the charting options by disabling this module: https://austin2014.drupal.org/session/stomp-complexity

Please remember my original objective with "chart" (scroll to the top to read them again). By becoming a charts co-maintainer it appears to me that by doing so I'd somehow give up my attempt to be independent as it relates to which charting module one should go for. From what I understand so far about charts, charts appears to me like a really valid approach to consider. But looking at it from my chart-objectives, there are other modules worth considering also (based on what I learned from my module comparison).

I understand that you want to rewrite it, but to what end? Charts already does what many people need/want. Reviving this module IMHO will make the Drupal ecosystem more confusing. I want to see more colaboration in Drupal; there's currently far too much fragmentation. The best place to start a soon-to-be-needed charting module for D8 is with the Charts codebase, since it already implements JS Google Charts.

And "license" options (not even included in it yet) is another criterium.

Do you mean for the external services for external libraries? Everything on drupal.org is GPL already.

Additionally, any time I'd be contributing to (eg) the charts module, is less time available to have chart moving forward.

Yes, exactly. :D

Edit: yes, I wrote this before @Pierre.Vriens wrote #22

Pierre.Vriens’s picture

@boombatower (Jimmy): I hesitate a little bit to just move forward as suggested by @eosrei (Brad) in #3 in #2371567: Chart 6.x-2.x Release, and this because of your request "Also please stick to >=7.x-2.x branch." in #1. Are you OK with expanding your request with "... and/or =6.x branch"? Sorry for hesitating ...

PS: haven't heard/seen anything so far from @Quicksketch (Nate) after my #22. Though yesterday I've been doing some more research in the charts issue queue, and created a few new issues there ...

eosrei’s picture

@Pierre.Vriens, I think it is safe to assume @boombatower asks that all new functionality or rewrites go into a new branch (8.x-2.x, 7.x-2.x, or 6.x-2.x.) We don't want people using new code until it is thoroughly tested. Only minor changes should be made to the existing 7.x-1.x and 6.x-1.x.

Pierre.Vriens’s picture

About 5 years later, but still: +1 for this Open Letter, it still applies today I think. As a new co-maintainer of the chart module, I'd like to use the opportunity to announce "my" support for various bullets mentioned in it, and this for any module in Drupal's charting-land.

Status update about my PS in #24: I have not received any feedback from Nate (@quicksketch). That feedback is crucial to me, before I will make a final decision about the suggestions in #19 and #20. While waiting (I can be patient, but time is running ...), I'm working on joining forces with other charting modules ALSO, similar to what's mentioned in #18.

Pierre.Vriens’s picture

Still no news from Nate (Quicksketch) so far. However, I decided to use a different approach, by creating a new issue in the charts queue: #2377647: Offer to become the maintainer of Charts.

Any type of +1 support (in that issue) would be appreciated !

Fingers crossed now to see what will happen about this new issue I just created. If it doesn't work out: hey, at least "I" tried ...

Pierre.Vriens’s picture

Interesting issue in (yet another) module in the land of charting, created by a former chart co-maintainer: #258425: Consider merging 'chart' and 'charts' ...

Pierre.Vriens’s picture

Pleased to announce: the recent updates in #2377647: Offer to become the maintainer of Charts ... and the answers in 3 of my recent charts issues!

Pierre.Vriens’s picture

For anybody interested in using other charting libraries that are not the 2 libs supported by charts, checkout #2364427-7: Renderer for Charts and Graphs APIs, which contains an interesting example of how support for the d3 library was added to forena, via a rather basic custom module. I think it could have been any charting JavaScript lib. The example for now seems to be like a prototype, curious to see how that issue (and sandbox?) will evolve in the near future.

My question about it, related to Chart 2.0: how about creating like a chart_forena submodule which more or less would be like a clone of that custom module (probably with further refinements similar to what David (metzlerd) suggested in comment #10 )? Obviously we would have a forena dependency, but at the same time you also could consider all those other forena goodies. And it would offer an alternative to the SVG Graph lib (for which I know at least 1 person who is looking for an alternative lib supported by forena). A next step could be to make the d3 lib an admin config option (similar to what is done in the wysiwyg module to enabled your preferred editor), and further enhance this submodule to support other JavaScript libs available for charting. Just to be complete: maybe we can come up with something similar, like chart_charts, for the 2 libs supported by charts?

Pierre.Vriens’s picture

To anybody interested in moving from chart to charts: be aware of the #2384833: HELP needed to match content of RC1 with ambiguous HEAD issue ... (including the PS in it), and the related charts issues mentioned in it.

Anybody interested in helping to get it resolved?

Pierre.Vriens’s picture

Priority: Normal » Critical

Special request to Jimmy aka boombatower: please checkout what I wrote in #2371075-22: Chart 7.x-2.x Release earlier today.

After doing so, and hoping that you can agree to what I'm up to, please consider this: how about we swap maintainer-status?

Reason why I ask: it might help to convince my current sponsor to continue sponsoring me to reach my goal as initially described in this issue.

PS: If for some reason you cannot accept my request, or not yet, no problem, don't worry, OK?

robertwb’s picture

Just wanted to throw in a +1 here Pierre. For me, the D8 path is also the best 2.0 path. If we can start with a robust OOP model for abstracting chart structure then the actual production of a chart in a given rendering engine is akin to a theme-ing task.

Looking through the couple of threads that your ideas on this are spread, I don't see an Object-Model diagram - does such a thing exist, and if not, can we put one in the community docs area (https://www.drupal.org/documentation)?

Pierre.Vriens’s picture

Per my comment in #2376179-6: Chart 7.x-3.x Release, I hereby would like to bring my comment in #32 to the attention (again) of the current project owner. Please let me know your answer, so that "I" know how to move forward.

bmick@arcweb.com’s picture

I need dynamic charting capabilities in D8. Dynamic because the data sets will come from mysql tables, and not static html or csv data sources. Can anyone provide a status on this project?