Web 2.0 Widgets instead of pop-up windows. [details]
Pop-up windows have become such an annoying security risk that browsers have had to cripple them. Web 2.0 developers are rapidly abandoning pop-up windows for web-based applications. Pop-up Widgets and Tabbed Displays filled with on-demand content using Ajax and JASON techniques are becoming a new standard for making websites and web-based applications more interactive and efficient.
Widgets, unlike pop-up windows, can be docked to the side of a page, ready for use as needed. Reusable EditWrxLite widgets can be collapsed without disturbing the widget's state and can even be left open across editing of different pages.
Backups that really work![details]
The secret to safely allowing non-designers the ability to edit a website is in how that person recovers from a mistake. Whenever a user saves an edit they can check the option to first make a backup of the page. Each time they save a backup a sequentially numbered backup file is created. Clicking the Backup tool gives them the list of backup files. With the Backup tool they can open a backup in the editor to view it, overwrite the original page with any of the backups, or delete each of the backup files. Any includeblock include files for the page are backed up and managed automatically.
Most wysiwyg editors offer nothing more than the set of execCommand functions that are built-in to the browser. The execCommand function set is actually borrowed from the set used by word processors, and is quite inadequate for a web page.
Built-in forms processor[details]
The execCommand functions allow you to merely insert form elements. That's not good enough.
With EditWrxLite you can also insert the actual form element.
You can submit the form to your own custom processor, or use EditWrxLite's built-in forms processor that will email the submission to any address you provide. The email address is stored encrypted to prevent spam robots from harvesting it off your webpage.
EditWrxLite forms can be protected against robot submissions, without using annoying captcha images.
Want to do file uploads, no problem - EditWrxLite automatically adjusts the form's enctype and processes the upload internally.
More than just links[details]
Most wysiwyg editors assume you've copied the link's URL to your memory or clipboard before you attempt to insert a link.
EditWrxLite assumes that a link with a typo is worse than no link at all. That's why the Link Widget has a built-in file dialog that let's you find and identify the file to link to.
Likewise, the Widget also lists all of the anchors on the page for making typo-free Bookmark type links.
The Link Widget contains an option to Force file download for the target of any linked file. No more "Save target as..." nonsense.
Tables, Color, and Images in real life.[details]
All wysiwyg editors can insert and manipulate a table, offer a 16 million color picker, and can insert an image tag. But in real usage that's not enough.
In addition to all the usual table manipulations, the Table Widget contains a Clone button on the Row tab that copies all of a row's table attributes, html tags, and content to a new row, preserving all formatting.
Instead of offering the usual arithmetic sequence of colors, EditWrxLite offers what is known as the "named color pallet", the colors that browsers recognize by name (as well as by hex or rgb) because they are the most used colors on the web.
But, what if you want to offer users a particular set of colors for your site, or limit users to that set of particular colors? The Color Widget can be trimmed to only the site-wide colors listed by the eZwysiwg admin.
When a page is editable it is fun to grab the handles of an image and resize it. But doing so rarely results in an image that is proportionally resized. The Image Widget can resize images while maintaining the original aspect ratio. Since a docked widget retains it's state, you can insert an image multiple times if necessary to achieve the correct sizing.
Like most wysiwyg editors, EditWrxLite is ideal for the site owner who wants a quick and easy way to update pages. But EditWrxLite is also designed for the webmaster or web designer who wants to delegate upkeep to others without endangering the layout and design of the website. On a per-user basis, the admin can create 4 different types of users.
UserType 1 • User can edit any page on website - edit entire page on pages without editblocks/includeblocks and inside of editblocks/includeblocks on pages containing editblocks/includeblocks
UserType 2 • User can edit any page on website - but can edit only inside of editblocks or includeblocks
UserType 3 • User can edit only a list of pages - edit entire page on pages without editblocks/includeblocks and inside of editblocks/includeblocks on pages containing editblocks/includeblocks
UserType 4 • User can edit only a list of pages - but can edit only inside of editblocks or includeblocks
Note 1: Users who are setup to edit any page on website (1&2) may login at edit.cgi and use the File Open dialog to find the page to edit, or login from a page using the Login Prompt.
Note 2: Users who are setup to edit only a list of pages (3&4) should login from those pages using the Login Prompt.
Block editing is designed for maintaining an existing web site. [details]
Block editing allows the web designer to offer site maintenance to others without exposing basic design and layout to damage. A third of installations are on church websites that encourage members of their congregation to take responsibility for part of the upkeep. Another third are installed by web designers who are too busy/valuable to do routine upkeep. The last third are installed by site owners who prefer to do upkeep themselves. In all cases, content changes as quickly as needed, and as safely as needed.
An Editblock is an area on the page that is editable. If an editblock exists on a page, only content inside of either an editblock or includeblock can be edited.
An editblock may be a DIV tag or SPAN tag pair. The comment after the close tag is required and must contain a match for the class in the open tag. Example:
The content to edit </DIV><!-- editblock-one -->
Each class name must contain the word editblock, a dash, and a unique identifier, and MUST be in double quotes. Examples:
Main content to edit </SPAN><!-- editblock-main -->
Eleventh content to edit </DIV><!-- editblock-11 -->
EditWrxLite uses class names to identify editblocks because W3C validation will throw a wall-eyed hissy fit if the word "editblock" is used as an attribute. On the other hand, W3C validation is not sophisticated enough to know if a class actually exists for a used class name.
Although EditWrxLite uses class names to identify editblocks, it can also edit pages originally setup for EditWrx which use editblock attributes (example: editblock="one").
An Includeblock is an editable area on the page that is included into the page from an external file by SSI, ASP, PHP. Edits made inside of an includeblock are written to the file that was included, not to the web page file. The SSI, ASP, or PHP include syntax in the web page file is therefore preserved.
An includeblock may be a DIV tag or SPAN tag pair. A comment after the close tag is NOT required. Example:
Edits made inside that includeblock will be written to the /incs/some.txt file, not to the web page's file.
Each class name must contain the word includeblock, a dash, and the virtual path to the included file, and MUST be in double quotes.
Note: The virtual path must begin with a slash and must lead from the domain's home folder to the include file.
An Excludeblock is an area on the page which can not be edited. If the user is setup to be able to edit from the page's open body tag to the close body tag, excludeblocks can be placed in the page to turn off editing for that area. Example:
Content to exclude </DIV><!-- excludeblock-one -->
An excludeblock may be a DIV tag or SPAN tag pair. The comment after the close tag is required and must contain a match for the class in the open tag. Each class name must contain the word excludeblock, a dash, and a unique identifier, and MUST be in double quotes.
Likewise, an excludeblock may be placed inside of an editblock to turn off editing for an area within the editblock. Example:
Some content to edit
Content to exclude </SPAN><!-- excludeblock-one -->
More content to edit </DIV><!-- editblock-main -->
An excludeblock may also be placed inside of an included file. The excludeblock area in the included file will not be editable even though the rest of the file is editable.
Any editblock or includeblock can be turned into a Userblock. If the keyword userblock and a username, or list of usernames, is included in the class, the editblock or includeblock will apply only for the listed user(s). Example:
The content to edit </DIV><!-- editblock-one-userblock-alice,cindy -->
The above example would allow "alice" or "cindy" to edit the editblock but would prohibit "bob" from editing. The userblock permission/prohibition would apply to only that editblock, "bob" would be able to edit another editblock that contained no userblock, or contained a userblock listing "bob".
Userblocks are particularly useful for includeblocks. For example, suppose the includeblock contains the site's navigation, and suppose you want only the user named "manager" to be able to change the site's navigation: