Home arrow CMS Content Editing
Editing content in a CMS

Editing content in a CMS

Most CMS use a plugin wysiwyg editor. This means an interface that avoids the need to use HTML coding.

A 'what you see is what you get' editor works in very much the same way as MS Word, for example, and is easy to use for anyone. It may require a few minutes' practice, but that should be expected. Most such plugin editors can be looked upon as restricted versions of Word - easier to use, with less capability.

You can of course just code directly into the interface, using HTML. Or, perhaps of more use, the output of an external HTML editor can be pasted into the CMS editor interface. However, the idea of a CMS is that this should not be necessary. In any case, doing this will almost certainly override the style and presentation guidelines that the CMS manager has set, so it is a very bad idea in the first place. A cms with radically different pages - weird layouts, odd fonts, different colours and so on - is probably not what you had in mind when you ordered the CMS in the first place. Some sort of common design and appearance from page to page is normally seen as a good idea.

Plugin editors normally produce good code that performs well in SEO for CMS, as that is what they are designed to do. Try not to override them and put your own version of pagecode in, as the result is likely to be non-compliant code that does not validate and is poor for SEO.

Tips for success

When editing a page in your CMS, don't treat it in the same way as if you were typing in Notepad or Word on your office or home PC. It looks similar - feels similar - but there are important differences, mainly to do with the fact that you are actually working on a server a long way away.

Think about this: you type your text into the interface of a plugin module, in your browser. The browser is talking to a server that may be thousands of miles away. The browser is connected to a module, which is just a part of a CMS, a very complex server script. It sends an interface page to your browser. When done, you hit a button and you hope that:

1. The PC's browser remembers what you have done.
2. That it sends that data correctly formatted to the server.
3. That there are no problems on the thousands of miles of wire or fibre that connect you.
4. That there are no glitches at the dozens of interconnect points in that journey.
5. That there are no problems with the server, at the millisecond your data arrives there.
6. That the server correctly hands that data to the CMS.
7. That the plugin is working 100% when it receives your edit data and translates it for the CMS.
8. That the CMS interprets it correctly.
9. That the server doesn't have a RAM or database server issue just at that point.
10. That your editing session hasn't timed-out by the time you hit that button. Your session might be limited to 10 minutes without action - that means without hitting the Apply button at some stage.

So there are a couple of things that could go wrong...

In fact the miracle is that, mostly, the system works fine. But sometimes it doesn't. In addition, you can get an editor / browser / cms relationship that is absolutely perfect and problem-free; or you can have a set-up that is decidedly flaky.

So: you must not count on your edited content getting there problem-free when you hit the button.

That would just be plain crazy, as you're not dealing with a copy of Word on your PC - you're dealing with a complex set-up thousands of miles away, with complex traffic flying backward and forward over that distance in order for it to work at all. Don't expect it to work 100% all the time!

Safety procedures

What you must do is adopt a 'Safe Editing' procedure. Otherwise, occasionally when you hit that button, you'll lose all your work. No way around it - you can't change the Laws of Physics, Jim.

Basically, a safety policy means to cover the possibility of errors. It means you DON'T:
  • Work for 20 minutes, write 500 words, then hit the Save button.
  • Paste in a whole new page, hit Save, and quick-delete the original - job done!
Ouch! If you do these you are just plain asking for trouble and there will be tears at bedtime.

What you should do is this:
1. Think about the possible consequences of losing all your work at any time. What should you do to prevent this?

2. Answer: never work for more than 2 minutes without saving. Then, you can only lose 2 minutes of work.

3. Never destroy an original. File it away safely.

4. Always use Apply, not Save (until the end). Apply is much safer.

5. Never use Save until you have checked the work thoroughly and are quitting. Always use Apply instead - even if you have finished. Just use Apply, even when finished. Then - finally - Save.

6. Work for a minute or two then hit Apply. Then check the result on the livesite.

7. Make this an automatic routine that needs no thinking: every minute or two, hit Apply, check the livesite. Work a bit - hit Apply - check the livesite.

8. You need 2 browser tabs open. If you don't have a tabbed browser, you must get one in order to work with CMS. If you don't like tabbed browsers for some reason, then you will need 2 separate browser windows open.

9. Use the Apply button in preference to Save. Even at the end - use Apply first. Never use Save until you are finally quitting, with all work checked.

10. Whatever you do, don't work for a time, then hit Save. You are just begging to lose all your work.

11. And then finally, after hitting Save, check the livesite one last time. Check right down the page. Check the source code and make sure the metadata is correctly displaying.

12. Remember that you have a limited session editing time - perhaps 10 minutes. If there is no action within this time (eg Apply), then if you hit Apply or Save at 12 minutes then you will find yourself logged out and all work lost.

13. Because of the limited session time and other issues, there is no harm in hitting Cntrl+A before you hit Apply or Save. The entire page text is then saved to your clipboard - it's safe.

The Apply button saves the work and stays on the page. The Save button saves and quits. Although in theory there is little or no difference, in practice there is a world of difference and you should ALWAYS use Apply until quitting.

Leaving the Editor page

NEVER leave the content editor page without using the SAVE button.

If you do this, you may lose your edits, or the page will be locked to other admin accounts.

Page content types

Main content pane
The page content consists mainly of main content blocks, and module blocks. In most templates there is only one main content area, called the contentpane or the centre column. Other blocks of content around this are contained within modules.

The main page content is arranged in articles that can be found in the Content Manager section of the backend admin. We term these articles CIs or content items. It is convenient to allocate one per page, though if the article is long it can be spread over several pages. Conversely, several small articles can be published to one page. Therefore for most purposes a CI (eg an article) is a page -- but it doesn't have to be.

Discrete Content Items (aka static content) are separate articles that are not related to any other content and  not often edited or moved. Therefore they are kept separate, and are not allocated to Categories. A custom error page is an example. It will still be thought of as a 'page', even though this type of article - like others - may not necessarily always be published as a page.

These separate blocks are distributed round the page and may contain menus or small articles. Or, of course, images, videos or anything else.

The content item in a module can be called an MCI or module content item. Again it is a separate article that cannot be moved or reused, except by a cut and paste of course.

MCIs can be found within their modules, in the Module Manager in the admin backend. You can edit them there, and also change the position of the module on a page. The appearance of the module can also be changed.

Plugin editors for CMS

There are lots of plugin editors available. There is an advantage in having a choice because there is no single editor that does every job well. For example, here are the strong and weak points of several:

Excellent with images - gfx can be uploaded to the CMS within the editor. You can even paste images into the editor, onto the page, if you know the procedure. Very poor with text formatting. Very good with anchor links. Good with standard links. The best plugin editor for image handling.

Very good with text formatting. Terrible with images. Poor with links. Useless for page anchor links as they are not present at all. The best plugin editor by far for text work; but poor for the rest. Not for frontend users as it gives too much text formatting power.

The TMedit copy and paste blocked issue
In this editor there is a weird fault in a security script that blocks text being pasted in on some browsers. You cannot use the keyboard Cntrl+V or the right-click Paste. There is a kludge given on how to fix some scripts but it doesn't work. The solution is to use, on Firefox, the browser toolbar Paste icon, and in K-meleon, the Edit menu Paste command. There are about 4 or more commands available in a browser to paste text in, and one or more will bypass the faulty script block.

The Tiny MoxieCode Editor is often the default editor in a CMS. It's a safe choice, even though it's just average with images and poor with text. Links are good.

A basic editor suitable for frontend users.

Wysiwyg Pro
Very similar to Tiny MCE and looks like a rebuild of this editor. The same icons, the same facilities. You still can't upload an image through this editor. However the text controls are much better, so this editor is a step up from TinyMCE. It doesn't have the image capabilities of FCKeditor though, or the full text controls of TMedit. It is a good choice for frontend editors who do not need to upload images, and if you don't mind them having control over font sizes. It has some weird names for various items - probably unique - perhaps as a result of translation errors. Anchors for example are 'bookmarks'. A nice clean interface that will suit trusted frontend contributors.

A good full-feature editor that handles images well. This is a commercial product. At first, Innova looks like a basic editor because the  control panel does not look comprehensive - but the functions are available on investigation. It may look at first to have similarities with TinyMCE, but Innova handles both images and text better. It has image handling capabilities on a parallel with FCKeditor. Text handling is also better than TinyMCE. You can upload images through this editor. Server independent, works on PHP or ASP. Because of this it is often seen on ASP - .NET CMS. Innova is described as highly extensible, meaning that you can add your own functions, and buttons for them, more easily than with other editors. Since this is a platform-independent editor that handles both the main tasks of full text control and full image control well, it is a good choice in any situation, especially for ASP backend work.

A plugin editor can be chosen for its plus points, so that you can have what you need to do the job at hand. It's a very good idea to use two, since they all have major faults and omissions. Using two can get around that. Here's how you do it: just create another ID for yourself, and allocate a different editor to that ID. Simple!

Of course, it's not such a bad idea if the editor app is a bit restricted, in some cases. If you are allocating it to frontend users, after all, you don't want them to be able to override the CSS - as you can easily do with TMedit. That would be a recipe for disaster, as you'd get green text, two column articles, comic fonts and who knows what else. For frontend users, allocate them TinyMCE, it's safe for them to play with.

However, if they will need to do image uploads, it will have to be FCKeditor. In this case, you can allocate the frontend users a cut-down version that won't let them go too wild.

The CMS difference

Working with CMS is different from writing to a Word document. You're dealing with a complex process that's taking place back and forth across a long distance. Sometimes it goes wrong - so play safe.

Standard website editing is better, did I hear? Yeah sure - waiting 3 weeks for the webmaster to get to it; paying big bucks for simple stuff to get changed; no way to add fancy stuff unless you see the bank and then wait 6 weeks. Better? You've got to be kidding. CMS is light years better in every possible department.

But like any technology, don't act as if it was foolproof - it isn't.
Web Business Managers