Dashboard: Rename class/feature to remove conflict with legacy dashboard widget

[timmyc]

Fixes #2137

This branch renames the WC_Admin_Dashboard to WC_Admin_Analytics_Dashboard to prevent the name collision that currently results in the legacy Woo Core dashboard widget from being displayed.

Screenshots

Detailed test instructions:

• On master of wc-admin installed/activated, note the bug by visiting the wp-admin dashboard and seeing that the WooCommerce Status widget is not shown ( see screen grab above )
• Install/npm start this branch, revisit the wp-admin dashboard and see that it is now shown
• Visit the WooCommerce Admin dashboard and verify it is still working

[jeffstieler]

Nice and simple!

[justinshreve]

Should we rename this flag to analytics-dashboard/customizable too?

[timmyc]

@jeffstieler is this branch still working for you? I can no longer see the dashboard on this branch - I attempted rebasing but still no love. master works fine.

[jeffstieler]

@timmyc I'm not seeing the dashboard anymore 😕

[psealock]

I'm not seeing the dashboard anymore 😕

I'm not sure how this branch ever worked without updating this line too:

woocommerce-admin/client/layout/controller.js

Line 41 in ea0789a

if ( window.wcAdminFeatures.dashboard ) {

[Tobias-Conrad]

@jeffstieler @justinshreve I was one of the admins which can not live without the WOO dashboard in the WP Dashboard.
I would like to contribute with testing, if a solution is ready please provide a download link.
At the moment it looks like, not all place of the dashboard issue have been seen ;-)
Goal could be to have this fix in the next update.

[timmyc]

Good catch @psealock guessing while testing this I had a cached build locally. I was noticing there is a lag between a file save, and changes being reflected in my local build with npm start running.

I applied the fix, and also changed the name of the name to analytics-dashboard/customizable as well per @justinshreve 's feedback.

[psealock]

LGTM

[justinshreve]

Good catch @psealock guessing while testing this I had a cached build locally. I was noticing there is a lag between a file save, and changes being reflected in my local build with npm start running.

It's possible that you maybe didn't exit and restart npm start after making the change, which means the old flag would have been true still? So the next time you went to test it, the correct flag kicked in.

[timmyc]

It's possible that you maybe didn't exit and restart npm start after making the change, which means the old flag would have been true still?

Yep absolutely this was it. And that explains some of the choice words I uttered while trying to get the PR working again yesterday - 😆