Bike-CMS. As I fascinated spent six days because of the comment on Habré

This story began with a comment to my article on Habré. More precisely, with parts of this comment:

“Try to build a WordPress level and application application - and it will just suffocate from the influx of users”

I counted it as a “first beat” argument and, in general, passed by. But some time later, the stars were formed in a completely unexpected way. First, I lost my main source of income. Secondly, after a week of convulsive rushes, I decided to stop this occupation and get distracted by something else. Somewhere for a week. Growing budget holes and occasional common 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 with a gloomy face threw a ball under the ceiling. And then for some reason I remembered this comment. And about the fact that I always wanted to try to write my own simple CMS.

That's how the stars came together. And the results of this experiment of mine are in the article.

Placement of accents

Why CMS . Because CMS is one of the first things that a novice website builder meets, immediately after learning the basics of HTML, CSS, and JS. And sometimes even up to. Secondly, because all those who deal with CMS quite regularly receive an objective or subjective reason to hate them. And many of them give birth to the idea that he could have done better. It’s like a childhood dream to “grow up and become a firefighter.” I am quite anxious about such things.

Relevance CMS . Some stubbornly bury CMS as a class of products. I disagree. In many cases, in the aggregate of conditions, CMS is still the best 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, since He has a very specific target audience, which is not going to disappear anywhere. I'm even almost ready to argue for the last pants, that the most common CMS will survive many very fashionable frameworks and others like them.

The quality of my code . Oh, this is a sore point. I am an amateur web developer. No more. My vocation (and main occupation) is to invent different things. And (often) implement them in the form of MVP. I like to search for common solutions to problems, invent 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 am trying to achieve is that an expensive and very properly made decision does not suddenly turn out to be absolutely useless. Usually, within this framework, I'm doing pretty well. But the last project ended in utter fiasco and plunged me into a financial pit. And my fault in this is quite a lot. Many of those who want to kick me bydlokod will be right. And I will be ashamed of my ignorance, because of which I could not make everything easier, faster and more correctly. Or even mistaken. And here is the next item.

Just important . I would like to read this article to understand: before you is not ready, 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 as a CMS. It should be noted here that I wrote the documentation for another week in fragments. Honestly, this was an incredibly difficult process for me. Only my donkey obstinacy made it possible to bring this work to at least an intermediate result. Which I was not satisfied with: the documentation was too long and not as simple and understandable as I wanted. Namely, it should have been one of the key points of the project: the documentation should be as complete as possible and at the same time succinct. So, 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 put myself "uncomfortable." If I still decide to continue to engage in this project, then immediately after the war with bugs and delirium in the code, I would rethink the approach to writing documentation.

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

Small 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: parts written by different people, crutches, modules that give data in different strange formats, data conversion modules for previous modules ... All this cost a lot of substantial money. And all the same, it often fell off, fell, did strange things, and in general required skilled ones. support for some money. As a result, half the time was spent fighting with the "features" of the system and re-checking the results. And then I came across a domestic development on the same topic. Simple and understandable as a calculator, so even with neural networks out of the box. Yes, she didn’t know how to draw cards so beautifully and didn’t have a couple of ultrafashionable things at that time, and the “neural networks” were more than primitive. But for simple routine operations and hypothesis testing, this was a treasure: this thing was installed on any computer with Windows, it rarely fell and worked quickly. I do not know what was the fate of the product, but he saved me a lot of time and nerves in my time. That's how I fell in love with simple and complete solutions.

Reflections

Before you do something, it's almost always worth thinking about. Sometimes something sensible can come out of it. It was the reflections that I started at the beginning.

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

All this would be great if it worked that way. In practice, often goes different. Let's go over the main points.

Simplicity and intuition for the end user . Some time ago I did a little experiment. For a group of six people, I offered to try myself as a content manager for two sites: an online store based on Bitrix and a WordPress blog. There were quite different people in the group: my mother, a geologist, a dancer, a guitar master, a journalist and a taxi driver. Everyone was offered a simple task: add a product in the online store and a blog article. At first it was necessary to try to do it yourself (after a brief general briefing), and then on detailed instructions. The result was the following: no one was able to achieve absolutely the right result; with the instruction of errors became less, but they all the same were. In terms of "friendliness" from the point of view of the group won WordPress. In general, “intuitiveness”, “clarity” and “friendliness” for end users are, for the most part, the dreams of marketers and ideologues of this or that solution. In reality, these parameters are at a rather average level, but for conscious use, certain preparation is still required. At least, this applies to CMS, which I have seen or actively used. Somewhere with this is better, somewhere worse.

The speed of obtaining the result of development . This item usually works fine while we are talking about installing a ready-made template and a couple of ready-made extensions. Those. about an absolutely standard site in a vacuum. But, as a rule, something more complicated is required. At least edit this standard template. And here, picking in files with pieces of the code of this template, its output logic, etc. usually begins. The situation is aggravated by the presence of dozens or even hundreds of functions predefined by the developers of a particular CMS (methods, classes, constants, etc.) with unpronounceable names. The original 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, which I see now in most CMS: the number of such structures is constantly growing, their own complexity is also growing. All this is served under the sauce of "universality". But, in fact, it creates a massive, unique for this particular system, intermediate layer. Which needs to be studied, which takes a significant amount of time. When I see whole books or paid courses on CMS, I feel somehow sad. But the most interesting thing starts when it turns out that the CMS developers have not yet come up with a ready-made solution to implement the necessary functionality. The time of crutches begins, which are fraught with problems because often done without a special understanding of the internal structure of the system. Of course, over time, the developer has a growing experience in using the system, many things become simpler, 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 studied. This sometimes gives rise to very strange decisions when CMS are used for purposes that are obviously unnatural. But, time saving 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 the resources consumed and the page return time. When I see separate, more expensive hosting solutions for specific CMS, I get a little sad again.

Lack of attachment to a specific development team and relatively low requirements for the qualifications of developers. This is probably one of the main advantages of popular solutions: the first developer decided to become a manager, went into hard drinking or married? No problem, find another! In reality, all, of course, is not so simple. A few months ago, I observed the following situation: on one project, we decided to change the development team on a running project. One "gold partner" replaced the other. Think everything went smoothly? Not. Three weeks the project was stormy: the timing of the planned work was disrupted, something was constantly falling off or was not working as it should. Often CMS are so huge, monstrous and immense, that even in a very average complexity project 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 that in the example above, the management was guilty of the situation, its ambitions and a very weak understanding of the technical part.

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 few of them (including those working in commercial studios) work this way: they know what can be put in CMS and where what happens at the output. But they do not always know exactly how this result is obtained.

To summarize, I believe that all those CMS with which I have had to deal are in themselves unreasonably complex compared to the complexity of the tasks they solve. And I do not like it. I would like a simpler solution, preferably without losing universality 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. It is rather a pure “taste”, but it influenced the final form of the decision. So, I’m annoyed by distributions of 40,000 files and directories, some of which have a nesting level of more than 10. I feel nauseous when I see 2,000 lines of a template representing a mash of HTML and PHP that output a relatively small part of a page. I have unpleasant feelings when an HTML tag opens in one file with such a mess, and closes somewhere in another. And when there are more than three such files, it gets worse. No less discomfort is delivered by PHP files that contain (without any obvious need for them) HTML markup or nothing other than the list of include'ov.

And now to, in fact, solutions. 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 already finished product and whose ownership of the above stack can be anything from scratch.

Many CMS continue to flirt with end users with phrases like “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, requirements for them are rising. And if we are talking about a project with at least some ambitions, then at some stage a programmer will definitely appear. For everyone else there is, for example, Wix (muck). Such flirting has a reverse side: 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, and a general complication of the system. And the general complication of the system brings it closer to the “black box” state, etc. Therefore, in RushCMS (as I called my experiment) all this just will not happen.

The next blow will be dealt with predefined constructions. Most popular ready-made CMS use the same aforementioned technology stack. On the basis of which most predefined constructions are implemented. When I look at the Bitrix developer guide, I get the impression that there are more methods, classes and functions than in PHP itself. Of course, it will not be possible to manage without predefined constructions. Otherwise, just a full return to the "self-written CMS in pure PHP" will occur. But their number must be minimized: we leave several service functions (authorization and some others) and a fixed structure of files and directories - the developer must always know exactly where to look for what. PHP and HTML should be separated. All predefined output functions are discarded. No more get_posts ().

How, then, to display the data? Let's assume that in 20 minutes you will be explained how the data is stored in the database and in the file system. So that you have no doubt what, where, how and for what is stored. How long will it take you to compile a SQL query and write a PHP code that will return to you all entries like “Blog article” starting with the letter “A”, in the title of which there is no word “Vasya” and sorted by date of addition? Probably a bit. We will display the results using a simple template engine. And yes, let the output template be one file. No, of course, you can divide it into several. But would someone be frightened by a long, but “readable” file, after a “sheet” of a mixture of HTML and PHP? Especially because, for example, the template of the example site (included in the distribution kit) is not so long: if you remove all empty lines, it fits into about 200 lines. The logic for processing it fits into about 220 lines (with empty lines). At the same time, the example site is a very small, but almost a real online store. 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 being started up also for the sake of the end user and his beautiful control panel. The easiest solution would be to give the end user a database editor. Do not rush to laugh, this is an important starting point.

Because once I did. The task was very simple: occasionally changing the value of one field from 1 to 0 and vice versa, as I usually did (it was a temporary solution, honestly). But at some point I had to leave urgently. I left a simple instruction to the secretary of the boss 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. The secretary's hand shook!

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

Firstly, the user is frightened and makes to make mistakes, the abundance of unnecessary information. Let our imaginary database editor be able to set the rights to view and edit fields in tables. And, at the same time, learn to install 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 entries. We hide all fields from it, except, for example, the field with the name of the record and the field to which it should enter values. It can only edit the latter. Go a little further and add the ability to validate entered data. So that he could not accidentally write down “2” or “Y” instead of 1 or 0. Now the chance for error is minimal. We transfer our database editor to the browser. As is known, the average user does not like the presentation of data in the form of tables and does not understand it. We enter into the table structure service fields for storing data about the hierarchy of records. We force the editor to display the records of the tables as usual “files” and “folders”, and the value of the fields as their “properties”. Add the ability to assign our "properties" comprehensible pseudonyms. For example, “Availability” instead of incomprehensible data_available. Of course, the user prefers to tick instead of entering zeros and ones in text fields. And the work in the spirit of “upload a file via FTP to this directory and enter the file name in this field” is very bad. Therefore, we add the ability to assign “js-processor” to “properties” in our editor, which will output the data as the user likes it. We add the ability to assign different handlers on the same field to different groups of users 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: decrypt encrypted data or, for example, implement some additional logic hidden from the user. For example, the user has put his tick “out of stock”, and in the table not only the value of the corresponding field has changed, but also some other logic related value. Or an angry letter went to the post office of the warehouse. Anything. For all this, we add the ability to implement server-side event processing logic.

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

This is what it looks like (I’m completely bad designer, especially if I have to do design quickly) for the end user from the Content Managers group now:



Getting confused, I think, is quite difficult. I was not able to test this prototype on the same control group 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 the 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 deciding them once you can quite easily reuse the groundwork. So this should not be a big problem. Writing your own handlers for the fields is also not too difficult. It seems to me that the overall result was quite universal and simple.

My 5 kopecks about Open Source

And then I'll dip a little and ponoyu. Forgive me. Up to this point, my participation in Open Source has been in 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 aren't you participating in the development of Open Source software? ". When I stumbled upon it, there were already a lot of comments and I did not get stuck, especially since most of what I wanted to say was already said by others. Now, when I decided to post my almost random pet project, I’ll put in my five kopecks here.

Many of my friends (most often those who are only indirectly related to IT, but somehow use OS-projects) put an equal sign between Open Source and such concepts as "free" and "not aimed at obtaining benefits." Which, of course, is fundamentally wrong. However, this rather common misconception plays against Open Source. A significant part of the audience considers their authors cranks, ready to sacrifice material benefits in the name of the ideals of mankind. Such, of course, is. But they are not so many. Most OS projects, it seems to me, are like startups and are made in anticipation of some gain. Even if not direct, then at least indirectly: user support, sponsorship, paid support, reputation growth, etc. : , , : , , .. . - , . , . . «-», , .

, ( ) , , ( ). — , . OS- — , , — , .

, . . , , - . , , . , , . . . - — . , OS-. , , (.. ) , . , : , . OS- , — , , . , .

. . , Open Source «, ».

Conclusion

, , , - . , : « CMS». . : « , . , , ». - . . , .

GitHub , .