Candy editor
Programmer's guide

Purpose of Candy editor

This scheme is useful for where occasional alterations are required to the details of an existing web page or two. This is not a CMS or blog. A typical application is to allow a trader to tweak their offers, opening hours and so on. Another application is for a club that just wants a simple web page with what's on, who's-who and the odd photo of events and people. CE is ideal for maintaining list of events.


Note Replacable images and uploaded reference documents are always in the same directory as the page being edited.
All you need is a server that runs PHP and of course the ability to edit files and FTP them. Some extra functionality will be lost if your server can't send emails.


This guide is local. The rest gets FTPd to the 'home' page of the server.
Pretty much EVERYTHING goes in the home directory. That is the same directory as the page(s) being edited.

Logs will go in ../info

Backups are pushed onto a stack of sub-directories of ../safety: prev1 to prevn

The download consists of a zipped collection of files which make up a demonstration system.
The simplest way to get started is to put all the files except the guide on the server.
"Home" directory is the one containing the page to edit.
homecandyedit.phpThe PHP file which does everything
homecandyedit.jsJavascript used by client
homecandyedit.cssStyling for editing
homejquery.jsjQuery javascript framework. The exact name may vary. See Configuring
homeessential imagescandy*.gif/png
homedemo imagesclub*.jpg/gif
homeclubIndex.htmStart here to prove system is working
homeclubDemo.htmA sample page to get started with
home/info.htaccessProtects against the passwords and logs being viewed
home/infopageInfo.txtTiny page by page configuration file containing access passwords
home/safety-Backups will go here

Try the demo

IE compatibility issueIn Internet Explorer press F12 (Developer tools) then select Document mode to be standards. If the display changes then edit your source to put the HTML 5 doctype in. ie. <!DOCTYPE html> to zap the 'Microsoft knows best' quirks mode.
At this point you should have a working demonstration system. Point your browser at your server/clubIndex.htm.

If the page being edited is then the way to edit that page is When we're editing the page there may be slight layout alterations but the idea is to keep the layout the same and simply highlight editable bits with candy stripes.


There are two configuration tasks:
  1. This isn't a super-secure way of storing passwords but it should be invisible to browsers. Test by pointing your browser at it.

    The .htaccess file is supposed to block browsers. If not then consult your server's documentation.

    Edit ../info/pageInfo.txt on a page-by-page basis.
  2. Edit candyedit.php All the configuration parameters are at the top of the code. These are documented in the code. Particular ones to note are:
    JQUERY_PATHThis is the jQuery javascript library. As supplied this points to a valid file. You are free to use a later version or different location. More details here.
    INTERNAL _PASSWORD You may find that the .htaccess file doesn't protect pageInfo.txt which contains the password(s). If so you can delete pageInfo.txt and provide a password here. Note that this password applies to all the pages in this directory. In practice this shouldn't be much of a problem as most CE applications will be a small handful of pages edited by the same person.
    These are sanity checks on stupidly large files being uploaded. Think what is reasonable. Remember that users will try to upload 5MB photos for thumbmails etc.

    IMPORTANT PHP will have it's internal upload limits which may be as little as 4Mb. This is set in php.ini. See the discussion in the code for how to deal with this if it is a problem.

    JQ_DOC_READY Ignore this if you don't use jQuery

    When hacking a page for editing CE needs to know if jQuery is already being used by the page. If this string is found in the original then that's the signal to just add in our code not build the whole thing from scratch. There are a number of ways to implement the document.ready event hook. You may have to tweak this search string to exactly match you version.

    CHANGE_NOTIFY_EMAIL Where to send an alert to say there is some editing going on.
    Leave blank to disable.
    Multiple addresses can be separated by semi-colon. eg.;

    This feature may be useful for checking that users haven't made a complete hash of things.

    Not all servers can send email or hosts block it.

    EMAIL_CHANGE_FROM If you are using the notification of changes email feature then you'll need to provide a From: address. Be aware that your server or host may have strict rules about outgoing email so if it doesn't work you should check with them.
    This is set to 3 minutes in the demo system so you can see the backing up working. This is far too short for a real system.
    CE makes a backup each time editing is started more than a certain time after the previous starting of an edit. For example if this is set to 2 a user will be able to fiddle around making a number of attempts without second and third edits causing backups to be shifted onto and down the stack. On the other hand if they did some edits in the morning then came back for more edits in the afternoon (providing 2 hours had elapsed) there would be another backup made.

    If you are using the 'email on editing activity' feature this gets triggered at this point. (So remember if you get a notification you may want to wait a while before looking at the changes the user has made.)

    VERSION_DEPTH How many previous versions are to be kept on the backup chain.
    EDIT_LINK_STYLE If you are using the editlink=YES setting in pageInfo.txt then this is the css that will be used to style the <A> tag that does the trick. As supplied it appears as a 3-pixel grey square.
Checklist Image upload size adjusted Password set Version delay=2 Original page backed-up

Making bits editable

All you do is add class=ed to span, div, h1, h2, h3, h4, li, tr, img and a tags.

General notes

Image tags

A tags


Hidden elements

Imagine a user deletes all the rows of a table. Then there is nothing left for them to edit! To deal with this the last deletion is not physically implemented. Instead the element gets the class edx substituted for ed. CE automatically adds .edx {display:none} to the live document head which hides the marked elements. However as they still show up when editing they are not lost forever.

As shown in the demo you can deliberately use class=edx for elements that only get used on high days and holidays.

Tell users

Keep it simpler than simple

For most people, updating a web page is a chore. They're probably not confident, haven't got materials and have forgotten what they did last time.

At least at the start give them the bare minimum of editing options. If they get on OK with that then you can think of adding more flexibility. Think of the most important updating functions, the ones that they really want and stick to those for starters.

What users need to know

  1. Editing URL and password.
  2. A printout of the normal page with editable bits highlighted.
  3. A reminder that changes and typing mistakes are published instantly!

Getting started

In practice the biggest difficulty for users is getting the necessary information. No data = no editing!
Arrange a time when you're available on the phone for them to have a go. Tell them to collect the necessary checked information first as this is for real.
  1. You can point them to the menu bar to get started.
  2. Show them how to edit a div or span and save the page.
  3. If that goes OK then go onto lists and tables
  4. Leave image uploading to later.
  5. Leave A-tags to last.
    Common mistake when creating a sequence of documents: Edit the same document without changing its name. When this is uploaded as next month's minutes it will overwrite the previous version. Users must give new names to new documents

Technical details



CE was put together by Peter Fox @ in June 2011.

Yes you can contribute to development

CE is an open source project so you can see and play with the code. Often people have small but useful contributions that might take only a couple of hours to do and then, this is the good bit, the improvements are available to other users.

Bugs and improvements

Fix them yourself or explain clearly with screenshots if applicable what the problem is. @


Technical people tend to think that more features must be better. NO NO NO. Candy Editor is meant to be as simple as it can possibly be. That is deliberate. We let the web page builder deal with the design and leave the user to maintain the content. If they want a blog use blogging software. If they want a CMS then use that. If they want pretty content then they can either ask the page builder to do a professional job of re-design or use their word processor to create documents they can easily upload as PDFs etc.


Internationalising a free open source application like this is a really cool way to contribute a little bit to better programs for everyone. It doesn't take long but it makes it accessible to lots more people.
Editing the javascript
All the strings that need altering are listed at the top of the code . How you go about making the alterations are up to you but it may be best to copy the strings as a block and from there search and replace en_ with an appropriate language code such as say de for German.
Editing the PHP
This is more tricky than the javascript as often literal text is combined with program variables. All the places that need attention are marked with i18n. Note leave "OK" alone as that is used as a signal by the javascript on completion of the AJAX call