WordPress offers six different roles ranging from Super Admin to Subscriber. There is one role that permits a user to write and manage their own posts but cannot publish them; that is the contributor. Writing a post and submitting it for approval to publish without images is as easy as it gets. Posts of that nature are rare and can get a little boring. Images help make a post more interesting.
However, as a contributor, images cannot be uploaded with the post. A number of work-a-rounds may be put into place to remedy this, but each can be a time-consuming and often repeated effort. This may not be so bad for a short post, but one with many images can be more challenging than the effort is worth.
To allow contributors to upload images with posts would greatly simplify this. One site offers a snippet of code to add to the theme’s functions.php file.
if ( current_user_can('contributor') && !current_user_can('upload_files') )
add_action('admin_init', 'allow_contributor_uploads');
function allow_contributor_uploads() {
$contributor = get_role('contributor');
$contributor->add_cap('upload_files');
}
This has been tested as working using WordPress 3.9.1. Here is an after and before screenshot of the admin board of a contributor. Notice the image on the left has a Media option.
A contributor may now upload their post with images ready for someone else to Publish. After a successful upload, from the Media option take note of a couple of differences between images submitted by the contributor and images submitted by others.
This is an image submitted by anyone other than the contributor. Notice that the contributor may only view the image and no other action may be taken.
This image has a box next to it to allow for bulk actions. The contributor may also Edit or Delete Permanently their own image as well as view it.
A second contributor account was created to verify that another contributor may only view other contributor images as well as any other image and may perform other actions on own images. The results were as expected.
It is important to note that even if the code is removed from the functions.php file, the contributor role will still have the capability to upload content. This capability is persistent until explicitly revoked. The setting is saved to the database. To explicitly revoke this capability simply reverse the action editing the code above and append to the functions.php file.
if ( current_user_can('contributor') && current_user_can('upload_files') )
add_action('admin_init', 'remove_contributor_uploads');
function remove_contributor_uploads() {
$contributor = get_role('contributor');
$contributor->remove_cap('upload_files');
}
Although the functions.php may be modified with either of the pieces of code provided above, a cleaner and more portable method would be the use of custom plugins. One plugin to enable uploads and another to disable them. That could be the topic of my next article…
A Gold Copy is an image of a fully patched and Custom Configured Adobe CQ instance that leverages the use of run-modes and sling:OsgiConfig nodes. Once established, the Gold Copy can be “cloned” by System Administrators to efficiently create reliable subsequent installations.
Gold Copies, commonly used in the DBMS world, are still catching on in the world of CRX. This is surprising when you consider how valuable they can be when something goes wrong, or in situations as routine as adding a new instance when a new developer joins the team.
run-modes [1] allow you to tune your AEM instance for a specific purpose such as: author, publish, test, development, intranet or others. By default, every Adobe CQ instance has to be one of two types: author or publish. These can be extended to address specific needs, for example: author,developer (author instance for developer’s local instances); author,qa (author instance for Quality Assurance instance); publish,preprod (publish instance in pre-production environment); or even much more specific settings like publish,production,us (production instance for publishing content in the US).
To start an instance in different run-modes, use one of the following methods:
quickstart file name: you can provide author or publish run-modes only (depreciated)
-r parameter: when running the java -jar… command you can add -r parameter to set the proper run-mode. For this you must rename your quickstart file to something like cq-quickstart-p4503.jar and provide -r option to the java command, ie: java -jar cq-quickstart-p4503.jar -r publish,qa -gui (publish instance for quality assurance)
edit …/crx-quickstart/conf/sling.properties
edit start up script under bin folder (preferred method)
sling:OsgiConfig [2] nodes allow you to store configuration parameters for almost all bundles. This is the preferred method as opposed to manually accessing properties dialog box for each bundle in Adobe Web Console (Formerly known as Apache Felix Console).
Here are the steps to set configuration using OSGi config nodes in the repository:
under /apps create a config sling:folder node for configuration affecting all instances (run-modes)
under /apps create a config.publisch.qa sling:folder node for configurations affecting quality assurance publish instances
under the newly created node create a new node for each OSGi PID you wish to configure; these node have to be of type sling:OsgiConfig
add properties to the newly created nodes with the values you want to set such properties to
There are four major areas of configurations that System Administrators must deal with when installing Adobe CQ for the first time or when restoring a crashed instance. These areas are as important as having a healthy running instance. Blogs 2-5 will cover these sections, and they are: custom configurations, sanity configurations, security configurations and optimization.
Custom Configurations:
Install Service Packs
Remove Geometrixx Web site
Modify Start Script
Change admin password
configure Forward Replication Agent
configure Reverse Replication Agent
configure flush Agent
mappings configurations
clustering author and publishers
dispatcher configuration
Sanity Configurations:
version purge
Custom Bundles’ log
CQ WCM page statistics/CQ multivariate statistics
CRX Bundle cache Size
DAM renditions
CQ HTML Library Manager Settings
Email Service Configuration
Security Configurations:
remove Geometrixx users
change password to default users
create users for replication
add clickjacking headers
disable WebDAV access
disable CRXDE Light access
disable Debug Mode
protect against Cross-Site Scripting (XSS)
prevent Denial of Service attacks (DoS)
Optimization:
Optimize Tar Files
Merge Tar Index Files
Consistency Check and Fix
Run Garbage Collector
Check Datastore consistency
CSS and JS minify
CRX search index’s resultFetchSize param
TarJournal File Maximum size
Set logging level
Apache Sling JSP Script Handler
Apache Sling Java Script Handler
CQ HTML Library Manager Settings
Day CQ HTTP Header Authentication Handler
The crx-quickstart folder we will get after unpacking and applying all configurations described in all 5 parts of this blog (“Creating a Gold Copy of AEM/CQ instances“) will become our Gold-Copy.
Suspense builds. Tension unbearable. As the cards turn…it is, of course, Miss Scarlett (the old fishmonger, Mustard, was never cunning enough to pull this off), with the rope in the (WHAT?!) Library… Those of you with fond childhood, or more recent, memories of Cluedo would have surely related to today’s EMC/Fatwire partnership news. In the worst kept secret category, EMC has effectively chosen to supplant its own Web Content Management (WCM) offerings with Fatwire’s, best in class, offering and in-turn chip in with some DAM going the other way, and, interestingly, only take a minority equity stake at Fatwire.
