Software-update: Bolt 4.0

Na twee jaar van ontwikkeling is versie 4.0 van Bolt uitgekomen. Bolt is een opensource-contentmanagementsysteem en is daarmee in bepaalde opzichten vergelijkbaar met programma's als Wordpress en Drupal. Bolt is eenvoudig in gebruik, voor zowel installatie als beheer, heeft diverse goed uitziende templates die met Twig zijn aan te passen, en is geoptimaliseerd voor zowel desktop- als mobiele omgevingen.

In versie 4.0 is Bolt een volwaardige Symfony applicatie geworden. De redactie-omgeving is geheel vernieuwd en ondersteunt nu meertaligheid. Verder is er een keuze tussen verschillende content editors, zijn er collections, zoals we die kennen uit de Gutenberg editor in Wordpress, en is er een RESTful / GraphQL-api.

Bolt 4.0 released

We're happy to announce the release of Bolt 4.0, our Symfony-based CMS ! This release is the culmination of little over 2 years of hard work.

Bolt 4.0 has been officially released this week, bringing fruit to a two years long journey of extensive development. During that time, we asked questions, we learnt from previous successes and mistakes, and we rolled up our sleeves and wrote code. The result? A content management system that’s easy for web designers & developers, yet simple and powerful for content editors.

Versienummer	4.0
Releasestatus	Final
Besturingssystemen	Scripttaal
Website	Bolt CMS
Download	https://docs.bolt.cm/installation/installation
Licentietype	Voorwaarden (GNU/BSD/etc.)

Reacties (27)

[Maurits van Baerle]

Nu nog hopen dat er een goeie migratie tool komt van 3.7 naar 4.0. Er is zoveel veranderd dat ze voorlopig adviseren Bolt 4.0 alleen voor nieuwe projecten in te zetten.

[Reactie gewijzigd door Maurits van Baerle op 24 juli 2024 03:34]

[RoestVrijStaal]

Until that time, we advise to keep using Bolt 3 for existing websites (it'll keep working for the foreseeable future), and use Bolt 4 for new sites or when you're planning to do a full rebuild anyways.

Dit is....niet leren wat Wordpress, Joomla en Drupal (in het verleden) fout hadden gedaan

Door op hetzelfde moment van de release met een migratietool uit te komen, voorkom je dat je door je userbase verplicht wordt om oude versies te ondersteunen.

[BobdenO]

Dit is....niet leren wat Wordpress, Joomla en Drupal (in het verleden) fout hadden gedaan

Dat is iets te zwart-wit naar mijn mening. Zelfs als upgraden makkelijker zou zijn, dan nog zou het geen sier hebben als de oude versie niet meer ondersteund werd. Niet iedereen ziet daar de noodzaak van in ("maar, het werkt toch?") of heeft budget om de webdeveloper de migratie te laten doen.

[Reactie gewijzigd door BobdenO op 24 juli 2024 03:34]

[Maurits van Baerle]

Ik ga er vanuit dat het een capaciteitsding is. Alle dev tijd die je steekt in een migratietool kun je niet steken in het product zelf (en Bolt 4.0 is al later dan aanvankelijk gepland). Als ze nu (misschien na het verschijnen van een eerste release na 4.0 die dingen oplost die na het uitkomen aan het licht zijn gekomen) zich richten op een migratietool die in 90% van de gevallen voldoende is dan zijn ze denk ik nog aardig op tijd.

Ik vermoed dat de migratie van de content (tekst, plaatjes, taxonomie) nog niet zo ongewikkeld is maar skins en al het routeren van pagina's en dergelijke een stuk lastiger als er veel onder de motorkap veranderd is.

[Archcry]

Ik ben blij dat er nog ontwikkeld wordt aan dit systeem. Wordpress is natuurlijk veel dominanter in de markt maar ook hopeloos verouderd. Ik ben blij dat dit soort initiatieven een poging doen om te "concurreren" met wordpress en ik zou me bij bolt security wise toch wat beter voelen dan bij wordpress.

[Htbaa]

Waarom ben je van mening dan dat WordPress hopeloos verouderd is?

[-weenie-]

Ik denk dat hij bedoeld dat de code style compleet verouderd is. Hing/hangt vast met allemaal functies en hooks. Daar gebruik je tegenwoordig eventlisteners/subscribers voor.

[Archcry]

Nja als we even een boek over clean code lezen dan denk ik dat er toch wel wat inzichten op gedaan zijn door de jaren heen die we in Wordpress niet terug vinden. Denk hierbij bijvoorbeeld aan single responsibility. Wordpress maakt nog steeds gebruik van een grote functions.php van 7658 (!) regels lang. Daarnaast heb je dan ineens bestanden die midden in functies geladen worden omdat die de nodige tools bevatten die nodig zijn voor die methode. (zie bijvoorbeeld dit. Naast het feit dat er geen dependency injection framework gebruikt wordt wordt het concept dependency injection ook niet toegepast.

Dit zijn eventjes twee kleine maar voordehand liggende voorbeelden die me zo snel te binnen schieten maar er zijn natuurlijk nog veelk meer dingen die we tegenwoordig toch wel even wat anders zouden doen. Op een gegeven moment moet je gewoon accepteren dat een platform code technisch gewoon niet zo goed meer is en dat een nieuwe frisse wind misschien beter is.

[Htbaa]

Bedankt voor je toelichting! Dat onderbouwt je statement.

Ik heb geen ervaring met core WordPress programmeren, en dat wil ik ook niet :-). Wel bouw ik mijn websites er in en de nodige plugins. Op dat vlak vind ik WordPress prima werken met voldoende mogelijkheden dankzij de filters en hooks (in feite ook een event systeem). Aan de gebruikerskant werkt het ook allemaal prettig. Wel zitten er de nodige quirks in wat sommige dingen niet altijd even logisch maakt. Het versturen van een e-mail, en dan vooral het customizen, doe je door als een malle met filters allerhande dingen aan te passen voordat je een e-mail stuurt. En niet vergeten die weer te herstellen als je klaar bent :-).

Uiteindelijk is het een keuze die je maakt bij het door ontwikkelen van een pakket: begin je een keer helemaal opnieuw of borduur je voort op wat er is. Het ecosysteem achter WordPress is dusdanig groot dat Automattic het zich denk ik niet kan veroorloven om het huidige WordPress aan de kant te schuiven en iets nieuws te gaan maken. Ik denk dat hun enige optie is onderdeel voor onderdeel te refactoren met behoud van backwards compatibility. Want als dat laatste niet geboden wordt zal het een grote knauw krijgen.

[foppe-jan]

heel prettig werkend CMS, gebruik het nu een jaar of 4, bolt 4 (beta) sinds 3/4 jaar. Heel tevreden, ontwikkelaars reageren snel en vriendelijk op vragen, bugs, enz..

[evertalbers]

Ik heb mijn eerste project met Bolt 4 al live staan en ben er erg blij mee.
De Tweakers redactie heeft trouwens oude screenshots bij dit artikel getoond.

[BobdenO]

Pietluttige opmerking: De licentie is MIT, ipv GPL. :-)

[Maurits van Baerle]

@Drobanir kan dat aanpassen.

[Power2All]

Mwa, ik ben van Bolt naar OctoberCMS gestapt.
Die vind ik veel fijner tot nu toe.

[whetstone]

Waarom? Ik ben aan het kijken naar welk CMS te gaan gebruiken voor een eigen site, wil eigenlijk per definitie geen WordPress en dit Bolt ziet er best interessant uit. Maar hoor graag van een gebruiker/kenner waarom OctoberCMS (dat ik nog niet kende) beter is.

[sfranken]

Ik heb beide een tijdje gedraaid. Bolt vond ik niet echt lekker werken, maar dat was nog de 3.x versie. OctoberCMS voelde voor mij aan als 'net niet af', omdat je met de GUI niet alles kunt doen wat je voor een site wilt doen, zoals content maken van een nieuw type.

Ik ben nu zeer tevreden over Processwire

[Power2All]

Mwa, ik kan er alles mee tot nu toe.
Eigen modules schrijven is super simpel, routing en alles.
Werkt anders helemaal top, met Bootstrap, en API restful.
Maar mijn nieuwe site die ik aan het maken ben zal gewoon weer puur Laravel worden met API, de site puur statisch met JS werken.

Ik checkte die Processwire van je, en het eerste wat ik dacht was: Gadver.
Ze gebruiken HTML in PHP, dat is echt niet meer van deze tijd man...

[Reactie gewijzigd door Power2All op 24 juli 2024 03:34]

[sfranken]

Juist daarom bevalt OctoberCMS me niet zo. Het is maar een dun sausje over Laravel heen, doe het dan goed zonder dat sausje, want de GUI van OctoberCMS (laatste keer dat ik ernaar keek) bood net te weinig om er écht wat mee te kunnen.

Ze gebruiken HTML in PHP, dat is echt niet meer van deze tijd man...

Even zonder gekheid, maar wat denk jij dat Smarty, Twig of Blade is? Dat is feitelijk niks meer dan een vertaallaag bovenop PHP. Eindresultaat is hetzelfde. Ja, ik weet dat het niet meer van deze tijd is, maar voor een beetje programmeur maakt het in mijn ogen weinig uit.

[Power2All]

Twig en Blade zijn juist bedoelt om niet je PHP te vervuilen met HTML.
Daarnaast, kun je beter gewoon arrays e.d. aan data geven aan Twig/Blade om dat te genereren.
Als je content wilt weergeven, kun je bijvoorbeeld beter weer MarkDown language gebruken.

HTML in PHP is gewoon not-done, elke PHP programmeur zal je uitlachen.
Maar als jij dat helemaal prima vind, niemand houdt je tegen, maar HTML in PHP is gewoon, not done

[sfranken]

Ik weet dat het not done is, en ik doe het zelf verder ook niet. Het is een punt wat ik heb aangegeven bij de developers van Processwire.

Mij ging het om het feit dat iedereen zich blindstaart daarop, en zich niet lijkt te beseffen dat het eigelijk overkill is. PHP is tenslotten bedoeld/gebouwd om dit te doen, een webpagina (of -site) maken. Dat we in de 20+ jaar daarna andere eisen zijn gaan stellen is heel logisch en goed, maar het veranderd niets aan het feit dat PHP hiervoor bedoeld is, hoe diep dat ook weggezakt mag zijn de laatste jaren ;-)

Punt is: niet blindelings meegaan met elke trend, maar soms mag je best even kritisch zijn en even verder kijken dan je neus lang is. Ik heb het meegemaakt dat de "gerespecteerde" programmeurs HTML en PHP gewoon mixte, daarna kwam het MVC patroon op en moest alles los en uitgebreid, en werd PHP langzaam een behoorlijke programmeertaal. Wederom, niks mis mee, maar vergeet je roots niet.

[Power2All]

maar het veranderd niets aan het feit dat PHP hiervoor bedoeld is

Programmeer talen zijn door iets altijd ontstaan.
PHP was een manier om je websites meer leven in te kunnen blazen, zonder gebruik te hoeven te maken van ingewikkelde omgevingen zoals CGI e.d., wat voor veel mensen destijds gewoon heel moeilijk was.

Symfony, Laravel, etc... zijn allemaal frameworks om juist het programmeren kwa code te verminderen en te vergemakkelijken. PHP en HTML was het idee om sowieso al los te trekken, dat is een van de redenen waarom er template engines ontstonden, om code van render data te scheiden. Het gebeurde langzaam, maar uiteindelijk ziet de PHP code in vergelijking met de HTML code, er een stukken beter op. Het is gewoon voor de meeste programmeurs (die ik ken dan, in de prive en werk omgeving) een crime als die PHP en HTML door elkaar zien, en veel te veel code op een enkele locatie zien, zonder correct gebruik te maken van classes, functies, namespaces, etc... Als ik daar iemand op betrap, dan spreek ik die persoon hierop aan om zich aan te passen aan deze werk-stijl, ik wordt ook soms terug gefloten als ik iets te veel code schrijf, dan wat er noodzakelijk is.

[Reactie gewijzigd door Power2All op 24 juli 2024 03:34]

[sfranken]

Dat vind ik dan weer redelijk extreem. Dat is, in mijn ogen, echt teveel meegaan met welke wind er dan ook waait. Je moet je product maken zodat het inderdaad goed is (rekening houden met alle best practices e.d), maar iemand "terugfluiten omdat hij/zij te veel code schrijft" is in mijn ogen toch echt wel een brug te ver

[Power2All]

Mwa, als jij code schrijft van 4 pagina's, wat eigenlijk met een simpele systeem gedaan kan worden via 1 commando (DirectX vs SDL), dan vind ik wel dat er waarheid in ligt.
Teveel code kan je source onoverzichtelijk maken, dus als je dat kan opsplitsen, of kan vereenvoudigen, maakt dat voor jou, en andere programmeurs de code handelbaar.

[jaapvisser]

Bolt ziet er op het eerste gezicht heel solide en logisch uit. Ik ga er een website in optrekken om te beoordelen of het systeem me bevalt. Twill.io (Laravel based) heb ik ook op mijn netvlies maar nog niet voldoende onderzocht.

In het verleden heb ik verschillende themes en modules geschreven in OctoberCMS mijn redacteuren vinden dit systeem niet heel handig, voor developers werkt het wel heel snel. OctoberCMS is gebouwd op Laravel maar heeft wat eigen conventies en niet blade maar twig als template taal (vind ik geen nadeel). Gebruiksvriendelijkheid vanuit eindgebruikers perspectief is wel een dealbreaker.

Pros van Bolt:
- packages en dependencies via composer
- symfony framework
- makkelijk om themes the ontwikkelen, twig is eenvoudig
- hybride cms kan ook als api of headless cms ingezet worden
- uitbreidbaarheid en module ontwikkeling moet ik nog onderzoeken, het lijkt erop dat er niet veel modules geschreven hoeven worden fieldtypes vangen dit grotendeels af.

[Reactie gewijzigd door jaapvisser op 24 juli 2024 03:34]

[Power2All]

Apart dat jou bericht +2 krijgt, terwijl ik juist datzelfde aangeef, en compleet de grond in geboord wordt.
OctoberCMS is top inderdaad, BOLT heb ik ook geprobeerd, maar het werkte voor mij te onhandig.

[jaapvisser]

Ik vind OctoberCMS goed werken (vooral vanuit ontwikkelaars perspectief Themes en Module ontwikkeling). Mijn eindgebruikers (redacteuren) vinden OctoberCMS niet prettig werken.

Een gebruiksvriendelijk CMS neer te zetten voor designers, ontwikkelaars en redacteuren is exact de focus van BoltCM en daarom spreekt het me aan.

De eerste test voor mij is een website ontwikkelen (het systeem beter te leren kennen en onder de motorkap te kijken), deze vervolgens aan redacteuren over te dragen. Wellicht moet de redacteuren alvast een demo met de standaard 2020 theme van Bolt geven.

OctoberCMS werkt goed met modules, de database structuur van opgeslagen data is erg schoon. Ik ben heel benieuwd of dit bij Bolt ook het geval is. Ik ben wat allergisch voor systemen (CraftCMS bijvoorbeeld) die voor alle veldtypes en data attributen complexe tabelstructuren gebruiken. Dit kan het schrijven van queries lastig maken of maakt dat het werken met data alleen via een API kan.

Voor redacteuren zijn context switches tussen verschillende modules soms wat lastig. Voor een nieuws, blog, kalender of produkten module is dit niet zo'n probleem. Voor het vullen van pagina's kan de redacteur verward raken als hij/zij heel veel verschillende modules langs moet om een elementen op een pagina te bewerken. Ik denk dat context switchen zullen verminderen als slim gebruik wordt gemaakt van Redactor (Bolt). Bij October vind ik het werken binnen pagina's wat stroef en onhandig.

Zover ik weet kent October geen Redactor / Streamfield editor.

Het feit dat Bolt een Nederlands tintje heeft en een goed werkende open source community heeft vind ik ook een aanbeveling. Niet dat OctoberCMS dat niet heeft maar altijd oppassen voor open source producten bestuurd vanuit een ivoren-toren.

Wel eens van open source gebruik gemaakt waarbij alle beslissingen intern genomen werden en participatie (PR's / FR's / Feedback) op geen enkele manier mogelijk was, clonen is dan je enige oplossing.

Er zal geen enkel CMS zijn wat helemaal perfect werkt en aan alle eisen voldoet. Bottomline: OctoberCMS is een goed CMS, Bolt lijkt op het eerste gezicht iets meer voordelen te bieden. Ze hebben beide een levendige open source community, over een paar weken kan ik vertellen of Bolt werkelijk beter is.

[Reactie gewijzigd door jaapvisser op 24 juli 2024 03:34]

[jaapvisser]

Inmiddels zijn de +2's al weer verdwenen weet niet hoe het rating-systeem hier werkt en/of tweakers or gebruikers dit manipuleren, maakt ook niet uit. Kijk hoe populair een systeem is maar ga vooral af op eigen ervaringen niet op een + of - meer op Tweakers.

[Reactie gewijzigd door jaapvisser op 24 juli 2024 03:34]