Het gedateerde systeem dat men Magento noemt

Adobe's Toekomstvisie op Magento:

• Geen plannen om de Open Source versie te degraderen, maar onduidelijkheid over de duur van de ondersteuning door Adobe.
• Commerce verschuift volledig naar SaaS. Aanpassingen zijn alleen mogelijk via de API met Adobe's ontwikkeltools.
• Introductie van een nieuw product: Commerce on Experience Cloud. De zelf gehoste versie behoudt de huidige functionaliteiten, maar nieuwe functies komen alleen naar de Experience Cloud-versie.
• De bestaande codebase ontvangt alleen nog beveiligings- en bugfixes.
• Open Source wordt overgedragen aan de Magento Association, effectief de gemeenschap.
• Commerce-functionaliteit kan worden aangepast via Adobe IO, waarbij de kern schoon blijft voor SaaS-upgrades.
• Geen plannen voor de toekomst van Luma binnen Commerce on Experience Cloud.

Implicaties voor Magento 2:
De focus van Adobe ligt duidelijk op het verplaatsen van Commerce naar een SaaS-aanbod, terwijl Open Source slechts een bijzaak lijkt te zijn. Deze verschuiving roept vragen op over de toekomst van Magento 2.

Magento 2, ooit een krachtige speler in de e-commerce wereld, wordt nu gezien als een verouderde oplossing. In het tijdperk van digitale transformatie zijn flexibiliteit en aanpasbaarheid cruciaal. Magento 2's verouderde technologie stack, zoals Zend Framework 1 en Prototype JS, maakt het minder geschikt voor moderne e-commerce projecten. Bedrijven zoals Netflix en Tesla geven de voorkeur aan meer hedendaagse platforms zoals Shopify.

De Beperkingen van Magento 2:
Het monolithische ontwerp van Magento 2 en Adobe Commerce wordt gezien als een belemmering voor innovatie en flexibiliteit. Het vereist kostbare aanpassingen en onderhoud, waardoor het moeilijk is om snel te reageren op veranderingen in de markt of bedrijfsprocessen.

Daarnaast brengt het gebruik van verouderde software risico's met zich mee op het gebied van beveiliging. Recente exploits in Magento 2 zijn hier een duidelijk voorbeeld van.

De Noodzaak van Verandering:
In een tijd waarin digitale transformatie centraal staat, is het essentieel voor bedrijven om agile en flexibel te zijn. Kleinschaligere, cloudgebaseerde e-commerce oplossingen bieden meer integratiemogelijkheden en flexibiliteit. Platforms zoals Shopify en BigCommerce bieden moderne, schaalbare oplossingen die beter aansluiten bij de behoeften van hedendaagse bedrijven.

Conclusie:
Magento 2 kan nu als verouderd worden beschouwd, met beperkingen op het gebied van flexibiliteit, aanpasbaarheid en beveiliging. Bedrijven die op zoek zijn naar een toekomstbestendige e-commerce oplossing zouden moeten overwegen om te migreren naar meer moderne platforms. De verschuiving van Adobe naar een SaaS-georiënteerde strategie benadrukt de noodzaak voor bedrijven om hun e-commerce platformkeuzes te heroverwegen en te kiezen voor oplossingen die beter zijn afgestemd op de eisen van de moderne digitale economie.

 

Waarom Magento niet meer van deze tijd is?

Geschreven door: A. Cynic

Ik heb de onderhoudstaken overgenomen voor een winkelwebsite die wordt aangedreven door een open-source PHP-software genaamd Magento. (Magento is een paar jaar geleden door Adobe gekocht en ze bieden waarde toevoegende commerciële en gehoste versies genaamd Adobe Commerce). Volgens de marketingtekst is "Magento een rijk eCommerce-platform dat handelaren volledige flexibiliteit en controle biedt over de functionaliteit van hun online kanaal. Magento's zoekmachineoptimalisatie, catalogusbeheer en krachtige marketingtools geven handelaren de mogelijkheid om sites te creëren die een ongeëvenaarde winkelervaring bieden voor hun klanten." En volgens Wikipedia, "Zijn er meer dan 100.000 online winkels gemaakt op dit platform. De platformcode is meer dan 2,5 miljoen keer gedownload en er is voor $155 miljard aan goederen verkocht via Magento-systemen in 2019. Twee jaar geleden vertegenwoordigde Magento ongeveer 30% van het totale marktaandeel."

 

Soms denk ik dat ik Magento haat omdat het zo overdreven complex, traag, resource-intensief en arm aan functies maar overvol met overbodige functies is dat alleen Adobe erin geïnteresseerd zou zijn. Dan denk ik aan de arme mensen die me betalen om het te onderhouden en extensies voor te schrijven.

— Reactie gezien op Hacker News

 

Ik heb nu de tijd gehad om met deze Magento-site te werken vanuit verschillende perspectieven gedurende enkele jaren (inclusief een minder soepele migratie van Magento 1.9 naar Magento 2.3) - als consultant die productgegevens beheert via de Admin-interface, als systeembeheerder die een Magento-gebaseerde site implementeert en host, als ontwikkelaar die kleine wijzigingen en fixes maakt zoals nodig door mijn klant, als gebruiker van de klantgerichte site - en het heeft me voortdurend onder de indruk gebracht: ik heb nog nooit eerder software gebruikt die zo'n slechte ervaring biedt aan beheerders, ontwikkelaars en gebruikers.

Mijn verwachtingen

Waar ik een eCommerce-framework zou verwachten dat een eenvoudige frontend-interface biedt die basiswinkelwagenfunctionaliteit implementeert als startpunt om op voort te bouwen, biedt Magento een standaardthema met een productbeschrijvingspagina die meer dan 4 MB aan HTML/CSS/JS aanvraagt, inclusief meer dan 200 JavaScript-bestanden (echt waar). Het aanpassen van het thema, net als alle Magento-aanpassingen (zie hieronder), is onredelijk ingewikkeld. Voor zover ik kan zien, is de enige verstandige manier om een prestatiegerichte en onderhoudbare Magento-website te hebben, door een volledige frontend te schrijven met een modern framework en uitsluitend met Magento te communiceren via zijn REST API. In feite lijkt de algemene regel voor succesvolle Magento-implementatie te zijn om zo min mogelijk van Magento te gebruiken.

Waar ik een catalogusbeheerinterface zou verwachten met de nadruk op het importeren en exporteren van productgegevens, biedt Magento een pijnlijk trage productbrowser en editor om copywriters te kwellen en een zwakke en ingewikkelde productexporttool die ongeschikt is voor enige echte rapportage of feedgeneratie. Mijn oplossing de laatste tijd is om programma's te schrijven die gegevens uit de REST API halen om rapporten in Google Sheets bij te werken in plaats van te proberen de Admin-panel te gebruiken of uit te breiden. (De productimporttool van Magento is prima.)

Waar ik een "rijk eCommerce-platform dat handelaren volledige flexibiliteit en controle biedt over de functionaliteit van hun online kanaal" zou verwachten met een ergonomische en goed gedocumenteerde extensie-interface, biedt Magento een over-ontworpen en ingewikkeld plug-insysteem bedraad met XML-bestanden (met weinig referentiedocumentatie) en PHP-code gegenereerd uit klassen die je levert, die interageren met de kernsysteemklassen (die geen referentiedocumentatie hebben).

Waar ik bij het moreel dubieuze kruispunt van een commercieel online retailplatform dat nauwelijks uit de doos werkt, preoccupatie met marketing en "SEO", en de uitbuiting van arbeid door programmeurs in ontwikkelingslanden (inclusief onder het mom van "open source") een ecosysteem van commerciële plugins zou verwachten die zowel duur als riskant zijn om te installeren, levert Magento. Dus als de basisinstallatie van Magento te stabiel, veilig en goedkoop voor je lijkt, kun je altijd naar de Magento Marketplace gaan en elke extensie vinden die je nodig hebt, geschreven door softwareontwikkelaars die hun carrièrekeuzes in twijfel trekken.

 

Meer vraagtekens in plaats van minder

Ik bedoel niet het harde werk van de open-source bijdragers te kleineren die hebben geholpen Magento te creëren. Sterker nog, hoewel ik niet begrijp wat hen motiveert, bewonder ik op sommige manieren de pure volharding en zelfontkenning die het moet kosten om tijd te blijven besteden aan zo'n project. Van wat ik kan zien door GitHub en de Magento StackExchange te browsen (wat - en ik weet dat dit overdreven klinkt - waarschijnlijk de slechtste StackExchange-site is die ik heb gezien), zijn veel ontwikkelaars Indiaas of werken ze buiten Noord-Amerika, dus ik gok dat de kwetsbaarheid van Magento heeft gezorgd voor vraag naar betaalbare PHP-ontwikkelaars. En ik weet dat het een soort gebroken ramen-valstrik is, maar als de ingewikkelde architectuur van Magento enige betaalde klussen of baanzekerheid kan bieden aan die ontwikkelaars, denk ik dat dat op zijn minst iets positiefs is.

Ik denk dat de meeste problemen van Magento - inclusief de slechte prestaties, slechte beveiligingsgeschiedenis en hoge kosten om aan te passen en te onderhouden - voortkomen uit twee kerngebreken: een gebrek aan documentatie en een fundamenteel gebrekkige softwarearchitectuur.

Als Magento goede documentatie had, dan zouden ontwikkelaars bijna ongeacht hoe verschrikkelijk het ontwerp is, in staat zijn om het te laten doen wat ze nodig hebben. Nu is de organisatie van de documentatie verbeterd sinds Adobe het heeft overgenomen (zie https://devdocs.magento.com/). Maar vanuit het perspectief van een PHP-ontwikkelaar is wat gedocumenteerd is ernstig tekortschietend. Veel voornamelijk nutteloze beschrijvingen op hoog niveau, een paar codevoorbeelden, maar geen echte documentatie van de Magento-broncode en de klassen/interfaces die het biedt.

In tegenstelling tot de documentatie, die Adobe zou kunnen verbeteren als ze erom gaven (maar als ze dat deden, denk ik dat ze dat al zouden hebben gedaan), kan de architectuur van Magento zelfs niet worden gerepareerd. Het hele framework is gebaseerd op ingewikkelde (wat de afwezigheid van documentatie harder laat aankomen) XML-configuratiebestanden en een dynamisch afhankelijkheidsinjectiesysteem. De manier waarop het werkt, is dat plugins afhankelijkheden op PHP-interfaces verklaren en vervolgens de Magento-codegenerator (de bin/magento setup:di:compile-opdracht) genereert de daadwerkelijke plugincode met de geïnstantieerde afhankelijkheden. Het is het soort overkill-systeem dat grote enterprise Java-applicaties, ontwikkeld door teams die een statisch getypeerde taal met uitstekende tools gebruiken, moeilijk maakt om over na te denken en te onderhouden; om die architectuur te adopteren voor een PHP-winkelwagentje-applicatie is totale waanzin.

Tijd is geld

Ik heb niet de tijd genomen om zijn prestatieknelpunten te onderzoeken, en ik hoop dat ik dat nooit hoef te doen, maar de gegenereerde PHP-code die een dergelijk dynamisch plug-insysteem ondersteunt, draagt ​​ongetwijfeld bij aan hoe traag Magento is. En Magento is traag. Achter een asynchrone omgekeerde proxy op een overgedimensioneerde ec2-instantie, ben ik er vrij zeker van dat de website van mijn klant kan worden DoS-aangevallen door elke ondeugende tiener met een kabelmodem als het niet voor Cloudflare was. Zelfs met de firewall van Cloudflare kan een enkele kwaadwillende bot de site vertragen tot een kruip.

De 'oplossing' die Magento biedt voor zijn prestatieproblemen is steeds meer lagen cache. Eerst moet de beheerder statische bestanden (CSS, etc.) genereren met de bin/magento setup:static-content:deploy-opdracht. Vervolgens is er een cachesysteem voor verschillende gegevens die Magento berekent en die vaak, onverklaarbaar, handmatig moeten worden vernieuwd. Maar het is nog steeds traag, dus wordt meestal aanbevolen dat je Magento ook uitvoert achter een cache-omgekeerde proxy zoals Varnish en/of een toegewijde key-value-cache gebaseerd op Redis. Het zou grappig zijn als het geen echte software was die ik moet onderhouden.

Erger nog, de onnodige complexiteit maakt het moeilijker om zowel code-uitvoeringspaden te begrijpen als wijzigingen aan de codebasis aan te brengen: een recept voor beveiligingskwetsbaarheden.

Vergeet de pluspunten niet!

Er zijn enkele goede dingen aan Magento, natuurlijk. Zijn enige redding, naar mijn mening, is zijn Swagger-gebaseerde REST API waarmee de meeste vereiste functionaliteit buiten Magento zelf kan worden geïmplementeerd. En Swagger/OpenAPI is zelfdocumenterend, dus de Magento-ontwikkelaars kunnen het niet zo moeilijk maken als ze de PHP API hebben gemaakt. Maar zelfs dat is een bron van lijden geweest. In feite is mijn belangrijkste gebruiksscenario ervoor, rapportage over de huidige voorraadhoeveelheid voor alle producten, standaard niet eens mogelijk omdat het /V1/products-eindpunt geen voorraadinformatie retourneert ondanks wat de documentatie beweert. Die bug is meerdere keren gemeld (bijv. #24418), maar het antwoord van de beheerders is dat de juiste manier om voorraadinformatie te krijgen is om een ​​oproep te doen naar /V1/products en vervolgens een extra http-verzoek te doen voor elk geretourneerd product (duizenden of tienduizenden in mijn geval). (Gelukkig zijn er enkele workarounds. Ik schreef cristoper/mage_qtyext, een zeer eenvoudige plugin die een "qty" -veld toevoegt aan de productresultaten; ik vond ook menacoders/Stock-Info-API-searchCriteria die alle voorraadinformatie aan de resultaten toevoegt.) Er zijn ook SOAP- en GraphQL-API's die ik niet heb onderzocht (behalve om erachter te komen dat de GraphQL API standaard ook geen manier biedt om voorraadinformatie te krijgen voor de gehele voorraad).

Al dat gezegd hebbende ..

Persoonlijk confronteert het vooruitzicht om oplossingen te ontwikkelen voor mijn Magento-gebonden klant me als een deprimerende tijdverspilling. Ik ben ervan overtuigd dat Magento nooit iets anders zal zijn dan duur om te onderhouden, traag en onveilig. Ik raad het niet aan voor nieuwe projecten.

Bron: https://catswhisker.xyz/log/2021/8/22/magento_sucks/

 

---

 

Wat vinden wij?

Het klopt dat magento eigenlijk niet meer met de tijd meekan en alle bovengenoemde zaken kunnen we ons wel in vinden, dat neemt niet weg dat wij goed bekend zijn met Magento.

Wat vooral ontzettend jammer is, is dat Magento eigenlijk momenteel het enige systeem is wat echt 'open-source' kan worden gebruikt(tot op zekere hoogte). De installatie is relatief gemakkelijk op te zetten, en als het draait is het een kwestie van je portemonee trekken en extensies aanschaffen.

Wij hebben gekeken naar welke andere open-source (php)e-commerce systemen er zijn voor het realiseren van een goede SEO pro, solide, OOP en clean webshop. En tot onze verbazing blijken er dat niet zo heel veel mogerlijkheden zijn. Wij waren in de veronderstelling dat er nu anno 2024 veel systemen zijn die als alternatief kunnen worden gebruikt. Het tegendeel blijkt waar.

Het klopt dat de hoogtijd jaren van Magento voorbij zijn, maar wat zijn dan de alternatieven?

---

Wij hebben een aantal open-source alternativen gevonden die ter vervanging voor Magento. Deze hebben wij lokaal geinstalleerd en getest of het kan kwalificeren ter vervanging van.

Heb je veel maatwerk en koppelingen met verschillende system is het raadzaam, eerst alle koppelingen voor jezelf op te sommen of deze compatible zijn met je potentieel nieuwe E-commerce oplossing. Zo niet, zoek een partij die echt weten wat ze doen, dmv bewezen technieken, bekijk hun portfolio en ga langs voor een persoonlijk gesprek. Ga niet uit op de mooie blauwe ogen maar doe echt zelf onderzoek of deze partij geschikt is voor hetgeen wat je wilt. Anders kan het zo zijn je na 2 jaar nog geen systeem hebt wat doet wat het moet.

Php e-commerce

Microweber - Microweber is an open-source content management system (CMS) and website builder that allows users to create and manage websites and online stores. It is known for its user-friendly, drag-and-drop interface, which makes it easy for individuals and businesses to build and customize websites without requiring extensive technical knowledge.

Litecart - Ongelooflijk snelle webwinkel software - LiteCart e-commerce platform gebouwd met PHP, jQuery and HTML 5.

OpenCart - The best FREE and open-source eCommerce platform. Everything you need to create, scale and run your business

Woocommerce - WooCommerce is the platform that grows with you. No matter what success looks like for you, you can do it with WooCommerce. Our WordPress-based ecommerce platform helps merchants and developers build successful businesses for the long term.

Laravel e-commerce

Lunar - Storefront Flexibility. Freedom to build what you need. Lunar’s headless approach to e-commerce gives you the freedom to build the best user experience for your customers.

Bagisto - An Open source Laravel eCommerce platform for building marketplaces, mobile apps, blockchain and headless commerce, powered by Generative AI.

Overige E-Commerce

Er is zeker meer dan alleen Magento, onderstaand een 2-tal links met veel verschillede E-commerce systemen en meer!

CMS guide - https://cmsguide.info/directory/ecommerce

Github - https://github.com/topics/ecommerce-platform