What do you want from OpenMage to make it competitive for the future? #2873

Flyingmana · 2022-12-31T16:24:47Z

Flyingmana
Dec 31, 2022

The year ends, a new one starts.
We got stability, continuity and compatibility(with modern php/sql) covered.

Now we know the various things our "competitors" are up to.
So looking at them, what are the features which are most interesting for you, or make a relevant difference to change to them because we dont have them(or not good enough)

elidrissidev · 2022-12-31T18:01:43Z

elidrissidev
Dec 31, 2022
Maintainer

Some features that I'd love to see in OM but also think will bring a lot of value to users:

Multi-stock functionality. Currently everything is hardcoded around the "Default" stock, but at least the base is there, so I think it's feasible.
Audit logs. If relying on the Admin panel alone as a way to manage a store, you'll often play the detective role trying to figure out who did what.
Editing an Order without canceling it and creating a new one.

9 replies

fballiano Jan 2, 2023

sometime ago I created https://github.com/fballiano/awesome-openmage

sreichel Jan 4, 2023
Maintainer

👍

Very first ... "awesome openmage" should be linked and updated.

There are many missing feature and still a lot of extenson, so it difficult to tell whats "needed".

From my programmers view there is one PR that i want to have merge sometimes ... #423. Every model (and every block-class - another PR) could have its own event-prefix, to be accessed by observers easily ...

fballiano Jan 4, 2023

Very first ... "awesome openmage" should be linked and updated.

I started as a test because I couldn't merge things into our "readthedoc", but I didn't mean it to be already "complete" :-) But it already has the same content of our "readthedoc" so... you know...

fballiano Jan 4, 2023

Very first ... "awesome openmage" should be linked and updated.

@sreichel what do you mean? that the ChangeAttributeSet should be in the awesomeopenmage page? I can add it for sure, but it's not even linked in our readthedoc...

sreichel Jan 4, 2023
Maintainer

I just wanted to have it link in README. :)

ChangeAttributeSet was just a suggestion.

addison74 · 2023-01-01T19:38:04Z

addison74
Jan 1, 2023
Collaborator

Let's detach OpenMage from Magento 1 and promote it as an alternative platform to Magento 2, OpenCart, PrestaShop, Woo Commerce. Magento 1 is dead and buried and OpenMage is not Magento LTS. I hope that those who want to switch to M2 will think twice, having OpenMage as an alternative. Why change something that works, just for the sake of keeping up with the news? However, M2 has over 1300 reported issues and 810 PRs at this moment.

Let's convince the developers that OpenMage can offer them a way to continue making money, with the platform being updated. They can replace their Magento 1 sections with OpenMage. The Internet is full of solutions, books, tutorials, all related to Magento 1, it is a shame to waste them.

To solve all reported issues and PRs that are open. If we don't succeed, at least let's sort them. It is not difficult if we do this in a team if 6 - 10 people actively participate. I proposed myself to visit this repository for 1 hour a day.

Let's settle on two versions of OpenMage, one LTS to guarantee some bug fixes and MAIN to be a modern version with changes that cannot be made in the LTS version.

To update some Magento modules. For example, Mage_Captcha needs a better user interface similar to reCaptcha.

When all this is done we can make a TODO list in which to gather improvements in functionality. As @elidrissidev says above, the possibility to edit an order, it is true that they are extensions, but I am sure that some of you have a solution for this. I have a not very long list of changes that bring more functionality, for example, I recently ran into a situation where I had to disable a customer's account until a dispute was resolved. As well as having the possibility to hide temporary a custom option in Frontend, an additional checkbox to what exists now.

0 replies

fballiano · 2023-01-02T10:05:49Z

fballiano
Jan 2, 2023

We did a lot in 2022, solving bugs, introducing a lot of improvements, cleaning up extremely outdated code, moving to a more modern stack and I'm pretty sure we already have the best set of workflow for code quality of any other PHP project :-)
OM has some of the brightest minds of the ecommerce world and it is a privilege to to be part of it, all of this great work deserves so much more acknowledgment.

Moving to the difficult topics, here's my considerations.

I've always said that being solely a "LTS" means death, we need to be the best platform again, this is not possible if we get stuck on deleting a single file that nobody uses since forever because maybe that one person in the world (that is not updating OM anyway) could have a problem. We kill our whole project to save somebody who doesn't even care.

We have to acknowledge who we are: a community based project with less than 10 active people, thus:

we cannot maintain 2 branches
there is no reason why v19 should still support ie8
if a user has to fix something while upgrading to a new version IT IS FINE (it doesn't mean let's destroy everything without caring, but not even wasting thousands of hours maintaining a v20 just because we don't want to remove ie8 from v19, because that's almost the only difference). Let's ask any M2 store how difficult is to upgrade a minor version, and let's compare to us.
the team should be on a "turn" basis, it's not right that there are these many dormant roles in the team, maintainers that are not longer involved should step down, every role and privilege should have an expiration date, elections, meetings
I'd like to see RFCs for the old decisions, for example who decided to have a website with that information? where's the RFC for that? who decided to provide 5years LTS? where's the RFC for that? I think those decision should be discussed every X time.
who are these partners https://www.openmage.org/partners/index.html? why I never see anything from them here? For sure I'm missing something but that needs to be more transparent. I would need a couple more OM customers but on the website we are promoting in big letters companies that do not seem to help us that much. If they do, then I'm sorry but it needs to be more evident.
we do not have the manpower the manage the website/readthedocs, we would be better off if the website would just redirect to the github, people would immediately see the amount to work that's done on a daily basis and the information shown on the website is mostly the same that's already in our README (apart from the debatable partners section)

The points above, IMO, would allow us to be more effective and to have a better working image for us (we're all developers at the end of the day).

From a software point of view I think we should have a full page cache functionality, we're lacking a modern varnish and that's already quite a problem. Our RWD theme should be modernized a little bit (it's mostly very good but could be improved a little bit). We'd need more "improved navigation" (everybody needs what I'm talking about) support, a little bit more advanced SEO features and we've to keep up with PHP 8.2. If we manage to be the first project to keep updated with the fast pace of PHP we will get people attention.

You all deserve the best year ever!

10 replies

Flyingmana Jan 5, 2023
Author

I say this for some specific reason that has nothing to do with the people in the group (which are all great professionals).
When we take decisions we need a specific number of approvals, and that number has been decided (probably) based on the number of people who can vote

It is not, its based on various standards of certification.

But if 7/10 admins are no longer responsive (it's just an example) that it's a big problem and can block everything.

All important Decisions are based on a minimum needed participation, and a possibly limited timeframe. (see rfc voting) Admins/Maintainers who do not participate during this timeframe, are not counted.

it was totally fine at that time but then we shouldn't answer "if you want to change something then RFC" when extremely important decisions were taken by a single person. otherwise those choices should be up for debate because they are still affecting everybody and situations constantly change

yes, thats why I introduced the RFCs, so its not anymore "a single person decides", and also that its not hidden in some tickets or chats somewhere.

fballiano Jan 5, 2023

It is not, its based on various standards of certification.

If there's the need for 3 voters and in the group only 3 people ever participate, it means having a 100% adherence. You see what I mean and what's the problem here?

Flyingmana Jan 5, 2023
Author

It is not, its based on various standards of certification.

If there's the need for 3 voters and in the group only 3 people ever participate, it means having a 100% adherence. You see what I mean and what's the problem here?

its a problem which can not be solved by reducing the size of the group.

fballiano Jan 5, 2023

but it will be made evident, when now it's not and we think it's all ok when it's not

Flyingmana Jan 7, 2023
Author

the team should be on a "turn" basis, it's not right that there are these many dormant roles in the team, maintainers that are not longer involved should step down, every role and privilege should have an expiration date, elections, meetings

I dont know how much it is going to help with it, but I started to list all the roles and responsibilities we have here: https://github.com/OpenMage/organizational/blob/main/Roles_and_Repsonsibilities.md

kiatng · 2023-01-03T01:59:00Z

kiatng
Jan 3, 2023
Collaborator

To be competitive and attractive for new projects, we need to remove legacy js libraries and have one of these: alpinejs, vuejs, quasar, reactjs, or some other modern js lib.

For existing projects, drop v19, continue with v20 as main.

7 replies

Flyingmana Jan 3, 2023
Author

So there's 2 PRS (yours and Dan's) that are proposing essentially the same thing, should we keep only one?

not really, this one is about branch names and which one is the default branch, while mine is more about Release and support schedules. I would go so far and say they are in big parts complementary.

addison74 Jan 3, 2023
Collaborator

Quasar, AlpineJS, Tailwind are good options for creating an interface to fall in love with. Bootstrap 5.3 comes with new improvements. If we manage to replace the legacy with modern alternatives it would be a great achievement, but realistically speaking it is a lot of work. On the other hand, I don't even want to evaluate the impact on the extensions that use them. For example, the Color Picker from Magento 1 can be replaced with better good looking variants, but I have two extensions that use it and the developers don't want to hear about Magento 1 anymore. If our OpenMage platform will start to matter in production and the interest will increase with surely they will change their opinion. It's wonderful to see how much things have changed, I didn't think I would end up programming in Windows again, but DDEV radically changed my perspective.

I would have a proposal to fork Nexcess/Turpentine and connect it to OpenMage to start providing a solution for those who want to use Varnish. In the past I was close to this project. Thus we try to reduce the "great advantages" that Magento 2 has compared to Magento 1.

fballiano Jan 3, 2023

@elidrissidev agree with @Flyingmana here, I'd keep them separated to have them as small as possible :-)

fballiano Jan 3, 2023

@addison74 agree, it's a very tough decision (and development). Regarding Turpentine, if would be great to have a working Varnish solution, I'm pretty sure @luigifab's version is the best nowadays https://github.com/luigifab/openmage-turpentine-varnish

addison74 Jan 3, 2023
Collaborator

@fballiano - @luigifab made a fork at another fork. Jeroen Vermeulen was a major contributor to Turpentine in a while. I have nothing against using this repository from now on for a Varnish solution.

Flyingmana · 2023-01-04T15:55:53Z

Flyingmana
Jan 4, 2023
Author

Adding this, because it was not mentioned yet:
Make it easier for new Developers and Users to learn how to work with OpenMage, by writing beginner guides and extend the general Documentation.

11 replies

addison74 Jan 5, 2023
Collaborator

I'm sorry I didn't check the link, I have that brochure in PDF format. I will add it as a link where it can be downloaded.

sreichel Jan 5, 2023
Maintainer

https://alanstorm.com/category/magento/

addison74 Jan 8, 2023
Collaborator

This is a good resource for learning https://www.magestore.com/blog/magento-tutorial-for-beginners/

fballiano Jan 9, 2023

This is a good resource for learning https://www.magestore.com/blog/magento-tutorial-for-beginners/

@addison74 great resource, added it to the awesome openmage

justinbeaty Jan 13, 2023

Also from Alan Storm: https://alanstorm.com/series/checking-in-on-openmage-and-magento-in-2020/

sreichel · 2023-01-04T22:24:11Z

sreichel
Jan 4, 2023
Maintainer

Later ...

Moderize OM - modulize OM.

We removed Mage_PageCache, Mage_Backup and allowed to re-install them via composer. And there are already repos prepared for modules that are disabled by default - Mage_Poll & Mage_Tag). Old themes will move to git repo. Old MySql4 classes too ...

Why not add a repo for every Mage Module?

(i already tested this for some parts ...i works. We just need to have code in one repo for contributions (like M2) ...

1 reply

sreichel Jan 6, 2023
Maintainer

I know this will not come in near future, but it w'd be nice to have. Patches could be applied in the same way we do it for ZF1F.

m-overlund · 2023-01-05T11:50:10Z

m-overlund
Jan 5, 2023

Basic online marketing setup can be a hazzle in OM (pixels, serverside tracking etc.).
Things like (Google) Tag Manager(s), Google Analytics 4, Facebook Conversion API and the likes are mandatory for most webshops, and much easy to setup on the "competing" platforms.

OM already supports Google API / Universal Analytics for example.

should follow through and be updated to support GA4 IMHO.

Whether you're an Ad Agency or Webshop owner, this is one of the issues i hear people (including myself) is dealing with.
WooCommerce and Shopify is often recommended in favor of OpenMage, in these areas.

3 replies

addison74 Jan 5, 2023
Collaborator

Related to GA4, I brought up in the discussion that this year the OM code must be updated. I know that some can insert their own manual code, but we have this facility in the Backend interface. If it will not be updated it must be removed. The rest of the issues could be solved by extensions, but no developer has invested time in updating them. What I have analyzed recently, the main players have the last updates from 2018 - 2019, none for PHP 8.

m-overlund Jan 5, 2023

I do agree on updating or removing Analytics support from OM.

For reference the only GA4 module I've found and is using is: https://www.scommerce-mage.com/magento-google-tag-manager.html
(Dunno if it supports PHP 8).

sreichel Jan 15, 2023
Maintainer

I'd add GA4 support ... just need some sponsors ;)

colinmollenhour · 2023-01-05T17:27:38Z

colinmollenhour
Jan 5, 2023
Maintainer

Regarding the public website, the push for this really came from the EOL of M1 and the PCI compliance concerns that came with it. Some payment processors were positing that Magento 1 code was non-compliant and for shop owners to make the case to them that OpenMage is a viable migration path to maintain a secure installation it was very beneficial to have a more professional looking website. Unfortunately, the decision makers often don't understand what a GitHub project or pull request is and would not consider a GitHub README to be a "legitimate" online presence (unfortunately there is no objective standard for this).

I agree that it needs more maintenance so probably we should make it more maintenance-free by minimizing any information on it that is bound to become outdated. For example instead of "PHP 7.4 Support" it could say "Powered by the actively supported and immensely popular PHP project"

As far as documentation for the public site, it is basically a simple Jekyll site built by GitHub Pages, nothing more. The content is stored in plain HTML/Markdown files so changing this verbiage is as simple as finding the right file and submitting a PR. I just updated the README.md with this information.

All the same, thanks for bringing attention to this as it does need more attention. Would be great to get some community volunteers to scrutinize the entire site and submit some PRs.. What is the best way to seek such a volunteer currently?

3 replies

sreichel Jan 5, 2023
Maintainer

To work on this, there needs to be a better documentation.

is it possible to aggregate some data from repo using github api? (e.g. to update commit counter)
where does release information at http://127.0.0.1:4000/magento-lts/changelog/magento1-openmage-20_0.html come from - and how to improve output (better format for release information, or adding anchors?)