Problem/Motivation

Having the full name of the source system (commerce, ubercart, magento and woocommerce) in the name of the migrations and plugins isn't necessary for uniqueness because there is already a 2 character designator that can be used. Plus it is a nuisance to type those all the time and then to sometimes forget that the commerce source plugins are different in that they do not include the source system in the id.

Any objections?

Proposed resolution

Use the following for the migrations and plugins for each system

Drupal Commerce

commerce1 - Commerce 1 source.
commerce2 - Commerce 2 source.
dc - Anything generally useful. Its "owned" by the commerce system and is version agnostic.
commerce - The current Drupal version plugins.

Magento

magento1 - Magento 1 source.
magento2 - Magento 2 source.
magento - Generally useful to all Magento versions.

Shopify

shopify - All sources.

Ubercart

uc6 - Ubercart 6 source.
uc7 - Ubercart 7 source.
uc - Generally useful to all Ubercart versions.
ubercart - The current Drupal version plugins.

WooCommerce

woo3 - Woocommerce 3 source
woo - generally useful to all Woocommerce versions.

Remaining tasks

Agree to do it
Write a patch
Review
Commit
Smile - less typing

Comments

quietone created an issue. See original summary.

quietone’s picture

quietone commented

Ah, this won't work when a plugin is the same for say ubercart 6 and ubercart 7. In that case the name would use 'ubercart' so it looks like the long names stay.

Still would like to change the commerce ones to use c1 and now c1_commerce.

joachim’s picture

joachim commented

> Ah, this won't work when a plugin is the same for say ubercart 6 and ubercart 7. In that case the name would use 'ubercart' so it looks like the long names stay.

You could always have a separate plugin for ubertcart 6 that's just an empty subclass of the ubercart 7 one.

> This arrangement does mean that c1 loses the '7', which is a nice indicator that it is a Drupal 7 source.

Why not 'c7'? You have 'u6' and 'u7' for ubercart.

heddn’s picture

heddn
Primary language English
Location Illinois
commented

What about uc if there is a common Ubercart plugin. And for common to all, say a destination, c2. Or try to push common to migrate plus or core.

quietone’s picture

quietone commented

I think it was heddn that said 'naming is hard'.

Just thinking out loud here.

Why not 'c7'? You have 'u6' and 'u7' for ubercart.

Because I'd rather stay closer to what the source calls itself. Commerce on Drupal 7 is Commerce 1 and on Drupal 8 it is Commerce 2. But then I'd have to look up the Ubercart versions. Which I just did, and it looks like Ubercart 2 for Drupal 6 and Ubercart 3 for Drupal 7.

What about uc if there is a common Ubercart plugin.

If we do that then what is the prefix for plugins common to difference versions of Commerce, Magento, Shopify and WooCommerce? Perhaps, Ubercart - uc, Commerce - cm, Magento - mg, Shopify - sf will work.

Hmm, maybe 3 characters for the names for not common plugins

  • Commerce 1 - cm1 and cm for common to all Commerce sources
  • Magento 1 - mg1 and mg for common ..
  • Magento 2 - mg2 and mg for common ..
  • Shopify ? - sf? and sf
  • Ubercart 2 - uc2 and uc
  • Ubercart 3 - uc3 and uc
  • Woocommerce 3 - wc3 and wc

What does that look like for order migrations

  • d7_commerce_order.yml -> cm1_order.yml
  • d7_order -> cm1_order
  • d6_ubercart_order.yml -> uc2_order.yml
  • d6_ubercart_order -> uc2_order.yml

A common ubercart source

  • ubercart_store -> uc_store

A commerce process plugin

  • commerce_attribute_target_type -> cm1_attribute_target_type

And then there are the directory paths that need changing.

  • commerce/src/Plugin/migrate/process/d7 -> commerce/src/Plugin/process/cm1
  • same for other sources
heddn’s picture

heddn
Primary language English
Location Illinois
commented

Can't take credit:

There are only two hard things in Computer Science: cache invalidation and naming things.

-- Phil Karlton

Some suggestions, mainly inspired by what folks in these communities call the things.

uc6
uc7
uc => generally useful for all UC.

commerce => D7
commerce2 => Anything generally useful. Its "owned" by the commerce2 landscape, so a global name.

magento => magento, because that's what the project itself calls it.
magento2 => magento2, because that's what the project itself calls it. Similar to symfony, symfony2, symfony3, symfony4
woo2 => wooCommerce2
woo3 => wooCommerce3

shopify => Does it have versions? I cannot think of a short name for it.

quietone’s picture

quietone commented
Issue summary: View changes

All I could find about Shopify versions was that in 2014 a Shopify employee said:

We are releasing new versions continually on a daily basis, often several times during the day. We do not publish a specific version number or what is comprised of those version patches due to the security considerations involved,

despite that in 2013 Shopify announced Shopify 2 along with a list of feature changes.

So, who knows?

Moving on,

@heddn, thanks for bringing in some common sense!

And I like it. Just one thing. I'm not sure I like or dislike using d7 for commerce 1 because then the plugins look very much like core d7 versions, as in d7_order or d7_product_variation_type. There is nothing wrong but it makes me think they are plugins provided by core not a contrib project. Will others think the same thing? Will it be a bit confusing?

joachim’s picture

joachim commented

> There is nothing wrong but it makes me think they are plugins provided by core not a contrib project. Will others think the same thing? Will it be a bit confusing?

Yes, I agree. I would prefer c7 for Commerce for Drupal 7.

On a side note:

> We are releasing new versions continually on a daily basis, often several times during the day. We do not publish a specific version number or what is comprised of those version patches due to the security considerations involved,

Hahahahahahaha!!

quietone’s picture

quietone commented
Issue summary: View changes

Updated the IS to change d7 to c7 for commerce, add the general name for all sources.

Do we agree on these names?

heddn’s picture

heddn
Primary language English
Location Illinois
commented
Issue summary: View changes

I reworded what I /intended/ to mean in the IS. I'm not tied to it, so change it again if you don't like. Sorry I didn't jump back in here earlier, a bit pre-occupied with real life the last few days.

quietone’s picture

quietone commented

Take all the time you need to deal with real life!

I have a slight reservation about using the same text 'commerce2' for both the generally useful in Commerce and the specific Commerce 2 sources but it will not cause a problem in the code. So, I'm good with the suggestion in the IS.

@joachim, do you agree? Anyone else?

heddn’s picture

heddn
Primary language English
Location Illinois
commented

My logic on commerce vs commerce2 and all the naming... is that the thing that "owns" the thing is what we call it. Since commerce (v1) owns the prior migrations, commerce. And commerce2 owns both commerce2 sources/destinations and any generally useful things for commerce2. While uc/uc6/uc7 owns those things.

Its a fine line.

joachim’s picture

joachim commented

Typo:

> uc - generally useful to all magento versions

Also, I think it's a bit confusing that all the version-specific things have a number suffix except for Commerce 1, which gets the unsuffixed 'commerce'.

heddn’s picture

heddn
Primary language English
Location Illinois
commented
Issue summary: View changes

Good points in #13. I don't like c1, c2 though. We don't call commerce that short name. So why not commerce1/commerce2? A little more typing, but I think clarity should win.

quietone’s picture

quietone commented

Yes, I like the current version whatever the outcome for typing.

+1

heddn’s picture

heddn
Primary language English
Location Illinois
commented
Status: Active » Needs review

Good consensus. Now the practicality of things.

We need to clarify on commerce, commerc1/2 differences. Things that are /specific/ to commerce 2 should be labeled commerce2. Sources and destinations for commerce2 use the entity api, so they are not per-se specific to commerce 2, because they use the entity api underneath. And process plugins are not specific in a lot of cases, so they could be tagged only commerce.

But if we have things which are developed to handle commerce2 idiosyncrasies, then those things should be labeled commerce 2.

It isn't clear to me really, what is specific to commerce or 2. I think I know when I see it, but how to articulate it, I'm not sure.

Why am I in such a quandry? Because of the logic over in #2935951-33: Copy migrate source plugin from migrate_drupal_d8 into migrate_drupal

quietone’s picture

quietone commented

Quandry, what a good word for this. I would think the problem applies to Ubercart 4 as well?

quietone’s picture

quietone commented

Not necessarily a problem with ubercart since we have 'uc' to distinguish the common plugins from the current plugins, although they may be in the same namespace. And that's the problem, distinguishing the common plugins from the current plugins. How about we do the same for Commerce and use an abbreviation for the common Commerce plugins? If so it could be 'dc' for Drupal Commerce or 'cm' or 'com' for commerce.

heddn’s picture

heddn
Primary language English
Location Illinois
commented

I have seen dc used before.

quietone’s picture

quietone commented
Issue summary: View changes

Ah, a precedent! I have updated the IS to include the current version as well.

Does anyone see a problem with the proposed resolution? Is there agreement?

heddn’s picture

heddn
Primary language English
Location Illinois
commented
Status: Needs review » Reviewed & tested by the community

dc is fine for general. the rest of the IS seems fine. Naming is important, but we're starting to backlog on this bikesheding. So let's stop it.

quietone’s picture

quietone commented

Great thanks!

I want to get this done, so will work on a patch after a break.

quietone’s picture

quietone commented
Parent issue: #2961933: Renaming Magento 2 to make room for Magento 1 »

Change this to a parent issue and make new issues to rename each sub module so the individual patches doesn't get too big.

heddn’s picture

heddn
Primary language English
Location Illinois
commented
Status: Reviewed & tested by the community » Fixed

No objections since this went RTBC. Marking fixed. That gives us 2 more weeks of feedback.

quietone’s picture

quietone commented

The intention has been to commit the renaming issues today/tomorrow for the next release, so I'd rather not wait another two weeks.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.