New Version of Classic Commerce

I fixed that warning and also an error in the verify email template.

Bumped version to 2.0.1

I hereby confirm it’s fixed :slight_smile:

1 Like

Hi @seanthompson

A minor alignment issue with the City/State/Postcode field.

I have fixed it with:

.store-address-container .city-and-postcode label {
	display:block;
}

I couldn’t get the attributes lookup table or HPOS to work

With the attributes lookup table you mean this? (this isn’t working)

That’s odd. This was working fine before. This is similar to what happened when product tags stopped working.

Got the attributes working. Just need to make a few adjustments. Hope to have updated version available tomorrow.

2 Likes

Great!
Just wondering, do you already know if your version will replace the one at the CP plugin page and Github?

Guido

Eventually, it should be available in the directory.

The attributes should be working now. Also fixed the css for the City label.

1 Like

Both things are fixed.
But I now also notice that button “Generate variations” doesn’t work properly. Infinite loop (and js error in browser console). But, when reloading the page, variations are added.

Thought I had that fixed too. I’ll look into it.

JS errors fixed.

I hereby confirm it’s fixed :slight_smile:

Hi Sean, do you have plans to get the plugin listed in the CP plugin directory? To replace the current version.

I’m preety sure that’s the plan. From what I understand the big hurtle is figuring out the easiest way to document the changes.

1 Like

It seems that the currently listed CC is not maintained for quite some time now.
IMO they should simply replace it (as v2), instead of asking you to send countless pull requests to the CC repository at GitHub. It’s already confirmed that it’s working fine (except for the notices). But maybe it’s not that simple… Oh, let’s not forget to inform the dev of v1…

@ElisabettaCarrara Are you still working on this, or would you prefer that I or someone else take over?

Still working on this, I am trying to understand if it’s better to build one single BIG PR or work on folders and do one per folder. Results seems better on a folder basis (testing the diff via meld on my local machine I mean).
What would it be better to implement changes?

What I would do is delete all the current files and folders and upload the new version using the top level files and folders. That way is probably least painful.

1 Like

Without a real commit, brute force like that?

@seanthompson and @Simone what do you think about this approach?

1 Like

It can be done, but we’ll loose unit test.

In my branch I’ve merged Sean’s code into the current code.
A lot of tests are failing, but I think they should be carefully reviewed as they could point out errors in the codebase of the new verson.
Can’t do much with the tests and build step.

Edit: also my commits need a careful review. The branch was intended just as an experiment that someone can replicate better.