EES customisation

(autjoe) #1

We have just applied the EES to one of our site, works really good. However, can anyone please explain how we can add more functionality (for example, we will need to allow the editor to be able to create a new page and upload related files) and how we can customize the interface (modify the css)?
With thanks!

(Kmiller) #2

Hi Joe


The EES allows easy editing of pages on your site. To add more functionality such as creating pages and uploading files, you can either use asset builders and/or the Javascript API to create these. These would sit outside of the EES (i.e. without the /_edit at the end of the url) but you could create pages which look similar to the EES.



It's probably best not to alter the EES CSS but rather create your own additional 'manage content' css file. You could set it up in the parse file so that this css file only gets loaded when users are logged in / in a particular user group etc. You could use a similar condition in the parse file to bring through a toolbar at the top of the page to allow editors to manage their content (add pages, upload files etc.).



Let me know if you'd like some help with setting this up.



Cheers, Keith

(autjoe) #3

[quote]
Hi Joe



The EES allows easy editing of pages on your site. To add more functionality such as creating pages and uploading files, you can either use asset builders and/or the Javascript API to create these. These would sit outside of the EES (i.e. without the /_edit at the end of the url) but you could create pages which look similar to the EES.



It's probably best not to alter the EES CSS but rather create your own additional 'manage content' css file. You could set it up in the parse file so that this css file only gets loaded when users are logged in / in a particular user group etc. You could use a similar condition in the parse file to bring through a toolbar at the top of the page to allow editors to manage their content (add pages, upload files etc.).



Let me know if you'd like some help with setting this up.



Cheers, Keith

[/quote]

Thanks Keith, I got your point.

(Scott Hall) #4

There are a number of 0rsm things you can do which will not affect the core code and can easily be managed outside of the EES package and from inside Matrix:

  • Use a CSS file to override existing EES styles.
    For example, if you want to change the toolbar background colour or the matrix logo then create a CSS Design File, call it 'eescustomstyles' (or whatever you like), and then add the web path just after the ees minified css file within the parse file.[*][b]Use a JS file to add things on the fly to the interface.[/b]
    For example, if you want to add a button to the toolbar then create a JS File, call it 'eescustomscript' (or whatever you like), and then add the web path just after the ees minified js file and insert all the jQuery/JS goodness to do what you want. From September there will be some functions you can call to ensure you can add bits and pieces to the interface at the right time, at the moment you have to play around with various methods of load and/or element detection e.g. setTimeout.[*][b]Create a separate area within the site to do non EES magic e.g. asset builders[/b].
    Then add links to these from EES interface additions. For example, add new div(s) to the bottom of the EES design file code and put asset builder links into this, style it up to look similar to the tool bar and position it wherever you like, left side, bottom of screen, fly in menu etc.[*][b]Wait for September release (Phase 2) goodness[/b].
    Not that long to wait when you think about it! You'll get an asset creation wizard similar to Mini which will let you add standard page, news items and file assets. you'll also get an asset finder similar to mini's which we'll use as an asset picker from various spots to nest content and locate parent create locations etc. More to come on this keep and eye on the Squiz labs website for EES updates.

You definitely [b]do not[/b] want to touch the EES core JS and CSS code as this will most likely create problems when upgrading EES code later on.

Have fun!
(Scott Hall) #5

Need to hide/show elements based on permissions?


Step 1. (Everyone will be blocked access to 'sensitive' elements until step 2 is complete)



– Create new text file asset called 'restricted-ees-elements.css'

– Make sure the web path ends in 'restricted-ees-elements.css'

– Make live and apply public read permissions. Its OK if this one is served with a __data URL.

– Use Firebug to identify element rules to hide. The following example hides the urls screen tab:



#ees_screenMenuList .screenMenuItem a#ees_screenMenuurlsDefault { display:none; }



– Do not use !important - it's just bad practice and 99% of the time is not required, use specificity or the natural cascading goodness.

– Get the web path for the new text file asset and add new CSS link tag directly underneath the EES minified CSS reference found within the exit design area of the Design file you are using for EES.



Step 2. (System admins and root users will see reactivated elements until specific permissions applied)



– Create new text file asset called 'unrestricted-ees-elements.css'

– Make sure the web path ends in 'unrestricted-ees-elements.css'

– Make live and apply deny public read permissions. Make sure this file is served with a Matrix URL, if its under the design folder then you don't need to worry, otherwise set 'Allow Unrestricted Access' to 'No' on its details screen.

– Copy and past the code from the text file created in step 1 and activate areas for advanced users, the example below 'reactivates' the URLs screen:



#ees_screenMenuList .screenMenuItem a#ees_screenMenuurlsDefault { display:block; }



– Do not use !important - it's just bad practice and 99% of the time is not required, use specificity or the natural cascading goodness. Because this file is added after the one above, cascading will be your friend.

– Get the web path for the new text file asset (make sure it is not using __data) and add new CSS link tag directly underneath the link tag you added in step 1.

– By default sys admins and root user will now see 'reactivated' elements until you apply specific permissions for users/groups.





The obvious security questions might be raised about people skilled enough to show these areas using web diagnostic tools and being able to still interact with these areas, a couple of answers to that:

  1. The user needs to be authenticated to start with e.g. the need a matrix login and have min write to interact with any of the EES screens.
  2. All changes they make are logged as per existing matrix functionality, so your little hacker won't go noticed.
  3. This solution is for hiding 'advances' elements from basic authors it assumes the kind of authors who would have the skills to figure this out would be admins or advanced matrix users.
  4. This is a rapid imp option, for anything more robust use custom JS to remove or customise these elements. Don't edit the core, there are other ways to do things.



    Be careful when hide/showing or dynamically removing elements, test the interface after each one to make sure we don't expect it to be there for our code, you should be fine to use this approach to hide such things as toolbar icon, screen tabs, delete icon etc.
(Scott Hall) #6

As of today (8 Sept 2010) we have provided some new pages in the EES manuals to help out. The JS event manager for custom plugins is only available in EES Phase 2 for 3.28.3+. Also, your current image variety triggers wont work, and may even create unexpected errors when trying to add a new image via EES, so please turn off any current triggers you have and use the link below to create a new EES specific one.


See:



– Customisation hints and tips via CSS: http://manuals.matrix.squiz.net/ees/chapters/css-customisations

– Customisation hints and tips via JS: http://manuals.matrix.squiz.net/ees/chapters/css-customisations

– Getting image variety triggers to work with EES: http://manuals.matrix.squiz.net/ees/chapters/css-customisations