ClassicCommerce or Classic Commerce? Status as a research plugin?

Thanks for the replies. I’m not sure, though, that the ClassicPress format should necessarily be seen as an example to follow. Classic Commerce (or ClassicCommerce) is a separate project and will (theoretically) run just as well on WP4.9. I am currently working on the status report page and making sure that the results are generic for either WP or CP. The “Classic” part is just suggesting that it is block-free and jetpack-free.

As another example, @anon71687268 has written a plugin specifically for CP and has called it “PHP Error Log Viewer”, not PHPErrorLogViewer.

Anyway, happy to hear other opinions on this. We will go with the consensus.

1 Like

Is classiccommerce intended to be the “one and only” recommended ecommerce plugin. As putting “Classic” in the name would very much imply that it is part of ClassicPress and therefore make it harder for there ever to be an alternative contender.
An ecommerce plugin and its subplugins are probably the main area to generate income and should be equally open to alternatives.
So my thought is that “Classic” should only be allowed in plugins etc. that are directly controlled by what ever is governing ClassicPress.


Good question Mark! This was discussed early on and my understanding is that it was decided that Classic Commerce would not be officially linked to ClassicPress. It was going to be seen as a stand-alone product, and I’m sure if others wanted to develop alternate e-commerce plugins they would be most welcome.


Who is “our” here, though? This is a 3rd party project; whomever is leading that project should make the decision on the name, the logo, etc, etc. The waters have been greatly muddied with the commerce fork for a couple of reasons:

  1. lots of initial feedback was solicited regarding logo and name, but, I feel this gave the false sense that this was a community project, and not merely the solicitation for ideas that it was, and

  2. adding the plugin to a ClassicPress-owned repo furthered the idea noted in item #1.

Both of the items noted above have given the community a false sense of ownership (ie, decision-making) in the project. This left a bad taste for me and, indeed, these are the reasons I solicited zero feedback and didn’t request a research repo when forking the TInyMCE Advanced plugin.


Classic Commerce in my mind is linked to a physical store.
CamelCase ClassicCommerce bring me back to e-commerce.
Just my impression…


Hmmm… OK, I see your point. But it is a community project (just maybe not this community), so should we set up a separate place to discuss it? I can see how using the ClassicPress arena to discuss this is muddying the waters.

Do we need our own forum and our own slack account?


In which case it’s up to the developer to call it whatever they choose so why are we even discussing it?

Maybe the definition of core plugin needs to be more clearly defined?

But here’s my tuppence worth:

In many ways, I’d prefer ClassicCommerce, all one word. If we use two words as in Classic Commerce, there would be nothing to prevent someone else creating a ClassicCommerce plugin, which to me looks more “official”?

But, what if there are 3 or more words? As an example, ClassicContactForm or ClassicCommercePaypalGateway? Just using these as examples but you get the general idea. Starts to look a bit messy in my view.


I’m not making a recommendation, necessarily, just adding my .02 on why it shouldn’t be up to the community to decide on the name. IMO, the code should have been setup outside of ClassicPress and with it’s own communication channels.

This is exactly my point.

Yeah, it gets tacky in a real hurry; same thing in the WP space. I see absolutely no need to use the word “Classic” in a plugin or theme name and, indeed, the word doesn’t speak to the “future” at all; it only reminds of the past.


I want to note that I’m not sounding off here just to be the opposition; I’ve actually skipped this thread many times in the last few days knowing my feedback wouldn’t be helpful. I’m not necessarily looking to discuss it, defend it, or win anyone’s opinion over; I’m simply sharing my thoughts as I’d been tagged in the thread. :slight_smile:

Update: I guess I haven’t been skipping over this thread for days as it’s only a day old. I guess it just felt that way :wink:


I’m really glad you contributed John. Tagging you was incidental but I think you’ve made a very good point.


Thanks, Alan … and I don’t mind the tag. :slight_smile: I’ve had this conversation (about the commerce project and how research repos muddy the waters) with a few other very active community members and it does seem that the research repos give a confusing impression. Perhaps it’s germane (perhaps not)…but, after reading the discussion on a new SEO plugin offering, I had the strong sense that it was also headed down this same road.


I’ve missed this. Can you let me know where this was discussed please @anon71687268 ?

1 Like

I think it was in Slack. The following post is pretty much the whole discussion (I think) from the forums. The convo there doesn’t necessarily muddy the waters, however, the title of the thread does make it seem like a core project. Research plugins, from everything I’ve read and understood, are plugins that will be considered for core inclusion, not external plugins that are going to be managed (or monetized) by outside 3rd parties on an ongoing basis.


Ah, so there’s been nothing recent then? I’ve seen the forum posts but I’m not a regular on Slack, so I thought I may have missed something on there.

I guess “recent” is a relative term for Slack as we’re only able to view the latest 10k messages on the free plan. The 10k may seem like a lot, but, it actually goes pretty quick. If you ever hear someone say that something was “10k’d” … that’s what that means. :slight_smile: Also, I’m not positive it was in Slack; I thought maybe it was since I didn’t find it on the forum.

1 Like

I think there are really two issues here, but they are related.

The first is a matter of history. When the initial discussions about ClassicCommerce took place here, they were prompted by a different developer who, so far as I understand it, is no longer involved.

The second is what the names Classic Commerce and ClassicCommerce imply. It seems to me that, as @anon71687268 says, the name ClassicCommerce implies that the plugin is somehow attached to, or part of, the ClassicPress project. So, if it isn’t, it shouldn’t have that name. (Whether it is then called Classic Commerce or something else entirely then becomes irrelevant so far as these forums are concerned.)

But here’s the bit that muddies the waters for me. How did the ClassicCommerce project get taken over? I could well be wrong, but it appears to me that the transition from one lead developer to another happened precisely because of its association with ClassicPress.

So I’m essentially with @anon71687268 in saying that there has to be a clear decision one way or the other, and then everything else should follow accordingly. So if this e-commerce project is not to be brought somehow under the ClassicPress umbrella, there should be a clean break in terms of repos, forums, etc as well as in name.


Excellent points, Tim. Thanks… that summarises it perfectly.

1 Like

Fair points here, though I’m sorry to hear that part of the approach left a bad taste for you. This is why I put “EXPERIMENTAL” in the description of all the ClassicPress-research plugins, the ClassicPress-research repositories are an experiment and I am open to clarifying this situation further.

From my perspective, I am willing to stand behind the official releases of the ClassicPress core software, fix bugs, provide support etc. I will need help from the community to develop larger features but I can make the commitment to “keep the lights on” so to speak.

For the ClassicPress-research plugins, I cannot make the same commitment, but I will help out where I can.

For Classic Commerce (CC) specifically, there are several people who are actively working on the project, but we do not have someone who has formally accepted a “project lead” role. (We did for a little while, but the last person recognized they didn’t have the available time to lead the project.) I think this is one thing that would help clarify the situation a bit.

As far as whether it is a community project or an official ClassicPress project or whether CC should get its own Slack …

This is not an official ClassicPress project in the sense that we don’t recommend it within the dashboard as an official solution for e-commerce. First of all we don’t have the mechanisms to make these recommendations yet (plugin directory etc) and second I’d like to see any such recommendation voted on by the community once there are a few releases out there and people have been testing it more.

I don’t agree with this. I think there is a lot of value in providing a subforum and a Slack channel, and an unofficial place on GitHub, using our existing infrastructure. Managing and maintaining an extra subforum etc is not very difficult for us, but setting all of that up from scratch and making sure people know where to find it would take time away from actually building the thing and hurt the project.

So CC is in a space between an official project and a 3rd party project where it is not really either one. I think this is mostly OK but I will share some more thoughts about the name.

I agree with this. I think this points towards calling it “Classic Commerce” for now, and possibly making a more general guideline that names like “ClassicSomething” (one word) should only be used by projects that are officially supported by ClassicPress. (Right now, you can tell the difference based on where it lives on GitHub. If it lives under then it’s official.)

This is a feature, not a bug! One of the benefits of storing this code in a central location is that it doesn’t disrupt the workflow to move new people in/out of the project.

Here we come back to the question of “what is a research plugin”. I think it is worth clarifying further, but here is what we have so far (from

Does that help any, or muddy the waters further? :wink:

Also, moderators please don’t split this thread - I am going to update the thread title instead. We have been discussing two issues here but they are pretty closely related.


Notice that the original project name is ClassicPress, not just Classic. This makes some difference to me. From that point of view, it’s not quite right to restrict “ClassicSomething” names.

Yes, such a name can be associated with CP, but I don’t think we can forbid this. CP pretends to be an ecosystem. And it’s a widespread naming practice for satellite projects to mention a recognizable part of a brand to conquer the target audience. E.g. Windows / WinRar, Instagram / InstaTools and so on. WordPress / ClassicPress :slight_smile:

The word “Classic” is not our property, isn’t it? If someone would develop a plugin “ClassicMusic” it may be confusing, yes, but it’s ok. Some people think that FaceApp is a Facebook-driven project, but Facebook is not responsible for that mess.

Plugin status
In general, my vision is very close to @james thoughts. (I just write posts much slowlier :slight_smile: )

Really think that we shouldn’t throw any projects out of the infrastructure (Slack, Forums, Github etc) at least at this stage. CP community is rather small now. It needs as much consolidation as possible to increase its summary value, weight and influence. This is very important for the “external” point of view. Each project which focuses on ClassicPress and positions it as the primary development platform is quite valuable. It can bring here additional attention, contributors, partners, users, clients. More activity, more buzz — better chances for promotion and integration with other projects (hosters, providers, agencies, studios etc) for all of us.

To my mind, we now have 3 “levels” of projects within this ecosystem.

  1. ClassicPress itself (and potentially core plugins).
  2. Community-driven projects (which are inspired by ClassicPress and give it a high priority).
  3. 3d-party projects (which are build foremost for WordPress, but add CP support, too).

So, technically I agree with @anon71687268 that number 2 is not a part of number 1. But considering all the things above I think we should treat those 2-level projects very carefully and even encourage (foster? stimulate? – not sure about wording) them. Slack channels, Forum threads — fine!

However this doesn’t mean that such projects should have any direct competitive advantages towards 3d-party plugins (in ranking etc). This only means that we should stimulate communication and sharing the experience between ClassicPress contributors, the community and other enthusiasts. BTW this also helps everybody to stay in touch and avoid WP-alike scenario (Core team vs Community vs Plugin devs).

For example, I haven’t contribute to ClassicCommerce yet (and I’m not sure that I’ll have time for that), but I follow this channel in Slack, see familiar people there, find tons of useful notes about Github (thanks @james once again) and stay in course. Even drop my 0.02 cents if needed. But if this project moves to another platform, I’ll unlikely follow it.

We are not so big to search for separation. 20-30 active contributors for all projects, probably? Let’s think about it when we reach the line of 200-300 :slight_smile:


It also helps to keep developers “in”.
If an independent developer can find here a good place for sharing suggestions this can stimulate her/his contribution to the project.

Maybe some extra suggestion about names usage, ecc… can clarify some situations.
For example, I’ve three little plugins: for CPcompatibility the name seems good for me as it is strictly related with ClassicPress, but a disclaimer about that it’s not an official plugin can be added to the readme; for xsx-debug I think that’s ok; for CPvars I think I should rename it (maybe xsx-vars or something fancy that explains better what is it for :man_facepalming:).