I discovered this problem when working in the excellent Wygwam WYSIWYG editor (based on CKeditor). Wygwam has it's own file management system which makes it easy to add images into an article, however, I was finding large chunks of my HTML were getting trashed upon saving, when the article contained more than one image.
It took a lot of retrying and examining the rendered code to see what was happening. Basically, when adding an image to an article via Wygwam's file manager, it adds an inline style for the image's dimensions (not exactly desirable, but there appears to be no choice in the matter). Upon submitting the article, EE's XSS filter would strip part of the code out. Where it should read:
<img alt="" src="http://www.website.com/images/1.jpg" style="width: 719px; height: 113px;" />
The final page source looked like this:
<img alt="" src="http://www.website.com/images/1.jpg" 719px; height: 113px;" />
The page rendered ok on the face of it (modern browers cope well with minor errors), but the real problems start when you re-open the article for editing again in SafeCracker: Wygwam was attempting to correct the errors in the HTML, often with disastrous consequences:
<p><img a="" adding="" all="" allowing="" also="" alt="" and="" appointed="" are="" are:="" at="" backed="" beauty="" becoming="" brand="" breeds="" business="" business.="" by="" commitment="" company="" confidence="" core="" covering="" currently="" dealt="" develop="" east="" england="" ensure="" europe="" even="" exclusively="" expanding="" fact="" field="" following="" full="" full-time="" fully="" greater="" have="" height:="" home="" img="" in="" is="" its="" julie.="" know="" leads="" maintains="" market="" most="" needs="" north="" obviously="" of="" our="" own="" paramount="" post-soviet="" potential="" pro="" professional="" professionals="" qualified="" reach="" recruited="" represent="" requirements="" right="" sales="" salon="" salon.="" sam.="" src="http://www.website.co.uk/images/image.jpg" staff="" state="" statement="" steadily="" still="" success="" supportive="" team="" territories:="" the="" their="" therapists="" they="" this="" through="" throughout="" to="" trainers="" training="" uk="" uk.="" ultimately="" up="" we="" when="" whilst="" who="" whole="" will="" with="" year="" your="" /></p>
Thankfully this problem has been partially addressed in EE - hopefully this will be developed further into some working SafeCracker parameters at some point in the future, but for now a core file modification is the only way around it.
REMEMBER: Always backup your website before making any core changes to your files!
You can disable the XSS filter globally for a set of defined field types, or specify individual field IDs if preferred. If you are using SafeCracker to allow public entry where they is a potential security risk, I recommend specifying individual field IDs so that you can target just your admin SafeCracker forms.
First, you'll need to open the following file on your server for editing:
/system/expressionengine/modules/safecracker/libraries/safecracker_lib.php
Now locate line numbers 2572 and 2573 (or around this area) - they should look like this:
$this->skip_xss_fieldtypes = array(); $this->skip_xss_field_ids = array();
If you want to disable the filter on a whole group of fields, then simply add the field types into the first array, enclosed in inverted commas, and separate each with a comma:
$this->skip_xss_fieldtypes = array('wygwam','textarea');
If you want to disable the filter just for individual field IDs, just add the IDs to the second array in the same way:
$this->skip_xss_field_ids = array('1','5','9');
Now save the file and try your SafeCracker form - you should find that EE leaves your field intact!
For simple sites like this one, Media Queries are a no-brainer - simple to add, and the basic layout allows for easy positional modifications to improve the layout on devices with smaller viewports. The target audience for the aggregator also made a compelling reason to create a responsive layout for the site - after all, there's a high probability an above average number of users will be viewing on an iOS or other mobile device.
It's just another example of how you can do cool stuff in CSS3 where you'd normally have no choice but to rely on images.
The other cool thing here is that we have loads more flexibility since we're just using ordinary images which are manipulated by the CSS - so we could use dynamic images, or slideshows quite easily inside the polaroid design, and the CSS takes care of all the tricky bits for us.
One such effect is a box, with an applied gradient to it, and an elliptical shadow. These combined effects give the impression that the box is lifting in the middle, giving a shadow beneath.
Here's how I did it in CSS.
Rich, unique designs are being published every month for keen club members to download and deploy for their own web projects, making it easy to get an amazing looking website up-and-running in relatively little time.
However, what I'm not a fan of is the way many templates are built these days.
Whilst wp_nav_menu allows us to build such complex multi-tiered menus, it unfortunately doesn't (yet) let us have as much flexibility as we sometimes need - for building more flexible split-level menus, for example.
The GA plugin in WordPress has this option, which is great for larger sites with loads of front-end admins all working on the site - you don't want to be diluting your Analytics with all that noise.
So, how can the same be acheived in Joomla? Well, quite easily actually. Read on to find out how...
Every menu link in a Joomla website has one; and they are unique to each and every link on your site.
But what if you need to style entire sections of a site based on a handful of top-level (parent) menu items?
This article explores the methodology of styling sub-level pages respective of their common parent menu links.
(more…)