Winter CMS and Github... a looong story to tell, i have.

[qroft]

Hi everyone. First of all sorry for this message being so long, but i am having a deep conflict with how a german agency developed a website made with Winter, specially after treating the client like garbage.
So here is what happend:

1. A friend of mine had an idea for a project and asked me for help. I told him to go with Winter as this would leave him free in finding people who are into PHP, Laravel, CMV etc. so that he does not depend on me.
2. For the start I made him the page, that more and more grew to something like a portal. At THAT point I told him that me, as a sole freelancer, can not offer the quality in service and development and that we together should seek an agency that a) works with Winter b) can guarantee a pro development and c) extend the service to sending newsletters, user support, marketing solutions for social media etc.
3. We did find a German agency that at first sight looked promising. But after giving them acces to the server, things started to go weird. For example one of the first things they said was that my code is amateurish and that you don't work like that these days. They said that they only work with Winter CMS via Github. Period.
4. I said that I am fine with that and absolutely willing to hand over everything to them, whatvi did. So they made A WHOLE relaunch of what I did and after the first new things where done, I was out of the project, as planned, but also because I did not know perfectly how to work with Github. So for me everything was fine and I had a good feeling that my pal was on good hands, though they said strange things about my work.
5. After some weeks the agency became absolutely rude and unprofessionell in communicating with my friend. And started to charge for stuff that they said that needs to be coded - though I already had written and implemented it, back when i was doing the launch. Remember, they said my code was bad...
6. but apparently not bad enough as they were still using it, though they charged for "correcting" my errors.
7. Now the whole project is on hold because they want for example to charge more money for old features that i already did and worked.

My friend is funked up with this whole situation and now asks me to do the whole thing again, though I still tell him that I as a one-person freelancer can not offer all of what he wants.

BUT my biggest question here is...
When I met October CMS (now Winter) I deeply felt in love with what I call "an IDE in the backend". I love the whole process of layouts/pages/partials/content etc. is what I have been seeking for decades moving away from creating locally and then upload to the server.

SO THE QUESTION: Why do you develop a website made with Winter CMS using Github, when you can do it through the backend?

I understand that developing a plugin or something more special in a workgroup is better done via Git as collaboration.
But in my case when I told the agency that I want to change the title of a page, they said that I must do so via Github. A whole pull and push just for changing a word?

I still love Winter and will keep up with it as long as possible, but for me the Winter CMS + Github that they tried "to sell us" here is a fail, from my point of view.
Or am i missing a point here?

[josephcrowell]

The way you did it isn't necessarily wrong. It sounds like this agency is ripping you and your friend off.

That said, I personally use Github and keep all of my work there so I can have a change history and so others that work with me can see how I got to the development stage that I am at. It's also easier for them to jump in and contribute. We can see who inserted code that broke things and provide instruction on improving their work processes. So many things.

I would like to mention again, however, that this is not necessary and you can totally develop a site the way you did it. Just because you didn't use git doesn't mean that your code is bad. If it works then it probably isn't as bad as they're saying.

[qroft]

I am just wondering if a "mix" of both worlds would not destroy everything? AFAIK yiu can tell Git what files or folders to push, so that you could, for example, leave out the folder with the partials or pages. On the other hand I do understand that a coder loves to create these with his/her favorite IDE.
But I have a feeling that this way stuff could get wrong.
Imagine an editor working on the "About us" page in the CMS background, while a coder does changes on that file through Git. At the end the one will overwrite the update from the other, I think.

[josephcrowell]

It will create a merge conflict and the file from git will have to be merged with the one that didn't use git.

https://www.atlassian.com/git/tutorials/using-branches/git-merge

[LukeTowers]

This is exactly the workflow that the Database Templates feature was designed to support: https://wintercms.com/docs/cms/themes#database-driven-themes

The idea is that it can be enabled on the remote server so that any changes made through the backend are persisted to the database and if any changes are made to the underlying file (i.e. after a deployment from git where changes were made) the original changes remain in the DB and remain taking effect into a developer resolves that merge conflict, typically by syncing those changes down locally, syncing them to their filesystem, committing and deploying them, and then removing the DB copy of the file from the DB with the "reset" button or just by manually deleting the DB records.

[LukeTowers]

With regards to point 3:
While it was rude of them to label your development approach "amateurish" (I personally can think of one German WinterCMS developer that solely develops on remote servers and he is definitely not an amateur, although I think he does use Git); I can certainly understand and support their requirement to work on the project using Git as a source control repository. There are a multitude of reasons to use source control, especially when working with a team of developers / contributors (although there's also very strong arguments to be made to use it even when it's just you working on a single project).

As far as your overall question:

Why do you develop a website made with Winter CMS using Github, when you can do it through the backend?
For a large number of varied reasons. Let me try to list off some of the reasons that I can think of off the top of my head:

• It's pretty much always better to develop locally and then push your changes to the remote server, this avoids a large class of issues such as:
  • accidental exposure of debug information in a live environment
  • breakage and downtime in a live environment
  • accidental corruption / loss of data in a live environment
  • can continue working on the project even without internet or if the provider goes down
• Other benefits of source control include:
  • The "Why" behind any and every line of code in the project - you would not believe how often I use git blame to figure out when and why a particular line of code was added; and doing this allows me to avoid recreating previous issues or attempting solutions that have already been tried and failed; or just getting a better frame of reference as to why the code is structured the way it is which better informs the solution that I will come to (even if you are the only one working on the project it can be absolutely lifesaving to have that history - several times I have done a git blame only to find out that I was the author of the code in question six months to several years ago)
  • The history of past solutions (imagine someone asks for a homepage popup and then to get rid of it. Then, several months later they ask for it to be added back - with source control that is easily done, without it you'd have to had "removed" it by commenting out code - which is just horrible for long term code maintenance)
  • an automatic backup of the codebase for the project
  • much easier to share and collaborate on a project if it is managed via git rather than live editing the same set of files at the same time
  • much easier to deploy that project on new environments should anything happen since the regular workflow of the project involves being able to do that whenever you add a new developer to the project

See also some of the following resources:

• https://www.git-tower.com/learn/git/ebook/en/desktop-gui/basics/why-use-version-control
• https://www.webfx.com/blog/web-design/why-you-should-use-git/
• https://www.nobledesktop.com/blog/what-is-git-and-why-should-you-use-it

Ultimately though it sounds like the agency was a poor fit for your client's needs. In development there are a million and one different ways to accomplish the same technical end results, and each of them have their own pros and cons. It sounds like your initial approach may have been focused on achieving the end results as quickly and easily as possible (which is totally valid, and Winter provides a multitude of ways to achieve similar results - I will sometimes pick the quick solution of implementing everything I need on a page in the PHP code section of the template rather than take the more "proper" way of building a dedicated component for that page simply because there is no need for a component on that specific page for that specific use case and implementing it the fast way is just the best option given the time, resources, and expectations involved).

While your approach worked for you and may have been fine with your client, agencies tend to have developers that have developed their own preferences over time, especially if they are eager to do things "properly" or have run into the downsides of the simpler approaches in the past and wish to avoid them going forward. This is probably why the agency chose to "rewrite" functionality that you already had built; so that it was structured in a way that they felt would be the best option for the long term. However (as always with contracting work, agencies, freelancing, etc) it ultimately comes down to communication. The agency may feel strongly that this approach is needed for the long term success of the project, but if they cannot effectively communicate that to the stakeholder or if their assessment of the project's triangle of needs (fast, cheap, good - pick two) was incorrect, then this end situation of unhappy people on all sides will always result.

Given that I only have one side of the story here, I wouldn't necessarily judge either of you based on what you've said so far - I think the problem just comes down to communication. Both development approaches have their merits, but you always have to make sure you're aligned with the stakeholders goals and limitations to deliver the best results. As far as your own personal development, I would recommend looking into version control systems in general and git / github specifically; it has the potential to expand your capabilities as a developer and will at least give you a more solid background to have these conversations with other developers / agencies in the future.

[LukeTowers]

Just to follow up on this, I think that while it is easy to critique someone else's work as subpar or amateurish and feel better about yourself for having done so; it is a mark of a good developer to be able to do so in a diplomatic and constructive way. It's always important to remember that most people don't try to do a bad job on purpose and typically aren't aware of the shortcomings of any given approach while they're developing it.

It is much more beneficial to take some extra time to figure out how to provide criticism of other peoples code in a way that strives to avoid badmouthing them and instead focuses on the potential issues with the current approach and the possible solutions for resolving those issues that have been identified.

This is something that I personally have had to work on a lot over the years and continue to need to work on, so I am by no means innocent of having made similar remarks in the past. I would however strongly recommend that all developers keep it in mind when commenting on other people's work and focus on being constructive and providing solutions instead of merely defining all of the problems as much as possible.