Bike-CMS. How I spent six days excitingly because of the comment on Habré

This story began with a comment on my article on Habré. More precisely, from the part of this comment:

“Try building a WordPress-level app and features - and it will just choke on the influx of users”

I considered this an argument in the style of “get it first” and, in general, passed by. But some time later, the stars formed in a completely unexpected way. First, I lost my main source of income. Secondly, after a week of jerky throwing, I decided to stop this activity and get distracted by something outside. Somewhere for a week. Growing budget holes and an occasional cold drastically reduced the list of possible entertainment.

At first I tried the game. But either I became a little old, or the games went wrong - by the evening of the first day I walked around the apartment and threw a ball under the ceiling with a grim face. And then for some reason I remembered about this comment. And about the fact that I always wanted to try to write my own simple CMS.

So the stars came together. And the results of this experiment of mine are in the article.

Accent

Why CMS . Because CMS is one of the first things a novice website builder meets right after learning the basics of HTML, CSS, and JS. And sometimes even before. Secondly, because everyone who deals with CMS regularly enough gets an objective or subjective reason to hate them. And many of them have the idea that he could do better. It’s like a childhood dream of “growing up and becoming a fireman”. I am quite anxious about such things.

Relevance of CMS. Some persistently bury CMS as a class of products. I disagree. In many cases, in terms of the totality of conditions, CMS is still the optimal solution. For example, when starting a business, for personal needs, etc. It seems to me that this class of solutions will live for quite some time, because He has a very specific target audience, which is not going to disappear. I’m almost ready to bet on the last trousers that the most common CMS will survive many very modern frameworks and their ilk.

The quality of my code. Oh, that’s a sore point. I am an amateur web developer. No more. My vocation (and main occupation) is to come up with different things. And (often) implement them in the form of MVP. I like to search for common solutions to problems, come up with useful (or just funny) things and applications, collect and analyze information, etc. I leave highly professional solutions to highly specialized specialists. The main thing I'm trying to achieve is that an expensive and very correctly made decision does not suddenly turn out to be absolutely useless. Usually, within this framework, everything works out pretty well for me. But the last project ended in a complete fiasco and plunged me into a financial hole. And there is quite a lot of my guilt. Many of those who want to kick me for bydlokod will be right. And I will be ashamed of my ignorance, because of which I could not make everything easier, faster and more correct. Or even mistaken. And then the next point.

Just important . I would like readers of this article to understand: this is not a ready-made, tested product. This is just a working model.. Made to test the concepts that were in my head. I think most will agree that six days is very little to create such a complex thing like CMS. It should be noted here that I wrote the documentation for another week in fits and starts. Honestly, this has become an incredibly difficult process for me. Only my donkey stubbornness made it possible to bring this work to at least an intermediate result. Which I was not satisfied with: the documentation turned out to be too long and not as simple and understandable as I wanted. Namely, it was to become one of the key points of the project: the documentation should be as complete as possible and at the same time capacious. So that after a couple of hours the reader has an almost complete understanding of the mechanism of the system and a minimum of "misunderstandings". In general, for this part I set myself "unsuccessful."

About bugs . They are undoubtedly present. Perhaps very serious. If you want to help me - write a letter to the mail (it is on the project website). This is the most faithful and convenient way for me to communicate.

Little lyrical digression

A long time ago I was a geophysicist. He was engaged in the interpretation of geophysical data. For these purposes, at that time there was a certain amount of specialized software. And it was creepy: pieces written by different people, crutches, modules that give data in different strange formats, data conversion modules for previous modules ... At the same time, it all cost quite substantial money. And all the same, quite often it fell off, fell, did strange things and generally demanded skilled ones. support for some money. As a result, half of the time went into battles with the "features" of the system and rechecking the results. And then I came across a domestic development on the same topic. Simple and understandable as a calculator, and even with neural networks out of the box. Yes, she couldn’t draw cards so beautifully and didn’t have a couple of things that were trendy at that time, and “neural networks” were more than primitive. But for simple routine operations and hypothesis testing, it was a treasure: this thing was installed on any Windows computer, it rarely crashed and worked smartly. I don’t know what the fate of the product was, but it saved me a lot of time and nerves. That's how I fell in love with simple and seamless solutions.

Reflections

Before you do anything, you should almost always think about it. Sometimes something sensible can come out of this. It was my thoughts at the beginning.

Why do we need a CMS? They simplify the process of developing a site and its use. End users (hereinafter, I mean site administrators, content managers, not site visitors) get a user-friendly interface for data management, the use of which does not require much knowledge and skills. The developer gets ready-made solutions to basic tasks that allow you to get the result many times faster than if he will be engaged in their independent implementation from scratch. At the same time, turnkey solutions are tested and developed, which dramatically reduces the likelihood of critical errors. Using popular solutions provides another important opportunity: the site owner (theoretically) can always find a developer who will solve his problem.

All of this would be great if it worked that way. In practice, it often turns out differently. Let's go over the main points.

Simple and intuitive for the end user. Some time ago I did a little experiment. I suggested to a group of six people to try myself as a content manager of two sites: an online store based on Bitrix and a blog on WordPress. There were quite different people in the group: my mother, geologist, dancer, guitar master, journalist and taxi driver. Each was offered a simple task: to add a product in an online store and an article in a blog. First, you had to try to do it yourself (after a brief general briefing), and then - according to the detailed instructions. The result was this: no one could achieve the absolutely correct result; there were fewer errors with the instruction, but they still were. In terms of "friendliness" from the point of view of the group, WordPress won. In general, “intuitiveness”, “understandability” and “friendliness” for end users are, for the most part, dreams of marketers and ideologists of one or another solution. In reality, these parameters are at a fairly average level, but for conscious use, some preparation is nevertheless required. At least this applies to the CMS that I have seen or actively used. Somewhere with this is better, somewhere worse.

Speed ​​of getting development results. This item usually works fine while it comes to installing a ready-made template and a couple of ready-made extensions. Those. about a completely standard site in a vacuum. But, as a rule, something more complicated is required. At least edit this standard template. And here usually picking begins in files with pieces of code for this template, its output logic, etc. The situation is aggravated by the presence of dozens, or even hundreds of functions predefined by the developers of a specific CMS (methods, classes, constants, etc.) with unpronounceable names. The initial idea of ​​these constructions was undoubtedly good: “call this function in the code and get an excellent result with one line of code and, at the same time, insure yourself against a shot in the leg / friend / cactus”. But I consider them evil. At least this is the version of their application that I see now in most CMS: the number of such structures is constantly growing, and their own complexity is growing. All this is served with sauce of "versatility." But, in fact, it creates a massive, unique for this particular system intermediate layer. Which must be studied, which takes a considerable amount of time. When I see whole books or paid courses on CMS, I feel somehow sad. But the most interesting part begins when it turns out that for the implementation of the necessary functionality, the CMS developers have not yet come up with a ready-made solution. Crutches begin, which are fraught with problems since often done without much understanding of the internal structure of the system. Of course, over time, the developer grows experience in using the system, many things become easier, more understandable, more familiar. But there is a downside: many are attached to specific CMS and do not want to learn something else. Because they remember the torment with the already learned. This sometimes gives rise to very strange decisions when CMS are used for obviously unusual purposes. But, saving time is still significant: a beautiful control panel is already included, and data management is more or less organized.

The quality of the result . If everything was done “according to the textbook” for this CMS and without the use of “crutches” from the previous paragraph, then the quality of the result will be approximately equal to the quality of the CMS itself. It all depends on the specific CMS. Most often, I have questions about performance. First of all, to consumed resources and page render time. When I see separate, more expensive hosting solutions for specific CMS, I again feel a little sad.

Lack of attachment to a specific development teamand relatively low developer qualifications. This is probably one of the main advantages of popular solutions: the first developer decided to become a manager, went into a binge or got married? No problem, we will find another! In reality, of course, everything is not so simple. A few months ago, I watched the following picture: on one project, they decided to change the development team to the launched project. One "gold partner" replaced another. Do you think everything went smoothly? Not. For three weeks the project was stormy: the timing of the planned work was disrupted, something constantly fell off or did not work as it should. Often CMSs are so huge, monstrous and immense that even in a project of very medium complexity it is impossible to quickly penetrate and continue someone else's work without much loss of time and nerves. In fairness, it should be noted

I think many will agree that working with a tool whose internal device is simple and understandable is much more comfortable than working with a “black box” (I do not mean a flight recorder). For quite a long time working with various web developers, I got the impression that quite a lot of them (including those that work in commercial studios) work just like this: they know what and where to put in the CMS and what happens at the exit. But they do not always know exactly how this result is obtained.

To summarize, I believe that all those CMS with which I had to deal are in themselves unjustifiably complicated compared to the complexity of the tasks they solve. And I do not like it. I would like a simpler solution, preferably without loss of versatility and with maximum control over what is happening inside. Of course, for now these are just dreams that are similar to a variety of napkins. It's time to move on to some solutions.

Solutions

In the beginning - one more small lyrical digression. That annoys me. Rather, it is pure “taste”, but it influenced the final form of the decision. So, distributions of 40,000 files and directories annoy me, some of which have a nesting level of more than 10. I feel nauseous when I see 2,000 lines of a template, which is a mess of HTML and PHP, which are engaged in outputting a relatively small part of the page. I have an unpleasant feeling when an HTML tag opens in one file with such a mash and closes somewhere in another. And when there are more than three such files, I feel worse. No less discomfort is delivered by PHP files that contain (without obvious necessity) HTML markup or nothing but a list of include'ov.

And now to the decisions, in fact. Let me remind you that I decided to raise the flag of maximum simplicity. The first solution is to separate developers and end users. A developer is one who more or less owns the main stack of web technologies: PHP, HTML, CSS, JavaScript, MySQL. The end user is the one who will use the finished product and whose ownership of the aforementioned stack can be any, starting from scratch.

Many CMS continue to flirt with end users with phrases such as “you don’t need a programmer to create a website!”. Yes, sometimes, for a certain category of users, this is very useful. But sites are becoming more complex, their requirements are increasing. And if we are talking about a project with at least some ambition, then at some stage the programmer will certainly appear. For everyone else, there is, for example, Wix (muck). This flirting has a downside: a lot of buttons, settings, etc. appear in the system. All this should be stored somewhere and somehow work, which means new tables in the database, files in the distribution kit and general complication of the system. And the general complication of the system brings it closer to the state of the "black box", etc. Therefore, in RushCMS (as I called my experiment) all this simply will not happen.

The next blow will be dealt to predefined designs. Most popular off-the-shelf CMSs use the same technology stack as mentioned above. On the basis of which most of the predefined constructions are implemented. When I look at the Bitrix developer guide, I get the impression that there are more methods, classes, and functions there than in PHP itself. Of course, one cannot do without predefined constructions. Otherwise, there will simply be a complete return to the “self-written CMS in pure PHP”. But their number must be minimized: we leave several utility functions (authorization and some others) and a fixed structure of files and directories - the developer must always know exactly where to look. PHP and HTML should be separated. We refuse all predefined output functions. No more get_posts ().

How then to output the data? Let's assume that they explain to you in 20 minutes how data is stored in the database and in the file system. So that you do not have doubts about what, where, how and for what is stored. How much time will it take you to compile an SQL query and write a PHP code that will return to you all entries of the "Blog Article" type starting with the letter "A", the name of which does not contain the word "Vasya" and sorted by date added? Probably a bit. We will output the results using a simple template engine. And yes, let one be the output templatefile. No, of course, you can divide it into several. But is someone afraid of a long, but “readable” file, after a “sheet” of a mixture of HTML and PHP? Moreover, for example, the example site template (included in the distribution kit) is not so long: if you remove all empty lines, it fits in about 200 lines. The logic for processing it fits in about 220 lines (with empty lines). At the same time, the example site is a very small, but almost a real online store. We add here a very simple (although, of course, not ideal) caching system "out of the box", the mechanism of action of which is explained in 15 minutes and which can be turned off.

But, of course, CMS is conceived in for the sake of the end user and his beautiful control panel. The simplest solution is to give the database editor to the end user. Do not rush to laugh, this is an important starting point.

Because once I did it. The task was very simple: occasionally change the value of one field from 1 to 0 and vice versa, which I usually did (this was a temporary solution, honestly). But at some point I had to urgently leave. I left a simple instruction to the boss secretary and flew off into the night. When I returned, a surprise was waiting for me: the values ​​of completely different fields of this table were accidentally changed. Secretary’s hand trembled!

So, as practice shows, giving an unprepared person a DB editor is a bad, very bad idea. But let's see why it is so bad. And, at the same time, imagine that we can change the characteristics of the database editor with the power of thought.

Firstly, the user is frightened and forced to make mistakes by the abundance of unnecessary information. Let our imaginary database editor get the opportunity to set permissions to view and edit fields in tables. And, at the same time, will learn to establish the same rights to the records themselves in the database tables. Now the secretary from my example above could only edit one type of field and only for the necessary records. We hide from it all fields, except, for example, the field with the name of the record and the field in which it should enter values. He can edit only the last. We go a little further and add the ability to verify the entered data. So that he could not accidentally write “2” or “S” instead of the set 1 or 0. Now the chance of an error is minimal. Transfer our database editor to the browser. As known, the average user does not like the presentation of data in the form of tables and does not understand it. We introduce service fields in the table structure to store data about the hierarchy of records. We force the editor to display the table entries in the form of familiar “files” and “folders”, and the value of the fields as their “properties”. We add the ability to assign human-friendly aliases to our “properties”. For example, “Stock” instead of obscure data_available. Of course, the user prefers to check the boxes instead of entering zeros and ones in the text fields. And working in the spirit of “upload a file via FTP to this directory and enter the name of the file in this field” is very bad. Therefore, we add to our editor the ability to assign "properties" to a js-handler, which will output the data as the user likes. We add the ability to assign different handlers to the same field to different user groups and the ability to assign rights to add / delete “files” and “folders”. Those. records. Of course, some data needs to be processed on the server side: to decrypt the encrypted one or, for example, to implement some additional logic hidden from the user. For example, the user checked his “out of stock” checkbox, and not only the value of the corresponding field has changed in the table, but also some other value connected by the logic. Or an angry letter was sent to the mail of the beginning warehouse. Anything. For all this, we add the ability to implement server-side event processing logic. some data needs to be processed on the server side: to decrypt the encrypted one or, for example, to implement some additional logic hidden from the user. For example, the user checked his “out of stock” checkbox, and not only the value of the corresponding field has changed in the table, but also some other value connected by the logic. Or an angry letter was sent to the mail of the beginning warehouse. Anything. For all this, we add the ability to implement server-side event processing logic. some data needs to be processed on the server side: to decrypt the encrypted one or, for example, to implement some additional logic hidden from the user. For example, the user checked his “out of stock” checkbox, and not only the value of the corresponding field has changed in the table, but also some other value connected by the logic. Or an angry letter was sent to the mail of the beginning warehouse. Anything. For all this, we add the ability to implement server-side event processing logic. the warehouse left an angry letter. Anything. For all this, we add the ability to implement server-side event processing logic. the warehouse left an angry letter. Anything. For all this, we add the ability to implement server-side event processing logic.

This very simplified and customizable database table editor is RushCMS. More precisely, its main (and only functional) “module”. The task of the developer is to configure the logic, assign aliases and handlers to the fields, determine the rights and give to the end user. All relatively few settings are stored in service files. In the database of the original distribution - only data related directly to the site. An example site (the same mini-store) has three tables in the database: for storing data on site pages, users and orders. All three have a simple and uniform structure.

Here's how it looks (I’m a bad designer, especially if I have to do design quickly) for the end user from the Content Managers group now:



To be confused, it seems to me, is quite difficult. I was not able to test this prototype on the same control group that I wrote about above. Only four out of six. With the same task. Everyone did better, there were fewer mistakes. This, of course, is not a very scientific experiment, but still.

Of course, the process of setting up a working environment has its own difficulties. This is probably the most difficult part of the whole process of working with RushCMS. But, in the segment where CMS is used, there are many typical tasks. And having solved them once, it is quite easy to use the operating time repeatedly. So this should not be a big problem. Writing custom handlers for fields is also not too difficult. It seems to me that the overall result is quite universal and simple.

My 5 kopecks about Open Source

And here I’ll bite a little and drown. Forgive me. Until that moment, my participation in Open Source consisted of donations to a dozen projects without serious sponsors known to me, the results of which I regularly use. I "brought" them an average of $ 2 per month. In addition, occasionally I wrote bug reports and even less often tried to offer something to the authors on GitHub.

A couple of months ago, Habré published an article “ So why don’t you participate in the development of Open Source software?” ". When I stumbled upon it, there were already a lot of comments and I did not start to get alarmed, especially since most of what I wanted to say was already said by others. Now that I have decided to post my almost random pet project, I’ll insert my five cents here.

Many of my friends (most often those who are only indirectly related to IT, but at the same time use OS projects) put an equal sign between Open Source and such concepts as “free” and “not aimed at gaining profit”. Which, of course, is fundamentally wrong. However, this fairly widespread misconception plays against Open Source. A significant part of the audience considers their authors cranks, ready to sacrifice material wealth in the name of the ideals of mankind. Such, of course, are. But there are not many of them. Most OS projects, it seems to me, are similar to startups and are done in anticipation of some benefits. If not even direct, then at least indirect: user support, sponsorship, paid support, reputation growth, etc. Both of these phenomena seem similar to me: it all starts with a fit of enthusiasm, when everything is done simply out of a desire to implement the idea and see what happens and continues with routine processes: refinement, support, feedback processing, etc. But routine always undermines any motivation. If motivation is not fueled by some kind of return, then the project gradually dies. As soon as the motivation runs out completely, the project is in the cemetery. Even if it remains useful and in demand. There are such "zombie projects" that are dead, but still go. Even if it remains useful and in demand. There are such "zombie projects" that are dead, but still go. Even if it remains useful and in demand. There are such "zombie projects" that are dead, but still go.

From the experience of several of my friends I know that a cactus (or streamer of games) can live, at best, on a user donat (especially in Russia). Sponsors are a rare occurrence; in order to receive other benefits, the project must be very large and in demand. The reasons for the mass emergence of startups and OS projects are the bright prospects that are drawn in the head, the reasons for the demise are the fact that these prospects do not want to become reality for too long.

While I played with this article and its subject, I had fun. Positive emotions and a genuine interest in the process in a sense pays for the time spent. On the other hand, the breath of the routine was already quite felt when I tried to write more or less complete and intelligible documentation. I have never been strong in this and, I repeat, it was given to me hard. At that moment, I just figured out how much time it would take me to support this project if I decided to seriously develop it. It turns out at least one day a week. Full. Because the idea of ​​doing something like this an hour after the main work is utopia. I checked, albeit not on OS projects. You can, of course, process every hour (i.e., devoted to raising money) an hour, freeing yourself one day. But not the fact that this scheme will be successful: all the same, an additional unpaid load is obtained, and the main work rarely allows us to implement such an approach in principle. And to receive from standard OS-project revenue sources an amount that will compensate for this one day is a task, it seems to me, from the field of unscientific fiction. All this is a little sad, of course.

And okay my entertainment. But how many really cool projects are dying. In my opinion, in the Open Source world so far everything exists on the principle of "better than nothing."

Conclusion

Despite the minor previous section, I, of course, will play with my model for some time. I think many had this obsession: “I want to write my CMS.” Almost a childhood dream. Now I can say to myself: “Oh yes, I tried to implement it. As much as I could, but I tried it. ” And I'm damn pleased somewhere inside. I will still smile. All good and great spring, friends.

Link to the project on GitHub , everything is there.