OpenMage LTS

Payment Method Support for Brazil

2024-10-03T00:00:00+00:00

Brazil has one of the biggest populations in the world and is a key market for e-commerce. However, the country has unique payment preferences and challenges that merchants need to consider when selling to Brazilian customers.

We are excited to announce the availability of the PagBank Integrações module for OpenMage, an open-source solution that allows merchants to accept a wide range of payment methods in Brazil. This module is continuously updated to support both Magento 1 and OpenMage platforms since 2014.

Peculiarities of Payments in Brazil

Brazil has a unique payment landscape with several popular methods:

PIX: An instant payment system created by the Central Bank of Brazil, allowing for instantaneous and real-time payments 24/7 using QrCodes.
Boleto Bancário: A popular payment method where customers generate a boleto (bank slip) and pay it at banks, ATMs, online banking or even at supermarkets.
Installments: Many Brazilian consumers prefer to pay in installments, spreading the cost of a purchase over several months. This is a common practice and is supported by most credit card issuers in Brazil.

Features of PagBank Integrações

3D Secure Authentication: Enhances the security of online transactions by requiring an additional layer of verification, reducing the risk of fraud and significantly improving the approval rate.
Support for Major Payment Types: Including credit cards, PIX, and Boleto Bancário.
Installment Payments: Allows customers to pay in multiple installments, making it easier to afford higher-priced items.
Lowest Fees: When you use this official partner module, you get one of the lowest fees in the market and pay less than official rates, while support the project.

With PagBank Integrações, you can provide your customers with a seamless and secure payment experience, tailored to the unique needs of the Brazilian market. Stay tuned for more updates and enhancements to this essential module for OpenMage.

You can start using the module by visiting the PagBank Integrações website or downloading the PagBank for Magento 1 and OpenMage on Github.

Screenshots are also available in the Features section, or you can check the demo store with the module.

Do you (really) need more?

2023-01-03T00:00:00+00:00

The eCommerce ecosystem is continuously moving. Every year, new software and ways to sell online appear. In this article by Front-Commerce, we’ll try to take a step back and see how the Magento ecosystem and merchants managed to go over these changes in the past 15 years, and what may be needed today.

Selling online is teamwork

Merchants who have been selling online for years have developed their own company culture and organization around their online store.

Over the years, their eCommerce platform configuration and features have been refined to adapt to the way people work in the company. Depending on its size, one or several people interact with the online store on a regular basis (not just visitors and customers).

These “admin” tasks involve:

adding new products and ensure they’re easy to find by customers (search, attributes…)
updating inventory
communicating new products and offers to customers (in the store, with CMS pages and blocks, or elsewhere online – social media, newsletters, forums, videos…)
preparing and shipping orders
handling returns and customer support
accounting…

With a low volume of orders, one person can handle this with almost any system. However, as the turnover increase, merchants need more people and better tools to handle the volume of their activity.

2007: enter Magento

When Magento first launched in 2007, selling online was vastly different than it is today. Smartphones, marketplaces and social media were not yet used as sales channels - yet merchants still had to do all the same tasks.

Over the past 15 years, Magento has evolved. It now offers more features and better user interfaces, so merchants can provide a quality service to their customers and better tools and processes to their team.

The modular approach of the software also enabled a vibrant ecosystem to grow. Third-party services provided official modules to integrate their services into the user journey, such as shipping or payment methods, ERPs, CRMs, and marketing automation. Developers published and/or sold modules for recurring features merchants and teams needed, like rules for shipment pricing, data feed for external services, admin logs, performance optimization, developer productivity, and software quality.

The success of the OpenMage LTS fork shows that many merchants selling online were satisfied with their platform. They were not willing to invest in a full replatforming after Magento announced its new major version in 2015, or when Magento1 reached its End Of Life in 2020.

After many years, their online store had become more than a default install of a software - it was like a house fully equipped for the needs of its owners, with a subtle mix of features adapted to their context and habits. Relocating meant reconsidering most of the choices and rebuilding many of the subtle, convenient features.

Developers were also satisfied with Magento. The expertise they had acquired over the years allowed them to develop almost any feature efficiently and quickly. That’s why there is still a community contributing to the OpenMage project with bugfixes and improvements today.

Selling online is tough

We know that eCommerce is difficult. Merchants sell online in their own way, with various methods for organizing catalogs, setting prices, and offering promotions. Some merchants now sell internationally, having adapted to their customers and ecosystem to grow their business.

Customer habits have also changed: user behavior, smartphone usage, user experience standards, etc. People are more likely to place orders from their phones, and merchants use social media to become visible to their ideal customers and bring more qualified traffic to their storefront.

Today’s user experience must meet the standards set by the most popular online services. Design, interactions, and performance expectations from users are completely different than they were 10 years ago. This change also affects SEO; search engines prioritize websites that meet performance and user experience standards, especially on mobile.

For this reason, I believe merchants who are still selling online today are those who embraced uncertainty and continually challenged themselves.

Technology has continued to evolve

On the web, technology moves fast and new improvements or new standards appear continuously.

As an example, Magento store owners have to deal with:

new PHP versions (PHP is in version 8.2 as I write these lines)
libraries getting deprecated (did you know that several libraries used by Magento are unmaintained by their initial owners, and are now part of the Magento core?)
software projects die (do you remember OSCommerce? Also, the “Magento 1” project was declared dead… but open-source enables projects such as OpenMage to write a new story on top of this legacy)

Some of these technology changes are welcome (i.e: new PHP versions bring better performance and code maintainability for PHP projects) but others are seen as a burden (i.e: a JS dependency is so entangled in many different parts of the frontend that replacing it with another is a huge task to undertake).

This is where I see the benefits of a solution such as OpenMage LTS. It is a lighthouse that remains stable (in terms of features) while following the needed technology changes from the underlying ecosystem. Thanks to the OpenMage community, merchants can maintain their fully tailored online shop up-to-date without having to recreate their custom features on a new foundation.

This is perfect for features that are just done! But for features that must evolve with users standards and usage, I think it often is not satisfying enough.

The rise of 3rd-party services

External services rise and disappear. Embracing this fact is a key factor allowing merchants to innovate and grow faster than their competitors.

Do you want to grow internationally? Support new payment and shipping methods used by customers from different countries.
Do you want to sell on a marketplace? Export your catalog to the marketplace your targeted customers visit daily.
Do you want to engage your community? Embed widgets from your main social media platforms on your website, and optimize your pages for sharing and reposting.

Plus, there are many more features that may be relevant in a specific context but are impossible to have in a single platform by default:

Reduce checkout friction with one-click payments.
Provide personalized product suggestions.
Unify content and commerce search results.
Offer top-level customer service with dedicated agents.
Allow customers to return their products for free without friction.
Accept crypto-payments.
And more.

External services come and go, but platforms are extensible. Popular services began to create and maintain integrations with popular platforms. The variety of platforms to support grew so much that all these services now prefer to invest in robust APIs that can be easily consumed by developers, no matter the platform they use.

Merchants can innovate faster by integrating these APIs into their existing workflow. Being one of the first to leverage a new service before it is successful enough to have integrations with the most popular eCommerce platforms should be considered a competitive advantage.

In terms of software, this means integrating these APIs into the technology merchants have spent years customizing to their needs should be easy (and cost-effective).

That’s where traditional systems and platforms can reach a limit. Developers may face technical difficulties integrating a new service into the existing monolithic commerce platform.

This is the use-case that a new generation of solutions can solve.

Headless commerce and composable storefronts

Headless commerce and composable storefronts offer an alternative way to move forward. Merchants can begin by relocating parts of their monolith to external services for specific tasks.

For example, merchants can use a headless CMS to manage their store’s content and use a composable storefront to build a custom user interface with modern technologies, while keeping the same underlying platform (Magento since 2007 and now OpenMage LTS) for the tasks it already handles.

This approach allows merchants to keep their existing features while gaining access to features provided by external services. It also makes it easier and faster for developers to integrate new services.

We have seen in recent years that projects have experienced a “second life” by using their Magento instance upgraded to OpenMage LTS as a headless commerce backend. In a few months, they were able to deliver a new frontend based on more maintainable technologies (allowing them to more easily hire web developers).

For some of them, OpenMage’s responsibilities were reduced to the essentials: catalog management, user management, and transactional commerce. Search and content management were migrated to other best-of-breed services, and unused features were removed. This resulted in a simpler and more stable codebase!

Later, some projects continued this journey even further: they replatformed their commerce platform to Magento2 (or other solutions).

These examples all shared one key enabler: the addition of a REST API adapted to the use of the storefront. It made this transition faster and cheaper and therefore less risky. We believed in this approach very early in the Front-Commerce team, and our partner PH2M managed to make it a reality by adding a wide range of REST APIs to bring headless feature coverage at a higher level than what even Magento 2 supports as of today!

Conclusion

Do you need to go through all these additional steps? It depends on your context, your customers and their usage.

You could keep investing in incremental improvements of your current frontend theme.

But if you aim at differentiating your brand from competitors thanks to innovative commerce practices (adapted to your customers and your company), it may be worth it!

A new Home for Magento Connect Modules

2019-08-18T00:00:00+00:00

One essential part of the Magento Ecosystem are the Marketplace and the big number of Modules for every usecase. But with the eol of Magento(1) its to expect, also the marketplace will get cleaned of all the Magento(1) modules at one point. This already happened once a few years back, when a lot of older modules got removed from the marketplace.

To ensure they are preserved and available for the OpenMage Project, we started a side Project. The OpenMage Module Fostering is an Archive of all the OpenSource Magento(1) Modules available via Magento Connect. But this will only be the first step. Having them all on Github, also allows managing the continuation of working on them through the community on a central place.

A Number: after skipping some modules with problems, we finally imported 2834 Modules.

This will also help to make them all compatible with the future PHP8 and solve security related issues of unmaintained modules.

You want support us in maintaining, get in contact with us on Github, Twitter or via Discord.

Also, tell us what else would you like to see happen?

You want to know more about how we managed to do this? Have fun reading through the Code of our Tooling. Keep an eye on it, we will continue to add Tooling, helping us to script changes for all the Modules at once.

Ein neues Zuhause für Magento Connect-Module

2019-08-18T00:00:00+00:00

Wesentliche Bestandteile des Magento Ökosystems sind der Marktplatz und die große Anzahl von Modulen für jeden Anwendungsfall. Aber mit dem Eol (End of Life) von Magento(1) ist zu erwarten, dass auch der Marktplatz von allen Magento(1)-Modulen gereinigt wird. Dies ist schon einmal vor einigen Jahren geschehen, als viele ältere Module vom Marktplatz entfernt wurden.

Um sicherzustellen, dass sie erhalten bleiben und für das OpenMage-Projekt verfügbar sind, haben wir ein Nebenprojekt gestartet. Das OpenMage Module Fostering ist ein Archiv aller OpenSource Magento(1)-Module, die über Magento Connect verfügbar sind. Dies wird jedoch nur der erste Schritt sein. Da sie alle auf Github verfügbar sind, kannst Du auch die Fortsetzung der Arbeit an ihnen durch die Community an einer zentralen Stelle verwalten.

Eine Zahl: Nachdem wir einige Module mit Problemen übersprungen hatten, haben wir schließlich 2834 Module importiert.

Dies wird auch dazu beitragen, sie alle mit dem zukünftigen PHP8 kompatibel zu machen und sicherheitsrelevante Probleme von nicht gewarteten Modulen zu lösen.

Wenn Du uns bei der Wartung unterstützen möchtest, nehme Kontakt mit uns auf Github, Twitter oder über Discord auf.

Sage uns auch, was Deiner Meinung nach noch geschehen soll.

Du möchtest mehr darüber erfahren, wie wir das geschafft haben? Viel Spaß beim Durchlesen des Codes über unser Tooling. Behalte es im Auge, wir werden weiterhin Tooling hinzufügen, das uns dabei hilft, Änderungen an allen Modulen auf einmal vorzunehmen.

Plan for the time after Magento 1 eol

2019-01-20T00:00:00+00:00

As you probably have already heard, the eol (End of life) for “Magento 1” is set to June 2020. (as announced here: https://magento.com/blog/magento-news/supporting-magento-1-through-june-2020 )

Already some time ago the OpenMage Project was started, to improve the bugfix situation for Magento 1, as even when a fix was already provided, they were often not integrated into official versions even years later. (this changed with Magento 2 a lot to the better)

This was only one of more than 5 forks I counted in the recent years(and there were probably even more). But it is the only one where a community formed around, and which got a wider range of users and contributors.

Lets talk some numbers, by now we are, and we have:

9 + 3 Maintainer (9 with Admin Privilege)
68 Code Contributors
146 direct Forks on Github
Over 200 merged Pull Requests
273 Stars on Github
~80 daily visitors on the Github Repository
110 Follower on Twitter ( https://twitter.com/OpenMageProject )

We structured the Project into several phases, oriented on the official Support status of M1.
We are currently in Phase 2.

Phase 1

When there was no official EOL set.

Keep a maximum on Backwards Compatibility to the official Release, to make it possible to switch without losing any features. Also no new Features.

We Focused on Bug and Performance fixes.

Phase 2

An EOL was set, and is slowly approaching.

We start to accept minor Backwards Compatibility breaks. Cleaning up the code from Parts which are not recommended to use anymore as they are outdated or even harmful.

Examples are the removal of the View Logging (this thing, which writes on every pageview to the database, and is for nearly all cases better replaced by Google Analytics), and the removal of the Compiler Feature (which in Magento1 is not needed anymore, since PHP brings its own OpCache)

Phase 3

Archiving a proper Continuous Integration Environment to archive enough stability to beeing able for bigger internal changes (we have some performance improvements in the pipeline for eav related database queries and the Index Process in general)

Also in this phase we will set up a proper Release Schedule. The current Plan is to have a stable Major release each January, which includes new Features and possible Backwards Compatibility breaks. Maybe one bugfix release per month. We will probably establish an LTS release every 2 or 4 years depending on what the users have more interest in. First LTS release is the current Magento 1 release, which we will continue to provide with bug fixes for at least 2 LTS releases and then decide depending on where we have how many users.

That said, we will work together with existing extension vendors to make sure a later major release of OpenMage will not cause major breaks

Phase 4

When we reach this phase, all our processes are stable enough to approach actual Feature development.

Some of this may involve a lighter default theme, which is less javascript heavy, performs better in the google pagespeed insights and more mobile friendly.

Also an auto updater like established with WordPress may be possible, to improve the situation for the Shops which do prefer to self host and try to keep the maintenance cost low.

Another big Point to keep in Mind is Security.

While we have through the community contact to some of the security researchers, this only helps to fix Issues, which got already found. We will also keep contact to hosting companies, which are good in tracking security issues which are already used in the wild.

But the best way to find security issues has proven to be bug bounties. As this requires a certain amount of money flow, the OpenMage Project will not be able to provide this part.

Luckily there are some people who took this part over and build a company around this security Topic. You can find and follow them at https://mage-one.com/

Some may wonder, why does the OpenMage Project try to compete with Magento.

The missed point here is, that Magento 2 did up its game by several levels, and with doing this, also their target audience. Magento 1 is able to perform quite well, and also the development speed is better than with Magento 2. But it does not scale well. Magento 2 is designed for way bigger Merchants and Projects, and to scale even further to match future needs which will come.

Therefore the overlap in potential target audience got quite small.

Magento2 is now suitable for big projects, which could never run on Magento 1, or only with very big adjustments. Therefore Magento 2 is no longer suitable for many small merchants or for self hosting. With Magento 1 a merchant was able to install it on a webspace without needing a developer. Magento 2 is even for a single developer sometimes hard to install properly.

OpenMage does not compete with Magento 2.

OpenMage is competing with solutions like Shopware, Sylius and Shopify.

OpenMage is for Companies, which for diverse reasons would not switch to Magento 2 anyway, but would consider to switch to one of the other Platforms. For them, OpenMage is the more cost efficient solution, as it only leads to the price of an update, not a replatforming.

Plane für die Zeit nach Magento 1 eol

2019-01-20T00:00:00+00:00

Wie Du wahrscheinlich schon gehört hast, ist das eol (End of life) für “Magento 1” auf Juni 2020 festgelegt (wie hier angekündigt: https://magento.com/blog/magento-news/supporting-magento-1-through-june-2020 ).

Bereits vor einiger Zeit wurde das OpenMage-Projekt gestartet, um die Bugfix-Situation für Magento 1 zu verbessern, denn selbst wenn bereits ein Fix zur Verfügung gestellt wurde, wurden sie oft noch Jahre später nicht in offizielle Versionen integriert. (Dies änderte sich mit Magento 2 sehr zum Besseren.)

Dies war nur einer von mehr als 5 Forks, die ich in den letzten Jahren gezählt habe (und es waren wahrscheinlich noch mehr). Aber es ist der einzige, um den sich eine Gemeinschaft gebildet hat, die ein breiteres Spektrum von Benutzern und Mitwirkenden hat.

Lasse uns über einige Zahlen sprechen, inzwischen sind wir und haben getan:

9 + 3 Betreuer (9 mit Admin-Privileg)
68 Code-Beitragende
146 direkte Forks auf Github
Über 200 zusammengeführte Pull-Anfragen
273 Sterne auf Github
~80 Besucher täglich auf dem Github-Repository
110 Follower auf Twitter ( https://twitter.com/OpenMageProject )

Wir strukturierten das Projekt in mehrere Phasen, die sich am offiziellen Unterstützungsstatus von M1 orientieren. Derzeit befinden wir uns in Phase 2.

Phase 1

Als es noch kein offizielles EOL gab:

Behalte ein Maximum an Rückwärtskompatibilität zum offiziellen Release bei, damit ein Wechsel ohne Verlust von Funktionen möglich ist. Es wurden auch keine neuen Features entwickelt.

Wir haben uns auf Bug- und Performance-Fixes konzentriert.

Phase 2

Ein EOL wurde angesetzt und nähert sich langsam:

Wir beginnen, kleinere Lücken bei der Rückwärtskompatibilität zu akzeptieren. Wir bereinigen den Code von Teilen, deren Verwendung nicht mehr empfohlen wird, da sie veraltet oder sogar schädlich sind.

Beispiele sind die Entfernung der View-Protokollierung (dieses Ding, das bei jedem Seitenaufruf in die Datenbank schreibt und in fast allen Fällen besser durch Google Analytics ersetzt wird) und die Entfernung des Compiler-Features (das in Magento1 nicht mehr benötigt wird, da PHP seinen eigenen OpCache mitbringt).

Phase 3

Archivierung einer geeigneten Umgebung für die kontinuierliche Integration, um genügend Stabilität für größere interne Änderungen zu gewährleisten (wir haben einige Leistungsverbesserungen für eav-bezogene Datenbankabfragen und den Index-Prozess im Allgemeinen in der Pipeline):

Auch in dieser Phase werden wir einen ordnungsgemäßen Veröffentlichungszeitplan aufstellen. Der aktuelle Plan sieht vor, jedes Jahr im Januar ein stabiles Major-Release herauszubringen, das neue Funktionen und mögliche Unterbrechungen der Rückwärtskompatibilität enthält, vielleicht eine Bugfix-Version pro Monat. Wir werden wahrscheinlich alle 2 oder 4 Jahre ein LTS-Release aufsetzen, je nachdem, woran die Benutzer mehr Interesse haben. Das erste LTS-Release ist das aktuelle Magento 1-Release, das wir weiterhin mit Fehlerbehebungen für mindestens 2 LTS-Releases versorgen und dann entscheiden werden, je nachdem, wo wir wie viele Benutzer haben.

Trotzdem werden wir mit den bestehenden Anbietern von Erweiterungen zusammenarbeiten, um sicherzustellen, dass eine spätere Hauptversion von OpenMage keine größeren Brüche verursacht.

Phase 4

Wenn wir diese Phase erreicht haben, sind alle unsere Prozesse stabil genug, um die tatsächliche Entwicklung von Features anzugehen.

Einige davon können ein leichteres Standard Theme beinhalten, das weniger Javascript-lastig ist, in den Google Pagespeed Insights besser abschneidet und mobilfunkfreundlicher ist.

Auch ein Auto-Updater, wie er mit WordPress etabliert wurde, könnte möglich sein, um die Situation für die Shops zu verbessern, die es vorziehen, selbst zu hosten und versuchen, die Wartungskosten niedrig zu halten.

Ein weiterer wichtiger Punkt, den man im Auge behalten sollte, ist die Sicherheit.

Wir haben zwar über die Gemeinschaft Kontakt zu einigen der Sicherheitsforscher, aber das hilft nur, Probleme zu beheben, die bereits gefunden wurden. Wir werden auch den Kontakt zu Hosting-Unternehmen aufrechterhalten, die gut darin sind, Sicherheitsprobleme aufzuspüren, die bereits im Internet auftreten.

Aber der beste Weg, Sicherheitsprobleme zu finden, sind erwiesenermaßen Bug-Bounties. Da dies einen gewissen Geldfluss erfordert, wird das OpenMage-Projekt diesen Teil nicht bereitstellen können.

Glücklicherweise gibt es einige Leute, die diesen Teil übernommen haben und eine Firma rund um dieses Sicherheitsthema aufbauen. Du kannst sie unter https://mage-one.com/ finden und verfolgen.

Manche mögen sich fragen, warum das OpenMage-Projekt versucht, mit Magento zu konkurrieren.

Der springende Punkt hier ist, dass Magento 2 sein Spiel um mehrere Stufen verbessert hat, und damit auch seine Zielgruppe. Magento 1 ist zwar recht leistungsfähig, und auch die Entwicklungsgeschwindigkeit ist besser als bei Magento 2, aber es skaliert nicht gut. Magento 2 ist für weitaus größere Händler und Projekte konzipiert und lässt sich noch weiter skalieren, um künftigen Anforderungen gerecht zu werden, die kommen werden.

Daher ist die Überschneidung in der potentiellen Zielgruppe recht gering.

Magento 2 eignet sich nun auch für große Projekte, die auf Magento 1 nie oder nur mit sehr großen Anpassungen laufen könnten. Daher eignet sich Magento 2 nicht mehr für viele kleine Händler oder für Self-Hosting. Mit Magento 1 konnte ein Händler es auf einem Webspace installieren, ohne einen Entwickler zu benötigen. Magento 2 ist selbst für einen einzelnen Entwickler manchmal schwer zu installieren.

OpenMage konkurriert nicht mit Magento 2.

OpenMage konkurriert mit Lösungen wie Shopware, Sylius und Shopify.

OpenMage ist für Unternehmen, die aus verschiedenen Gründen ohnehin nicht auf Magento 2 umsteigen würden, aber einen Wechsel auf eine der anderen Plattformen in Betracht ziehen würden. Für sie ist OpenMage die kosteneffizientere Lösung, da sie nur den Preis für ein Update, nicht aber für eine neue Plattform berechnet.