methnen

Ah, thank you. So it’s just that the CSS that controls the look/feel of the slider is not loading and returning an error sometimes.

The site is hosted at wordpress.com, I’ll get in contact with them to see if they can identify the issue.

I really appreciate the quick response.

• This reply was modified 1 month, 1 week ago by methnen.
• This reply was modified 1 month, 1 week ago by methnen.

Awesome. I replied to you in the pull request comments.

I can’t see what you did so I can’t tell what might be wrong.

Do you have your code as well as a place I can see this in action?

Correct.

At least as far as I know.

• This reply was modified 2 months ago by methnen.

Those are line breaks. Not hyphenations.

And there isn’t a way.

I mentioned in another thread that SVG and Canvas text handling is atrocious. And this is an example of that playing out.

To create a new line of text in Canvas or SVG you actually have to create a separate text object and then position below the previous line of text.

I convinced the Chart.js developers to add the subtitle functionality specifically to provide a way to somewhat deal with the issue. Thus why I recommended reformatting your titles to provide a shorter main title with longer/additional info in the subtitle field.

Yes, that’s why I was saying add it in and I think it will work.

I believe, what’s happening is that the plugin is getting confused because there’s only numbers in all of the cells. So it’s having trouble deciding what is a potential label and what isn’t.

Adding the label to the first row fixes this.

I’ll have to figure out if I can think of an efficient way to fix this longer term.

Oddly enough I think you might be the first person who’s ever brought this up.

OK, so there’s something going on here that I’m not immediately positive on.

But try formatting the data like this with a label on the first row for the data set:

https://methnen-dropshare.s3.amazonaws.com/pb-67EyrN3kYB.png

Let me know if that solves the issue you’re having?

Have you considered using a bar instead of column chart in this case?

I would try that with a larger height.

That will thicken the bars quite a bit an should leave the chart being more readable on mobile.

I’d also look at trying to use a shorter main title with the rest of the longer info put into the sub title.

Chart.js and most every Chart rendering library uses Canvas and/or SVG to draw the charts and text handling in both of these is kind of a mess which is why you’ll often see long titles and labels causing issues.

I don’t understand the question completely.

The plugin will create a chart out of whatever data you put into it.

I don’t “type” the data going in or out to Chart.js on purpose because it’s basically impossible to know what type of data it might be and trying to auto recognize things like dates is very problematic.

Everything is either a number or a string as far as the plugin is concerned.

You can use dates if you want and as long as those dates are formatted in a way that works and includes all of the data and date values you want to display it will work fine. There’s many examples of people doing that with this plugin including in the examples in the wiki.

But it seems you’re trying to do something else.

The Units thing is more for Display and Tagging purposes (it’s linked to a WP Taxonomy)

It’s currently not in my plans, but this is just a Chart.js chart so you could potentially figure out how to do it since Chart.js can be extended via plugins.

However, the chart should have compressed to fit the width of its container. I’m not immediately sure why that didn’t happen in this instance.

In cases where a chart will be seen on mobile I’d typically recommend switching to a chart type that will handle that compression best given the data set you have.

Chart.js does not proportionally resize well. I don’t know if it’s in their (the Chart.js) plans to ever correct that limitation but it’s a standing limitation unless something changed relatively recently.

For what it’s worth Highcharts which is much more mature is pretty terrible at proportional resizing as well, though if I remember correctly it is there my experience with it was that it mangles the charts worse than what I standardized on for both Chart.js and Highcharts.

Which was to have the height hard coded and the width fluid.

Can I get a little extra info? Are you using Chart.js or Highcharts? How is the CSS being applied?

You should never make changes to a plugin itself. Changes should always be made via hooks or inside of your theme.

Happy to help direct you but need a bit more detail. ??

OK, this one is really weird. I’m not quite sure why it’s happening yet but something is causing the canvas objects to always have a height of 600px despite me hard coding the height into the canvas object itself. This happens on my end too (though it didn’t use to). I think it might be inside of Chart.js that this is happening but I’m not sure yet.

However, I do have a possible fix. If you can email me at jamie AT methnen.com and let me know on here when you’ve done so I’ll send you an updated copy of M Chart and if you can test it out I’d appreciate that.

This issue was resolved over email and the fix will be in the next release of M Chart.

Oh, and depending on what kind of caching you’ve got going on you might need to hit the Settings -> Permalinks page in the admin panel to make sure any rewrite rules have been refreshed.

I don’t speak or read Japanese so apologies if google translate didn’t do a good job.

But I think the problem you describe is the M Chart post_type slug conflicting with an existing one in your install of WordPres.

You can override slugs and any other post type arguments using the following filter hook:

register_post_type_args

In practice this looks something like this:

add_filter( 'register_post_type_args', 'm_chart_register_post_type_args', 10, 2 );

/**
 * Filter register_post_type_args and modify it for our purposes
 */
public function register_post_type_args( $args, $post_type ) {
	if ( 'm-chart' == $post_type ) {
		$args['rewrite']['slug'] = 'something-other-than-chart-here';
	}

	return $args;
}

This should work as is if you throw it into your functions.php file and change the something-other-than-chart-here to what you’d prefer M Chart to use instead of chart for individual chart URLs.