Deprecated - Documentation

I wanted to post our tinymce settings for others to reference and review. This is just a guide based on our experiences. As always, your implementation might be different based on your needs.

Please let me know if you see anything that is potentially bad:

Access

Authenticated users and above get to access tinymce.

Profiles

Our current practice is to run two user profiles:

1. editors
Any roles that are considered administrators or content editors get this.

2. default
Authenticated users, etc.

Both of these have the default settings with the following notes:

• Default state is true
• Allow users to choose is true
• Safari browser warning is true

Buttons

Both have the following buttons turned on:

• Bold
• Italic
• Underline
• Strikethrough
• Justify left
• Justify right
• Justify center
• Bullet list
• Numbered list
• Outdent
• Indent
• Undo
• Redo
• Link
• Anchor
• Cleanup
• Sup
• Sub
• Hr
• Remove format
• Charmap

We also give editors the image button. The reasoning behind this is that we have a structured image on most of our nodes, and the image button has the potential to break the interface when users reference very wide images.

Hi.

I was wondering if there's some sort of *visual* Drupal documentation available...e.g.: an infographic or visual overview of the Drupal architecture, an image or diagram showing Drupal basics or workflow, etc. Anything...?

Thanks,
Martin

Under the heading Handbooks can I suggest a new heading called Using Drupal for users.

This new Handbook sections would be targeted at Regular Users rather than developers and hard core users.

This new section (with a small introduction) might have a number of headings such as;

karencha

Suggestions for the next version of the Contribution page. Ref.
http://drupal.org/node/21779 ,
(which resides inside http://drupal.org/node/10257)

I suggest adding something like the following to encourage and use as reference in/for discussions:

***********************
"Contributions may come in many different forms, some visible/noticable, others may never be known in general. Many (or most?) happen in daily talks etc. which rarely are visible at for example Drupal.org. This does not make them less valuable, though, and the Drupal community values them all.

Here are some examples on valuable contribution forms. Anyone may pick as many or few as they fancy, and still feel proud of taking part in helping the Drupal community:

- code: contribute modules
- help test beta releases, modules, fixes/patches, etc. and report what works and what does not
- file bug reports
- report about security issues, including advicing existing Drupal sites to upgrade when security upgrades are released.
- make feature requests
- documentation, screenshots, etc.
- inform about documentation improvement potential (suggestions as well as writing yourself, both are valuable. A person who can come up with a good idea is not necessarily fit for writing it in documentation form, and the ones skilled in writing good documentation can never come up with all the good ideas for improvement themselves, so don't be ashamed of suggesting without writing it yourself.)