What is the most efficient way to create a dynamic page body?

Question

I took a look at the PHP script behind my dad, which was built by a hired programmer. Now I do not think that I am better than him, but I think that his technique may not be the best.

The website has a dynamic page body, in the sense that my dad can use the specific admin page to modify the HTML content on most web pages on the website. Now this is done through the database: all pages are stored in the database, and each request processes the request, which extracts the page from the database and implements it.

Now I think this method is very bad, mainly because it requires (even if not so expensive if you cache) an additional query to the database. Wouldn't it be more efficient to store pages as HTML files, and then just change the file itself when needed? Thus, editing the file, I think, is faster, and loading the contents of the html file for each request is much simpler and faster than executing the request.

It? Is there any other (more efficient) way to deal with this situation?

Answer 1

There are several good reasons why a CMS should use a database to store / retrieve dynamic content. Just as there are several reasons why you prefer not to rely on the database.

• Pro Db:

  • Security: this is an obvious and slightly ambivalent argument, but nonetheless. If you decide to save your content as separate files on your server, they will need to be saved in a directory that does not allow public access. Otherwise, users may access pieces of your site individually, which may seem unprofessional.
    People with dishonest intentions will also easily modify the content of your site. Of course, there are many ways to prevent this and increase overall security. Database systems left on their devices are also not completely secure, but provide minimal effort for hackers.
    note: the security argument is worth or falling with how well the script injection filters are disabled, and how to safely configure your server.

  • Disk usage. When using separate files to compile each requested page, the server needs to access its HD for each request. Again, caching solves this problem to some extent, but it’s easier and (in general) better to cache the results of a database query (step-by-step performance). Either on the database server, or in PHP, or, even better, both.

  • Logging

    . By this I mean: when you change the content, managing a CMS using a database is much easier. If you have changed the content and want to undo / undo the changes, DB is the easiest way to implement such a function. Using HTML, you'll soon be wading through tons of files called site_menu_block_YYYY-mm-dd.html.backup . Even if this is done using a script, it will almost certainly be slower than using DB.

  • Translation: as vlzvl pointed out, if you use static pages, you either finish each page N times, once for each language. When changing style sheets, you also have to change N files. This is an expensive resource. In addition, your scripts will parse the HTML template file for each request and the XML file with the actual content. Thus, you lose SEO advantage in HTML files and cause excessive load on the server and on your website.

• Pro HTML:

  • I can only give one lasting argument: it’s much easier to get an SEO site this way. Just let search engines index individual files. This greatly reduces the overall security of your CMS. .

However, I think I'm right in saying that all major CMSs use both methods, depending on what data they are dealing with. HTML headers, for example, are often partially stored as separate files, like JS files and style sheets.

Answer 2

this is a question of the century ... there is no exact answer to this question. just performance tips. People have been working on optimizing page loading over the past 30 years.

Answer 3

No, it’s better not to have fixed HTML pages under the hypothetical '/ mypages folder .

• What if the user wants about 500 content on his web page? he will have 500 files.
• Yes, of course, they will be serviced faster, but is this enough to solve the huge problems below?
• What about page translation ? it will be a nightmare in static html files.
• Pages are displayed in this way because they are dynamic; that is, the material can be “introduced” by third parties / plugins (say) and applied to several contents at once; how to apply the same material to multiple HTML and then change it again ?
• How about if you want to change HEAD> * er and * <SCRIPT> ** loaded? you will be forced to do this in all 500 contents in each change.
• What about the PHP included in these .html files? This is not a reason if you do not put PHP into this, but if the included php file is renamed / deleted, you will need to change all the files in a bulk update.
• Think of patterns ; the reason modern CMS (or admin pages) are dynamic today is because they can change classes / styles, etc., without affecting the content itself. A single change in the theme used or in one class will cause (again) a massive update.
• A database is files , but run faster . If you are worried about performance, you can program the database to use caching (queries such as SELECT data FROM content WHERE id = 1 ), so the query is hardly requested in terms of performance.

I can think more.

Answer 4

It all depends on the content. When you have a lot of other content, such as news, it’s easier to store data in a database for each news server and load the data into a template. But when you have one content (for example, a huge article or information page), you can use HTML to store data.

It also depends on whether you want to use a multilingual page or not. You can sketch a multi-page page with HTML only. But here is the same as above. What is your content. Many different entries or less than one content?

But, what I have done so far, I have done both at the same time: when the client needs a page with script news and multilingual, etc., I created a page on which the user can log in to the news feed and save the news in different languages, but changes to other sites are done using HTML, and a different html file exists for each language.

EDIT:

It depends on the user. If the user does not know how to use HTML, but wants to change the site itself than the only available option, this is the opportunity to give him the administrative center for making changes. OR, if you do not want to give the user much benefit: D

Answer 5

My opinion. Most CMSs handle many database calls and upload many files to compile a single page, which is ultimately sent to the visitor. However, for most sites there is no performance issue (i.e. loading most pages in <1s). Therefore, I would be surprised if you have problems with one access to the database. But for processing, why use a database when your site is really not needed? I have made several sites for clients, where I use one index.php, which downloads one menu file and one footer file, which are the same for all pages, and separate selected html files are loaded between them. Therefore, to edit the page, you use any editor to open and edit the corresponding html. Very simple.