Oof, I wish these things would actually error for me or in Drupal CI. I'll fix these.
Thanks for this! Don't know why I didn't experience it. What version of core are you on?
I think you would need to disable/delete the normal Taxonomy Term view and then your new View might work. Or, you should be able to update that view with a Term With Depth argument that comes from Core (this would not be based on a search_api index).
@pnigro - can you try a different URL for your View? That one might have interference with the regular taxonomy term view.
I've attached a video of my personal testing - can you see if there's anything that I did differently from you?
I just created a "Cumulative Total Field" plugin, but it's only on DEV. When I issue a new release, I'll close this ticket. In the meantime, I invite you to explore dev and provide feedback.
Please note that the new field and the existing field both have a new option available: Summation Method. You can either select "Database" or "PHP". Database is better if you have an entity-based view and if you need pagination or anything like that. PHP is better if you have a view based on a non-Drupal database table or are using a module like Views CSV Source; however, for the PHP method, you really need to be displaying all rows or the cumulative value will reset when you page.
@fjgarlin, I believe there is a data issue with this. I went to look at Charts: https://new.drupal.org/drupalorg-api/project-usage?nid=232629&weeks_ago=2
Here were the results for me:
{
"usage": {
"1763251200": {
"6.x-1.x": 1148,
"7.x-1.x": 106,
"7.x-2.x": 253545,
"8.x-3.x": 45540,
"8.x-4.x": 68,
"5.0.x": 47075,
"5.1.x": 22058
},
"1763856000": {
"6.x-1.x": 1096,
"7.x-1.x": 159,
"7.x-2.x": 251146,
"8.x-3.x": 44304,
"8.x-4.x": 68,
"5.0.x": 44205,
"5.1.x": 21488
}
},
"success": true
}
The results here ( https://www.drupal.org/project/usage/charts → ) are:
Thank you!
Hi @drumm, there's a video of what I ultimately want to use this for in this Slack thread: https://drupal.slack.com/archives/C51GNJG91/p1764246715745809?thread_ts=...
(I want to enter my username in a field and get a table of all the projects I'm listed in a maintainer of). Case #2 would satisfy my needs.
Yes, I see it has updated since I posted. Thank you!
This does not seem to have resolved itself. For example, https://www.drupal.org/jsonapi/index/project_modules?filter%5Bmachine_na... → shows no active installs, but there are two listed on the project page.
andileco → made their first commit to this issue’s fork.
Sorry, I didn't mean any D7, just more than a single entry for 5.1.x, for example.
Hi Paul, please apply the merge request to test. I've included images from where you can find the depth field on the filter and on the argument. Hope this helps!
Hi Paul, thanks for your question. The quick answer is, I have only created the filter (vs. contextual filter (aka "argument")) plugin, and actually had it on my to-do list to create the argument plugin for the next version: https://www.drupal.org/project/search_api_term_with_depth/releases/1.0.0 → .
I'm converting this from a documentation request to a task. I don't expect it will take especially long to add the argument plugin.
Making a note here that this issue focused on date. We may want to start a new ticket that confirms the decisions made around time. Opting to ship earlier rather than let this ticket languish.
Thank you for working on this right away, @flgarlin! I am logged in on drupal.org, but when I navigate to:
https://www.drupal.org/drupalorg-api/project-maintainers?uid=2054544 →
I get a page not found. Do I need to try at a dev or test URL of D.O?
My manual tests are now working well - @nikathone, can you give another review?
Reviewed from Views, API, and field (chart data table).
Realizing I need to add into the README, package.json, and composer.json.
If you want to use the "first row" option, you'd need your data entered like in the attached picture, where each column is a country and the row is life expectancy.
Good to move to RTBC?
Interesting... in those examples, they use the subtitle as a legend. Will look at the first row question soon.
@bspeare, please review. I have attached a video displaying the output. I think the main difference is if you're in Views, using the Numeric Array field. If you are using a chart field, you can actually type into a cell the low number followed by a comma then the high number (e.g. 74.7, 83.2). See the two attached videos.
@bspeare, is this ready for review? If so, can you change the status and assign to me?
Please import this modification of the view and test with the MR. Would this work for you?
This is interesting. A few requests:
Would you be able to create a CSV of dummy data that could be used for testing?
Could you replicate your view with the Views CSV Source module?
Could you then share your View configuration?
If not, could you just share your View configuration? In particular, I'm interested to see if you're using the "Group by" option on your date field.
@bspeare - I'm definitely open to adding this. Are you able to take a first attempt and have me review it?
Thanks for that catch, @mwymore. The package.json option was generating the dist directory and the Composer option was not. And it gets a little masked by the CDN option. Please review this MR and let me know what you think.
andileco → made their first commit to this issue’s fork.
Implementing these changes resulted in a View displaying the first 110 rows of a 2,000,000 row CSV file taking 64.51 ms to render versus 21000 ms.
The issue at play here is the query-based nature of Views. Your parent View will be one query, and the Chart Attachment will be a different one. These can work together well if the categories are the same or if the Chart Attachment is a subset of the parent display. But when the child has different categories, there's not a good way to tell the View where these new values should fit. I think solving this might be too complicated.
I have two recommendations if you face this issue:
1) populate your data with null values until the categories match
2) use the Grouping feature in views, which might achieve what you're hoping (the drawback is that you will have to have the same chart type)
@mutasim al-shoura - thank you for creating this ticket. If you are using Highcharts, here are my recommendations that don't require a patch:
- Enable the Accessibility, Exporting, and Export-Data, and Texture libraries (you can enable them here: /admin/config/content/charts)
- Add the Highcharts Caption module*: https://www.drupal.org/project/charts_highcharts_caption →
*If you scroll to the bottom of https://www.highcharts.com/docs/accessibility/accessibility-module, you'll see that using the caption is a great option for the description, and the nice thing is that it gets included in the Chart export, too.
However, the above is really Highcharts-specific. Would you be interested in making a more generic solution, which would apply to all the libraries? You have a start to that in your patch.
By the way, if you could create a merge request, I would appreciate that over a patch, as it runs code checks and tests.
@bspeare - I'm not sure about with Google, but this is actually fixed for Highcharts in 5.1.x. If that's what you're using, navigate to /admin/config/content/charts, the select Highcharts Settings > Global Options > Language and then enter a comma in the "Number formatting: Thousand separator" field (and save the page). If this is for Google, you're welcome to open a new ticket.
Thank you, @nikathone! I like that you make it work with the original function. I'm happy with this and the code quality checks pass.
Thank you, @annemiekb - I just created a MR with your patch to help benefit from the automated tests and make it a little easier for folks to work on the issue.
andileco → made their first commit to this issue’s fork.