Dolibarr is using 2005 PHP code, in 2018

[ChangePlaces]

I'm completely new to Dolibarr, I've just spent some time looking at the core code of 8. There are a number of major issues which render Dolibarr unusable and unmaintable in 2018. This is not a "modern" ERP / CRM.

• SQL code and template code and logic are thrown together. This is a fundametal no-no since... about 2005
• Use a template system, They're a big thing for a reason. They need to be used. This will allow people to develop skins 100x more easily, which will put more themes in the marketplace etc
• As horrid as it may seem to French people, English is the global language. Directories, comments and variable names need to use it as you're not coding for yourself. Even dolistore should have English as the first language.
• There are many problems that have already been solved by external libraries, this is what composer is for
• Not having any symfony components is a bit of an issue - all worthy PHP projects are using Symfony components because they work. Not to be cool. They have a large community base actively working on solving specific problems and trying to solve them yourself just isn't cool anymore.
• Modules need a separate directory to be put in. I don't think anyone wants to copy third-party code into the project root due to malicious code overwriting core system files.
• A router is needed so all code is handled from one file, to stop code duplication and to enable controllers to handle grouped functionality in one place (making the codebase instantly understandable)

Yes, this will need major refactoring, I'm sure it'll also mean people will have to learn new skills, but to be honest, Dolibarr is not a modern codebase. I'd love to help contribute to Dolibarr, but I simply can't advocate putting code in the htdocs, something I haven't done since about 2005

I understand I'm going to be shot down for this, probably even have this closed / deleted but I have written this and have taken time to contribute to the Dolibarr project. I would like to contribute though, just not to the current spaghetti code

[torvista]

No doubt the developers are fully aware of modern methods and don't need someone to explain what is needed. Dolibarr is what it is. A legacy project with a long history and the inevitable historical baggage that comes with it's roots as a french project. Major architecture changes mean major disruption for users on upgrades and so must be managed very slowly. As far as I have seen, most users are really just users and do not modify much, judging by the few contributors here. So, architecture changes that don't improve functionality would seem pointlessly disruptive. Dolibarr is not perfect by a very long way, but as far as I have found, it has greater functionality than similar projects, and if it doesn't, I can modify it relatively easily with my limited php knowledge. In the end, the functionality is what matters to 100% of the people. If it works but is messy underneath the hood, that matters only to the very small percentage who need to go there, me included.

The facts are that in 2018 Dolibarr is being used and is being maintained, so that detracts from your otherwise valid comment.

I would have preferred to invest my time and contributions in something more modern too, but my skills are limited and I have found nothing better that worked out-of-the-box.

[mwelters]

@torvista Totally agree ! I also searched other projects for usability and decided for dolibarr BECAUSE it is functional and the code is easy to understand.

@ChangePlaces This is Opensource ! Fork it and show us a way to the enlightment of object-oriented modern component based Programming !

[dolibarr95]

Hi all!

8171 #6198 #2868

Welcome @ChangePlaces (sincerely)! If you have ideas/suggestion just make a PR. Dolibarr have been created by french users, so of course there is some french. But as you see we try to speek english (google translate helps lol). There are dolibarr forum in other langages.

[ChangePlaces]

@dolibarr95 hi, most of the videos I've been watching on youtube have been in french and I've relied on the broken auto-translated subtitles youtube provides! It's do-able, but is still a barrier to learning and importantly understanding dolibarr. I see the drive to get a course created for dolibarr which is a great idea, but will this be a good idea as it'll get more critical eyes on the codebase which could point out the same things and drive people away from dolibarr?

@mwelters But here's the problem - why would anyone want to fork the code, when it's going to need completely re-writing and re-structuring from the start? It would need too much work for it to be a fork!

I would love to make a PR, but everything would need changing - I don't have enough dolibarr system knowledge to even begin and as I'm a consumer on the search for an ERP which will need lots of additional code changes I would not feel confident using dolibarr as a long-term strategy.

It works for some people who want to make a change here, a change there, but that's only a small part of an audience. Business processes are unique to every company and it'd be nice if dolibarr could accommodate this.

[torvista]

I understand that investing time building your custom code on top of a codebase that you are not happy with, seems a bad idea. But one has to look in detail at the project as is (i.e. the develop version, not the released version) and evaluate how much it is really lacking from what you actually need, and balance that against spending much more time on a better-designed ERP that needs a lot more work to get to the same point. After much research several times over the last five years, I came to the conclusion that Tryton was the best, but I don't have the time or inclination to learn and modify it, when I already am competent with php/mysql from working with my online shop. One has to factor in the time and effort required to get to the end-point of production-ready code.

Dolibarr does not need a course to learn how to use it. If it did, the GUI needs to be fixed to solve that. Every time I have found something poorly explained, I have updated the language file...to aid my employees, and updated the wiki where appropriate.

[PMickael]

I'm totally agree with @ChangePlaces , I also open a issue a few weeks ago about commits, the first things to begin with, it to make a real commit usage, it's a not CTRL+S shortcut, you need to think of what you do, and more-ever fix things over the time, I update some part of the code for my own needs, and new updates introduce new code problem/syntax, like as simple as choice between space and tabs which is actually a random pick depends of the weather of the day 😄

And I think there is a big gap between users versions, I tried to stay as much as possible to the latest version, but it's really complicated because I don't have the time to look at all this random commits to see if I will not break like VAT module which was not working properly in ~6.0 => ~7.?.? and fixed now (I think, I don't test all the case)

All the problems point to commit usage, it's not possible to make a code review if things are not correctly commit.

[Thunderstr1k3]

Cheerio folks, I just stumbled across this thread. I totally agree with @ChangePlaces. Dolibarr has a great usability on its surface, but as a matter of fact, it lacks features - just like any other ERP System. As a software developer I tend to write necessary lines, but french code is a show stopper. Though I had french in school for almost a decade it is impossible to read the code fluently as one has to switch between languages every few seconds. Seriously, being french is nice and all but no excuse for a messed-up code.

Since I really like how dolibarr is designed, I would volunteer for assistance. @ChangePlaces Shall we? Anyone else?

[nielsdrost7]

I'm currently helping to get an invoicing application into a new version (PHP of course), but I could help with this application as well, maybe even intregrate invoicing into Dolibarr. When everyone agrees on development environment, coding standards (phpcs), I'll help where I can, just ping me (set up a slack channel, would help)

[cfoellmann]

I am also evaluating ERPs at the moment and on the surface dolibarr looks very promising to me but I definitely need to add some extensions. A bad codebase will cost me more time and my firm more money. But if the project leads are on board with evolution of the codebase like: consistent coding standards and replacement of French with English "code"; I might be able to sell the project to my bosses

@nielsdrost7 👍 coding standards (phpcs) 👍 slack (or sth similar)

[nielsdrost7]

So I've created an organisation : dolimodern. i've committed 4 repo's:

• docker-dolibarr (and docker-doli which is a fork of someone's docker-setup for dolibarr)
• original dolibarr
• modern dolibarr built with laravel and split into modules. View files are set up, controllers need to point to the view files. If you guys want to build things in Symfony, you're more than welcome to grab the view files (blade templates). They're basically just html, since this is the very beginning of transferring Dolibarr to a more modern setup

[UnderDogg]

@ChangePlaces @cfoellmann on my local PC i've converted the database into something workable. I've generated models, views, controllers, migrations, seeders (using factories) I'm willing to convert it onto a laravel project if you guys really want to.

I can't do things and then find out that you guys want to make the new version with Symfony. I 'very added you both to the organisation, so you can edit all those repositories and make commits to them @Thunderstr1k3 I added you as well (invited)

[BebZ]

Hello, just a "noob" question : What makes you think Dolibarr code or fuctionnalities are better than other ones like TinyErp, Axelor, or else... Did you already try to read other code like Axelor's one ? It seems on other platforms they've put as much as possible functionnalities, but they can make only minor upgrades because they are stuck with coding standards/platforms. Dolibarr seems more free from platforms/ strict coding standards. Isn't it ?

[UnderDogg]

Tinyerp and Axelor are made in different programming languages, so it's more difficult to make changes. There is almost no way to compare these 3 products. Coding standards: when Dolibarr was invented coding standards didn't exist or barely existed. That's why the new effort needs to start with the information we have (coding standards is one of them)

[PMickael]

@UnderDogg a new codebase from scratch doesn't sound like a great idea, because I don't think that we get enough mind ressources on this. Maybe a cleanup of what exists will be a start we do not actually need to use a framework to do that, we just need to get access to the codebase but it's seem's to be complicated...

If you want to start a new CRM ok, but it will not be dolibarr anymore

[jtraulle]

On the same page with @PMickael ... A hard fork and complete rewrite from scratch seems absolutely unreasonable and will fail like the few forks before that.

[cfoellmann]

I also don’t see a future for a rewrite. It costs to much manpower. Starting something new is great but something so complex will take a long time until it would be usable for the users of an ERP system.

I am not sure what route we are going to take. Even if we pick up dolibarr. Main plus for me was php and MySQL and with a commitment to cleanup and „translations“ it might still be a viable option.

[dolibarr95]

[hregis]

For my part, I consider Dolibarr as a framework, it's up to us to improve it. Make a break in the engine will generate a lot of problems! See Prestashop who has made a break in its mode of operation, it involves fees to the user! Dolibarr is an ERP/CRM! A cut would be fatal! We made a fork, which is no longer a fork, because completely rewritten in NodeJS + MongoDB https://www.tomanage.fr/

[dolibarr95]

@nielsdrost7 https://www.dolibarr.fr/forum/15-retours-dexperiences-utilisateursintegrateurs/64477-dolimodern

[UnderDogg]

Guys it's ok, it was just an example. I took all of Dolibarr's HTML files and did put them in a template, so you can generate templates from the Dolibare source code that you want to improve. I just read the opening post and when you look at the repositories you see the examples.

• grab the docker environment and run it in the usual way. You guys probably want to improve the current Dolibarr sourcecode and that is perfectly fine.
• unfortunately all information is echo'ed right from the source code (the 2005 way, the title of this topic). When you want to do it in a modern way, you want to make templates (views). If you look in dolimodern you will see all those views.

I wish you all the best of luck with improving the current sourcecode

[hregis]

it's possible to reinvent the wheel, but why reinvent the wheel when we could improve it? ;-)

[cfoellmann]

I really like @UnderDogg s drive. If we can iterate and keep everything backwards compatible it could work. Improve „everything” under the hood and keep it running for everyone invested in the project. We have to keep in mind that using an erp System is a long term investment and you need to give the users (enterprise) the peace of mind to be able to rely on it for years.

If we could move everything to php 7.2 (+5.6) + horizontal scalability via docker it should be a good idea.

The templating system (MVP concept) while keeping extensions working “for now” in parallel should be a good move!

I hope this discussion keeps going. And keep it civil people!!

[hregis]

the 9+ version of Dolibarr does not have any problems with php 7.3! The VMC can be broken down into many concepts! The rules are there to follow a road, but is it the right road? ;-)

[cfoellmann]

I looked at the code and it is a horror. Especially when you do not understand ANY French! Rewriting something like the templating would require touching a large portion of the code base. Ergo many of the French “elements” can be replaced. An English code base would allow more people to contribute

[jtraulle]

Maybe it is possible to progressively transition from French to English in existing codebase (without the need of hard fork). If this is done one module at a time with the appropriate SQL migrations, it should be doable ... What do you think ? On the other hand some core modules are tightly coupled and should be refactored together ... One other major problem that I can think of is about preserving compatibility with the existing external modules ecosystem provided by various developers ...

[hregis]

@cfoellmann I develop on Dolibarr since 2005, it is a French project at the base, so inevitably there is French! We modify little by little the code to put English from everywhere ... without integrating bugs !! ;-)

[torvista]

I wish Eldy would comment on this...as there is a lot of energy, time, effort and experience being wasted just in this thread as it is in a vacuum. I think my first posts are still relevant.

[ChangePlaces]

It's interesting to see this thread come alive again, and I think it's provoking some interesting discussion.

@torvista an ERP needs to be easily modifiable to fit into business workflows. One size does not and can not fit all. In addition, your other point that other people don't contribute to dolibarr is probably because the code is a mess, not understandable (both because of French, and no real order / sequence to the code).

@UnderDogg I don't think a hard fork is appropriate. There are 777 issues. If you restart, you're going to be fighting those issues and creating many more. Also, symfony would be a smarter choice. Laravel is too opinionated for its own good.

@dolibarr95 : I'm sad to see the bitchiness and catty attitude from you towards those trying to help an aging project into the 21st century. It could breathe life into dolibarr and open up many new doors. e.g. having an all-English code base would allow many other people to wittle all those issues down to a smaller number. Everyone would prosper here.

Phrases like, "it is what it is" and "it works for me", and "I don't want to change it much" are not good enough and are the bain of advancing past the fear of the unknown. Imagine having a codebase with plugins... and how other developers could develop their own plugins to add new features and even opensource them for dolibarr to use.

Well-planned, thought out changes to the code base would make no difference to the end user what-so-ever and could be planned over a period of time with people helping out where they can. Database changes could be handled effortlessly with migrations, and doctrine would make this a breeze. Some of the earlier commits would be horrid as a simple change would have to encompass so many files, but over time this would improve.

It needs support from core developers who have an intense knowledge of the system and a community wanting to help. It seems like 50% of this is met so far!

[hregis]

@eldy Eldy wants to keep maximum autonomy from external libraries, and maintain compatibility with devices for the blind peoples! Dolibarr is already a Framework! It must be changed little by little! No break in the code!

[torvista]

other people don't contribute to dolibarr is probably because the code is a mess, not understandable (both because of French, and no real order / sequence to the code).

Well that is your opinion, but my opinion is that most people who start using Dolibarr are small business people who are not aware that the code is not built on a 2019 framework.

When I started preparing it for my business and started digging into it, yes there is a mixture of french and english, but that that is only to be expected and it makes no sense just to rename things unless that is part of a code improvement: if it is not broken, don't fix it. There are plenty of things that DO need fixing and they should have priority.

As I said before Dolibarr is a large project with a long history and lot of legacy code. I have no doubt the developers would love to change it all overnight but that would destroy the user base who do not have the skills to manage a big bang/breaking upgrade. But, a detailed roadmap from the developers to detail how they ARE going to move the project codebase forward is, I think, solely needed, to better focus a discussion such as this.

Where real developers as yourselves are showing interest, the project leaders should be jumping at the chance to include you and guide your efforts to where they think they would be best employed. Their lack of comments is not encouraging....

[hregis]

@torvista Think again! it's encouraging ! I had doubts a few years ago and a fork was born ... but the evolution of the Dolibarr code is such that it makes you want to contribute! Dolibarr moves fast and well! it must be considered as a framework! A base that allows you to create what you want! an external module can use the technology we wants!

[dolibarr95]

bitchiness and catty attitude from you

@ChangePlaces the picture is a joke sorry if i hurt somebody here..and I just invit nielsdrost7 to comment in the forum in a specific topic about his work. ;)

[dolibarr95]

@ChangePlaces about videos... As I said here : https://www.dolibarr.fr/forum/12-howto--aide/62681-wiki-dolibarr-org My objectiv is a perfect wiki (full documentations, screenshots...). I've got my opinion about videos, mooc, and other platforms...but this is not the right place to talk about it i think. :)

[PMickael]

Core dev team right now :

[FHenry]

@UnderDogg I give a look at you code, nicly done, install it, but I always get 404 page not found of laravel framework, maybe welcome or home route lead to nowhere ?

[dolibarr95]

:) It could be nice if can @nielsdrost7 present/talk about his work : https://www.dolibarr.fr/forum/15-retours-dexperiences-utilisateursintegrateurs/64477-dolimodern or create a topic in the englis forum

[UnderDogg]

@FHenry interesting, can you go to /ownercp? Or /projects? I'll take a look as soon as I can @dolibarr95 on my way, I didn't have an account and my French isn't that great, so I need google translate I did some replies on the forum, I hope they understand

[ChangePlaces]

I can't create any issues in doli modern, so here goes as a potential roadmap overview:

0/ It's been a while since I've looked at the code base (been busy creating my own system) but if unit tests do not exist, they need to be written. No one like writing them, but they always uncover things that are broken)

1/ A familiarity with the current issues should be noted. You may come across solutions as you touch the code base.

2/ the current codebase should be converted to english as a priority. this can be done with online translation if necessary, but I'm sure there are enough native speakers here to help. At this stage, it should not translate table and field names, but should include where necessary: comments, filenames, variable names, class names. Comments should be done first. The easy part. Next, a good IDE will replace the names across the whole project (though they are not perfect, so a commit should be done after each variable / class change just in case). Care should be taken to avoid changing things that are not related to the current change. This is where core committer support would help, but, beggars / choosers etc. This is not an easy step as care and attention has to be paid to the renaming of the variables / classes. When all tests pass, all's good.

From here things will get a little fuzzy. It's possible to merge twig templating into the system with the current code base (Symfony doesn't enforce the MVC paradigm) and get the same output. Templates would have to be created and move the necessary logic in to either twig language, or in to controllers and then pass the data to the template (depending on how complex the data is). Sub templates for things like tables and other view can be crafted and pulled in by other templates when needed. This would simplify templating by 100 times!

A single index page will use a "router" to know where to pass the request to. This will be passed to a controller which will pull in the necessary data then calling the templates. The codebase from above should be able to be wrangled from many different files that call the above templates into several single-concept controllers. It's handy to have one set of controllers for the user views, and one set for the API.

The API is not to be left behind, the controllers in symfony can easily output json data (simply return $this->json($data)) and should return the same data as currently. This will need to be 'bodged' in places, as changing the api (if necessary) to english names will be reserved for later as it'll be a breaking change.

Then, models can be created using doctrine and then integrated into the above View/Controller system. This allows annotations to create the meta data of the database. Here, table names / field names can remain the same (it's invisible to the common user). As changing field names can be a breaking change (e.g. 3rd party code which interface directly with the database for private stats etc would break). It would have to be reserved for a major version change.

---

Each of those steps can be broken up into 100 different steps, but for a general overview it's a start.

Project structure is important, e.g. in the current code, to install plugins you're overwriting code unknowing what it's replacing it with. Huge security hazard. By putting modules inside a 'module' directory, will prevent this. Although not a priority at this stage, it'd be possible to separate the modules into separate projects so they can be installed as necessary by the user.

I remember reading about the background of dolibarr and how its developer/s received support from the french government. I'd assume if you're not being told to make a change, because the boss is happy, then why bother wasting energy changing it?

[altairis-tof]

Am i the only one to think that an ERP is made for users and not for developers ??? Dolibarr is very popular and i dont understand why some guys want to break it into pieces... if you want to play on your own, just start a new project but please dont waste our time ! if you want to improve dolibarr and follow the lead, you are welcome.

[ChangePlaces]

please dont waste our time

who asked you to "waste your time"? Improving the codebase will mean more people able to contribute which equals more features, better code, fewer issues with the code and hopefully fewer bad attitudes towards change. Essentially the changes would be invisible to 'you' the end user, but as you're on github you're more than a 'user'.

if you want to improve dolibar...

That's the whole point...

...and follow the lead, you are welcome.

From a development point of view, there is 'no lead'. The code is an awful mess that only some people can contribute to, and oh, I'm repeating myself again

[altairis-tof]

ok for improve; not ok to throw it all away. and yes i'm a developer and i know that what i develop is for end users not for developer pleasure. and last more, french is one of the most spoken language around the world ;-)

[cfoellmann]

I think we should return to a more productive discussion!!

@altatof About the reach of French for users (people) you are right but if you were to measure the language skills among developers you will get a different picture.

i know that what i develop is for end users not for developer pleasure Your result is for the end user but in an open project you do have to consider how your work is impacting your fellow devs/contributors

[ChangePlaces]

I'v'e just re-read down this thread from the start and noticed a few things:

• @eldy removed the "bug" from the title of this issue and sees it as "code enhancement",
• there are a series of vocal 'developers' who are aghast at losing the French contained in this code as if it's some sort challenge to national pride,
• there are issues going back to (at least) 2015 about re-organising this code base which have either been closed, or are still open, either way no action has been taken.
• no support from core team at all.

The last point is a concern. If they don't advocate clean code, then I dread to fear what undetected issues are happening. 777 issues is a lot for any project and the core team / person should be jumping on the chance of improving the codebase. But they are not.

As it stands, it's unmaintainable, impossible to merge into any business practices, impossible to read (even for french nations), and I would rather exert my energies to other, more productive situations. I've seen this before with Drupal (such a complex code-base no one could understand it except core dev team) which now is mostly symfony modules, and prestashop (core dev is offensive to people who point out issues with the code) which has serious security issues, and more.

As I wrote elsewhere, without core team support, any large changes to the codebase will be impossible and a waste of time as it'll be fighting them as they'll want to modify their code, not the improved code.

It's a shame so much energy has been in this thread.

[torvista]

no support from core team at all.

THIS is the FIRST issue that needs to be resolved, anything else is irrelevant/wasted effort until there is some conversation/signs of life from them.

[cfoellmann]

@ChangePlaces thanks for the summary. I am totally with you on your results.

In my quest to find an open ERP system written in PHP Dolibarr was more or less my last hope and on the outside it looks promising but due to the issues @ChangePlaces listed above it is not looking like I can go with the project. Since I come from the WordPress world I know a lot about doing the "not-standard" way or hard to convince maintainers. But WordPress is a project with huge legacy support but high quality releases. Despite what modern projects say about it it is dependable and promises long-term stability. That is what I was hoping to find in Dolibarr, too.

[cfoellmann]

777 issues is a lot for any project

The 147 open pull request show an even more grim picture. PRs that just waste away will discourage contributions and hurt an OPEN project. Open source is a choice that need to be actively engaged!!

[cfoellmann]

Me again 😉

I know that the French are very protective of their language BUT I dont see why changing the codebase to English exclusively is sooooo bad!? In the current state a French-only speaker does NOT understand the code because comments and code are partially English (whatever the ratio) and an English-only speaker does NOT understand the code either because of the Frensh portions.

So my question: What good does it do to reduce the group of devs able to contribute?

[altairis-tof]

it is not to be protective of a language or another; personnaly i dont care if the invoice table is called "invoice", "facture" or anything else; the fact is that end users dont care about it and want to have an ERP that suits their needs, whatever language or framework is behind; we have a good ERP that works with lot of users, and lot of coders at this time. So if you want to make it evolve, just do it by making PRs ;-) By the way, this kind of thread (troll ?) comes back every year or so, but i did not see many real contributions apart from discussions from those who initiate them.

[torvista]

I think the comments in french are irrelevant...I have seen they DO get changed when the file is updated, but really there are more important issues than that. You have to accept the history, don't use it as evidence the project is bad because there are non-english things in it, that is very arrogant.

I think the code/variables named in french is a minor irritation for non-french speakers...but changing them globally is major disruption...it can be done, but for what real improvement? It does not mean the code is bad.

BUT: 777 issues...unresolved, although the great majority are probably fixed...but who knows, yes it shows a lack of interest, professionalism AND a lack of pride!

147 PRs left for dead...yes it shows a lack of interest and yes, discourages contributions.

No comments here from the development team...in fact IS there a team or only Eldy?...it shows a lack of interest.

Sad, it makes me drag my feet about developing this. Like many others. I am hoping something else appears...but you know it won't, not overnight, to compete with the features Dolibar has: that takes years of development.

[cfoellmann]

for me the "bad" code (if it is or not) and legacy is not the major part giving me pause here. I love refactoring, modernization and code review but I learned my lesson in the past. Nothing is worse than sending PRs and getting back nothing. It will bug you every time you look at your open PRs list on Github.

If there was official movement here I would be more than happy to get my bosses to sign of on starting to evaluate Dolibarr further.