First things first; make sure that your database is setup, accessible, and configured to allow remote connections. It’s also important to ensure that the Edditt webservice will be able to write to the filesystem and create folders – if this isn’t done, you’ll not able to complete the set–up. More information on system requirements can be in the documentation. 

Edditt creates a number of tables in your database. These are life blood of Edditt and contain everything that the system needs to run. In addition, Edditt will create a cmsfiles folder in the root of your webspace where all files in the ‘local’ area of the file manager will be located. 

Now that you know what’s going to happen, you’re ready to add your site. Login to your Edditt instance, go to Account and then click Add a site. 

First up, you’ll be asked to enter a couple of URLs. The site URL is the address of the site you want to setup and the development URL is the temporary URL of the site while it’s being developed. If you’re not intending to use a development URL, you can leave it blank. Neither URL fields should contain http:// or trailing slashes. 

If you’re using a development URL set In development to yes. Edditt will then attempt to connect to the webservice on the Development URL rather than the Site URL. 

The next stage in the process is setting up the web service. Without this, Edditt can’t operate. 

In terms of the Path to the webservice, you’re free to use whatever path you want, e.g. edditt/ws.php. We also recommend downloading the webservice every time you add a site. There’s a couple of reasons behind this. The most important reason behind this is that we regularly update the service with bug fixes and system–level improvements. Secondly, we pre–fill the webservice with your subdomain and custom URL details. 

Auth–code is the password used to authenticate your site to Edditt. Again, you can use your own code, but to make it easier just click on the generate button which will add a random and long winded code to the auth–code field. Saves you having to think of one! 

You can change this later if you wish however, please make sure to update Edditt if you change the webservice–config in the future. 

The penultimate step in the process is setting up your database connection and if you have all your details to hand and your database is setup correctly, this should be pretty straight–forward! 

Database Server refers to the address your database is hosted at. You can use either a URL or IP address for this. Generally this will be the same as your domain name, however some hosts provide databases on separate servers. 

Insert the Name, Username and Password associated with your database and then choose your Database Type. At the moment, MySQL functionality is available. We are open to others and can add more when needed; so let us know!  

Table Prefix refers to the prefix we add to all the tables that Edditt creates to run. This can be customised to be whatever you want to be. We’d recommend that you get Edditt to setup these tables for you. However you may also decide that you don’t need to create these tables. Be careful! If you don’t set these up correctly, Edditt won’t work! 

So with that all done, everything should be in place to add your site to Edditt.  All that remains is for you to Deploy and your site will be added to Edditt. 

If Edditt has encountered a problem in the setup process, you’ll be told and you’re able to go back and review your settings before deploying again. 

So there we have it, you’ve added a site to Edditt. Here’s to many more!

After months of long days filled with documentation–writing, coding and re–coding, improving and streamlining, we have got to the point where we stop talking and start listening. There were times when it felt like we would never get there, but now we’re so happy to be able to let you loose and see what you think.

We are immensely proud of this not–so–little system. We know that it frees you to develop in a way that no other system does, giving you all the tools and hooks you need to code the way you want to.

Over the coming days and weeks we’ll be blogging and tweeting about all the amazing things that Edditt has to offer: features galore, solid infrastructure, and a beautiful interface. But now is not the time for that. Now is the time for you to explore and enjoy. 

The revolution is here.
The revolution is now.

Join the liberation front.
Join Edditt. 

As if that’s not enough, each module itself has configurable options and features that you can turn on or off, giving you the ability to completely tailor it to the requirements of the site you are building. 

But what about that one specialist function that might not be in the box. Worry not; if you need functionality that the base module doesn’t, then look no further than Web Hooks.

Every module allows you specify a web hook – a page that receives key bits of information when an item is saved, added or updated. This gives you the ability to run any further processing on the data that you want – whether it be image resizing, PDF generation, text processing or goodness knows what else. And because Edditt only uses standard HTTP methods and JSON objects, you can write the web hook in whatever language you like. 

The crux of it is: Edditt likes to get out of the way and let you do the job you enjoy – developing sites. We’ve developed the system to give you everything you need and more to make any website content managed, without having to jump through hoops to do it. 

Right now, we are putting the finishing touches to the Edditt website, along with the documentation needed to support a system this flexible. That means we’ll be launching soon! To be amongst the first to know, follow us on Twitter or sign up for updates.

So when you set up a site on Edditt, all we store on our servers is the connection information, and user data (so users can persist across site instances). 

Aside from that, absolutely everything else is stored in your website’s database. It’s right there for you to see; you can even edit the database directly (though we can’t be responsible for the consequences!).

Portability

Should you decide Edditt isn’t the system for you and you want to move to another CMS, you don’t need to ask us, get an export, or any of that hassle – your database is right there, with all your data stored in it. Just make it work with the new system. 

We mean it when we say that we are totally hands off: you are in control and you call the shots. We don’t want to tie you down or trap you in any way.

And when we store information, we don’t hash it or obfuscate it, we use standard cross–language ways of storing it, like JSON.

Giving you options

Because you can see and access all the data, it gives you lots of options for how to approach a site build.

Say you just use the same module structure over and over, you could of course use the Kernel feature in the system. Or you could just copy the module information from one database into the other and change the site instance ID. And voila! The same modules will appear in both sites.

Or say you want to pull down rollback data for an item and process it in some way. Just query the database and do your processing. It’s all there waiting for you.

Edditt is all about giving you options and letting you take control. Truly owning your data is just one way we help you do just that.

Have you ever got an email from one of your clients with a subject like “Help?!” or “Page is missing” and containing a well worded but frantically typed story about how some extreme circumstance caused them to accidentally delete a page from their website (despite the 2 confirmation messages they have to click to do that).

Well, with rollback those days are gone, gone, gone.

Making your life easier

Rollback saves a version of the page every time a change is made or when it is deleted, giving a full versioning history of the item up to as many days in the past as you want (or forever). 

This means if you want to revert to a previous version of a page, you just rollback to the version that was right. Or, if an item has been deleted, you can just reinstate it to the system. 

Simple.

Its always there for your clients to see, so they can edit their site with the confidence of knowing that any changes they make can be reversed with the click of a button. Its effortless.

And thats not all it does.

Comparing changes

You can compare changes between different rollback versions of the same item, so your editors can see what edits have occurred. You can even hook up a visual view of the changes so that they can be seen on your client’s site, colour coded to indicate what happened where. 

If your site has an editorial or approval team they will love this feature. Even more so if you combine it with the built in authorisation system.

So there you have it, two killer features that make you (and your clients) life that much better. Whats more, rollback and compare changes are built into every instance of Edditt straight out of the box – you don’t need to set them up, and you don’t need to pay anything extra to switch them on. 

Don’t you just love us?
(You should).

We set out to build a user management system into Edditt which works for all sorts of clients, big and small alike. One that gives you complete control over who sees what and who doesn’t. More than that, we set out to create one that was a bit more interesting than your average to work with.

Users and groups

We’ve given you the ability to set up both users and groups. Users, obviously enough, are individuals who can access a site and make changes to it. You can give a user individual permissions, or you can assign them to a group, in which case they inherit the permissions the group it entitled to.

Groups are a container for a collection of users, all sharing the same permissions. This makes it really easy to add new users with the same permissions, and also for you to set up a hierarchy of user types on the system (e.g. administrators, editors, section editors and so forth).

Authorisation and notification

Authorisation is a nifty feature that means when a user makes changes to the site, but you want these changes to approved by someone further up the chain before they go live they can request approval from an assigned user (or group) for their changes. That user is then notified of the changes, and can login to edditt to approve (or disapprove) of the changes. They can even choose a compare view, where the changes made are highlighted side by side with the original version of the item

We also give you the ability to be notified by email of changes that a user (or group) makes. This means every time they change, update or delete an item on the system an email it sent with information about that change – giving you real time updates about over what your users are doing.

Fine–grained control

Not everyone on your site needs to be able to carry out the same tasks, so Edditt lets you completely customise what each user (or group) can and can’t do. Its as easy as choosing Yes or No and following the process through. 

At one end of the scale you can give a user access to everything, or at the other end you can only allow a user permission to access a specific field on specific item. And in between – you control what they can and can’t do – the power is in your hands.

Anything a user isn’t able to access is hidden from their view, so as far as they are concerned, it never existed in the first place!

So there you have it, a whistle–stop tour of user management in Edditt. I think you’ll agree, its gives you very flexible, powerful control over what your users can and can’t do.

It’s something that gets asked so much there had to be an easier way to make it happen.

The Files area of Edditt doesn’t stop at connecting to and managing your site’s webspace (though it does do that particularly well!); it also connects to 3rd party services on all corners of the web. And by that we mean it pulls media seamlessly down and gives them pride of place right alongside your website’s files. 

So, be it Vimeo, Flickr, YouTube, Amazon Web Services or any other service you can think of, Edditt will sync beautifully with it, allowing users to drop rich media and content effortlessly into their website. Trust me when I say, your clients will love you for this.

And it’s not just a one–way relationship, we don’t just read your media – you can upload files directly through Edditt, cutting out the middle man. So, you can set up accounts for your clients on 3rd party services, but they never need to go near that service’s website. Seamless huh?

As for setting this all up in Edditt – well that’s pretty effortless too. Make your way to your site’s integration settings, and click on the service you want to sync with. You’ll be taken to the service’s website, login and once you come back its all set up.

We really do spoil you.

We said yes, then spent the car journey home wondering how the heck we were going to do that. You see in those days, CMSes were for the big boys, and only the big boys.

So, we planned out a simple system that worked perfectly for one site. It allowed the client to update their site in no time at all. He loved it, we got paid, so we loved it too.

About a year down the line we’d made about 16 or 17 of these. But we were growing tired of pushing out bug fixes to every one of them. Every fix meant changing every system on every site – what a pain. So we decided it was time to build a system that could power all our sites, a magical beast that centralised our content management. 

Obviously this new system needed to be more flexible, so we set up ways of adding different features to each site.

After two weeks of straight work and very little sleep, it was done. It was fantastic. Now, we could turn sites around faster than you could shake a stick. And we had all our sites in the same place; no more pushing bug fixes to a multitude of places. Bliss!

Over the next 4 years this system served us well: we won lots of jobs we shouldn’t have because of it, and it gained us a reputation at being really good at what we do. Looking back, you could say this system was Edditt version 1.0.

But all was not perfect: We started to find ourselves hitting the constraints of the system. It just wouldn’t do things that we wanted it to do; we dreaded having to make changes or add new features as it would often have unwanted consequences.

It was time for a rethink – time to start over.

This time we were serious. We had a feature list the length of your arm and it kept on growing. So we furiously started scribbling. There were pieces of paper everywhere – covered in schemas, diagrams, roadmaps and ideas. We researched other systems, we won’t name them, but we checked them out just to make sure we weren’t reinventing the wheel. It quickly became clear we weren’t. Nothing else gave us the features we were looking for and most of all, none of them seemed easy for our clients to get to grips with.

So work began in earnest. 

We set out to create a system that was flexible from the ground up; allowing each site to be completely tailored to its needs without any constraints, and giving the user the best control over their content. This system had to be able to do everything we needed it to do: manage databases, interact with 3rd party services, hook into pages on our site for extra functionality.

A few months down the line and it was ready for some serious testing, we let some clients loose on it. And they loved it. It worked in a way that made complete sense to them. They found it effortless and from our point of view that was what really mattered.

Edditt gave us a ridiculously fast development pace – we could turn around sites even faster than before. CMS was no longer a pain – in fact, it was quicker to CMS a site than not to. Who would have thought?

Over the last year we have refined it and tweaked it mercilessly, continually improving upon what we started with. We have added new features, and are planning more besides. We want to make sure Edditt takes its place as the best CMS system out there.