What to do next time?

This is a pilot version of the app quickly assembled more for demonstration purposes rather than for use as a production instance. Therefore, in principle, it may contain minor bugs and typos.

I don't know how much free time I will have yet. If I have enough, I will probably fix the errors I found. But for now, I will just write them down here so I don't forget.

Uncontrolled removal

This issue affects the following files:

• static.pages.only/Themes/default/dashboard/bbcodes-delete.tpl
• static.pages.only/Themes/default/dashboard/styles-delete.tpl

The essence of this issue is that when we process the deletion of a file selected by an admin and are ready to start the deletion, we also need to check if this file is still in use somewhere.

For example, the stylesheet file being deleted may still be in use on some page at that moment.

Also, for example, the bbCode being deleted may be in use on some page.

Therefore, we need to warn the administrator about the contradictory situation before the uncontrolled deletion of that file occupied by someone.

Editor style is glitchy

When you select a different style in the page editor form, you can see how the entire style changes - not only in the editing area, but also in the form elements. It shouldn't be like this. I need to consult with some talented CSS master who can tell me how to solve this problem in the most elegant way.

Please compare the following screenshots:

Then I change that style, for example to "bootstrap.css". Look what happened to the form elements:

The same glitches occur in the built-in constructor.

Additionally

I would like to get rid of the bad practice of writing the !important flag in the following style files:

• static.pages.only/Themes/default/css/edit.css
• static.pages.only/Themes/default/css/login.css
• static.pages.only/Themes/default/css/ui.css
• static.pages.only/Themes/default/css/pages/*.css

In some cases, using this flag may be justified. However, its excessive use usually indicates suboptimal use of style rules.

DOCTYPE conflict

The issue is more theoretical than practical, since it is unlikely that an administrator would store a Fragment block with the <!DOCTYPE ...> tag in the built-in Constructor's storage.

This issue can be solved by modifying the following functions:

• static.pages.only/Helper/Helper.php
  • helperEchoEditableBody()
• static.pages.only/Themes/default/js/constructor.js
  • dragstartFragment()

Currently, these functions modify that tag name to a CSS "safe_!doctype" name which is invalid.

Wishes

These wishes came to mind while testing this application:

1. Add a grab functionality. As you know, this application has 4 types of content, for which the following administrative functions are implemented:

   • Edit,
   • Mark Up,
   • Construct,
   • Upload,
   • Download,
   • Copy,
   • Delete.

   I think it would make sense to also offer a Grab feature. So you can save fragments, style files, and even entire pages (their HTML) you found somewhere on the web that you like.

   However, to avoid unauthorized grabbing, the Grab module must have a unique security label (like <meta name="allow-grab" content="..."/>) that should be inserted into the HTML code of the donor site to confirm permission to grab its content.

2. Add a page style for writing comics. Currently this application contains the following style files:

   • View "bootstrap.css"
   • View "ck-demo.css"
   • View "ckeditor-premium.css"
   • View "ckeditor.css"
   • View "default.css"
   • View "don-quixote.css"

   I thought it would be nice to have a style file like "comics.css" as well. I liked the simple layout shown in this codepen example.

3. Fill the Fragment storage with another Bootstrap blocks. Currently, the storage contains only these blocks:

   • Breadcrumbs,
   • Features,
   • Jumbotrons.

If you have any other interesting ideas for this application, please describe them to me.