briggysmalls / ithemes-exchange-digital-variants Goto Github PK

At the moment if the digital variant needs changing (due to a plugin update) then it must be deleted then re-added.

This is no good if many products already exist, as deleting the variant removes it from all of them.

Either the variant should be updated or deleted/readded to all of the existing products when the version number changes.

Note: that this should not change the variant title or value titles back to the default

With the introduction of a single variant shared by all products comes potential improvements.

A user can now rename and add/remove options to the variant and this will be reflected on all products.

However, the variants recognised as being digital are still fixed as those with a value matching the digital slug (hardcoded).

Addon settings should be introduced, allowing a user to pick which values are the digital ones.

The digital variants are currently not visible from the frontend. Furthermore when attempting to set a variant pricing, it is revealed that the variant values are missing from the select box.

commit: cbcaee2

When added to a website the plugins installation seems to have caused all shipping to be applied as the default 'International' instead of correctly identifying 'UK'.

A CI server should be set up to run the linter and execute tests

If a setting is missing a new digital variant is created.

This means that if the digital variant id is lost somehow, or the digital variant value is lost, posts can be left orphaned.

Some attempt to cleanup should be made when creating a new variant

The terminology employed up until this point is completely confusing.

Currently the following concepts are in use:

• Feature that means products can take many flavours: variant
• A product that has a distinct flavour: variant
• A database object that describes a set of flavours: variant
• A product that has either physical or digital flavours: digital variant
• A product that is of the digital flavour (out of possible physical/digital): digital variant

This really needs sorting out as the terms are so overloaded it is hard to understand what the code is trying to do.

A product is currently identified as being the digital variant of a product, based upon whether it has a value with a slug/post_name of 'digital'.

However, should multiple format variants be created, this slug becomes digital-x where x is an integer.

The test should be improved to be more robust

In just a few commits, regressions were introduced that broke the plugin. Tests should be written to avoid this

iThemes has a concept of Product Types, with the core plugin creating:

• Simple Product
• Physical Product
• Digital Download

The Digital Variant product should be its own product type. This means that Physical products could be unaffected by the addition of this plugin (e.g. downloads not added to them) which may be desirable. Furthermore it simplifies the identification of products that have a variant indicating if they are Physical/Digital, as all that need be checked is the type. Perhaps a filter could be added that automates the addition of the variant too.

It seems very simple to add a product type, for example the Simple Product type is created with:

// Simple Product Types
'simple-product-type' => array(
	'name'        => __( 'Simple Products', 'it-l10n-ithemes-exchange' ),
	'description' => __( 'This is a basic product type for selling simple items.', 'it-l10n-ithemes-exchange' ),
	'author'      => 'iThemes',
	'author_url'  => 'http://ithemes.com',
	'file'        => dirname( __FILE__ ) . '/product-types/simple-products/init.php',
	'category'    => 'product-type',
	'tag'         => 'core',
	'labels'      => array(
		'singular_name' => __( 'Simple Product', 'it-l10n-ithemes-exchange' ),
	),
	'supports' => array(
		'sw-shortcode' => true
	)
),

where init.php is an empty file.

A misnamed function causes the plugin to break when attempting to checkout with a digital variant.
This should be fixed.