Projekt:Customization

This starter pack has a wide variety of new ui text. Especially the new german texts use "Sie" instead of "Du" as a new "feature". Here are the files, you probalby wish to customize before you take this wiki productive:

Inhaltsverzeichnis

1 Access control
2 MediaWiki configuration settings
3 Boilerplates for new pages
4 System messages
5 Some predefined Editsummaries
6 Extending SMW
7 Start your own subproject

Access control

At startup, the wiki is only accessable for your admin user. You have to assign roles or permissions to at least one security group.

Remember in your ./_config/Localsettings_acls.php file:

 87 ## Access control
 88 # public or not
 89 # by default, content can only be viewed after a successful login
 90 # with this setting, however, your wiki is free to READ for all:
 91 #$wgGroupPermissions['*'] =& $imtDefaultRoleReader;
 92 # if you configured the use of img_auth above, you also have to uncomment this:
 93 #$wgImgAuthPublicTest = false;
 94 
 95 # access roles: you can assign default roles or use an array with custom rights
 96 # default roles are: $imtDefaultRoleContributor, $imtDefaultRoleCurator, $imtDefaultRoleDevelope, $imtDefaultRoleAdministrator, or $imtDefaultRoleMaintenancebot
 97 # note:
 98 # * 'user' (the group of authenticated user) already has the role contributor
 99 # * 'imt-mediawiki-maintenance' (ldap bot accounts) already has the role maintenancebot
100 # also remember: an ldap group used here must have the ldap group attribute 'Wiki Gruppe'
101 #$wgGroupPermissions['sample group'] =& $imtDefaultRoleAdministrator;
102 
103 # you can restrict login to a list of groups (each of which has its users added to wiki group 'user' automatically)
104 #$imtGrantAccessRoles = array( 'sample_group' );
105 
106 # you can also deny access for a list of groups
107 # remember: an ldap group used here also must have the ldap group attribute 'Wiki Gruppe'
108 #$imtDenyAccessRoles = array( 'blacklist_group' )

Public access

The first segment lets you give your wiki public access. Just uncomment lines 91 and - if you use img_auth.php - line 93. Everyone can read your wiki now.

Line 95ff lets you assign permissions to security groups in more detail.

Roles

Of the predefined roles, each role has the permissions from the role above. They are in order:

$imtDefaultRoleReader: This role has only the right to read pages.

$imtDefaultRoleContributor: This role can create and edit pages and images as well as set some user preferences.

$imtDefaultRoleCurator: This role has some basic page curation permissions, for example: (un)delete or move pages, reupload images. It also can write in Namespace help.

$imtDefaultRoleDeveloper: This role has also the permissions to write in the namespaces Mediawiki, Form, Tempalte and Module.

$imtDefaultRoleAdministrator: This is the administrative role that has all encompassing permissions. Make sure you assign this role to at least one of your groups.

Security groups

You can either use a mediawiki local security group (can have any name) or - if you use the ldap plugin - an ldap group name. Note that at the upb, ldap groups need to have the attribute "LDAP Gruppe" for this to work.

You should assign roles to groups by reference so that changes to roles later will be reflected in the groups permissions.

Manual permission assignment

You can also assign permissions manually. It will look like this:

  $wgGroupPermissions['mygroup']['read'] = true;
  $wgGroupPermissions['mygroup']['edit'] = true;
  $wgGroupPermissions['mygroup']['move'] = true;

You can find a list of all configuration settings here: http://www.mediawiki.org/wiki/Manual:Configuration_settings. If you want to add them, please put them in ./_config/LocalSettings_host.php before the comment shown in line 104.

Login restrictions and blacklisting

If you are using the LDAP plugin, you can resptrict the login to a list of groups rather than all users with an account. Just uncomment line 105 and include all group names in the array.

Note: No matter what, a user needs at least read permissions. If you do not restrict the login to certain groups but set your wiki non-public, a user with an account will not be able to login except if he is assigned a role or at least read-permission or in an ldap group with a role or read permission assigned.

You can blacklist in a similar way, just uncomment line 109 and list all groups you wish to blacklist. Users in a blacklisted group will be denied login. What that means depends on your type of wiki. For isntance they will still be able to read in a public wiki but probably not be able to warite anything. In a private wiki, they will not be able to view anything at all.

MediaWiki configuration settings

You can find a list of all configuration settings here: http://www.mediawiki.org/wiki/Manual:Configuration_settings. If you want to add them, please put them in ./_config/LocalSettings.php at the very end in the section

######################################################################################################
#                                                                                                    #
#                                    C O S T U M I Z A T I O N                                       #
#                                                                                                    #
######################################################################################################

Boilerplates for new pages

Only if you added the Boilerplate package on import contain these pages the text, that will be preloaded when creating new pages in the corresponding namespace:

Template:Boilerplate for the default page namespace
Template:Boilerplate_category for category namespace
Template:Boilerplate_file contains a warning, not to create a page in filespace "file". Is NOT displayed when uploading a file
Template:Boilerplate_meta for namespace meta
Template:Boilerplate_help for namespace help
Template:Boilerplate_property for namespace property
Template:Boilerplate_user for namespace user
Template:Boilerplate_talk for talk pages
Template:Boilerplate_template for namespace template

Preloading ignores texts between <includeonly>...</includeonly>.

If you want to have preloading text for an additional namespace, you have to do this:

Edit ./_config/LocalSettings_extensions.php, search for the section #Preloader and add the following line to the list of preloader boilerplates:
```
$wgPreloaderSource[ <NAMESPACE_CONSTANT> ]         = 'Template:Boilerplate <namespace name>';
```
Where <NAMESPACE_CONSTANT> is the mediawiki constant depicting the namespace you want the boilerplate for. If the target namespace isn't one you created on your own, please refer to https://www.mediawiki.org/wiki/Extension_default_namespaces for a complete list of predefined namespaces.
Create a page called Template:Boilerplate <namespace name> in your wiki and fill it with the preloader text.
Please note, that text in <includeonly>...</includeonly> tags will ignored when preloading, so use it to categorize and document your boilerplates. The default category for boilerplates is Category:Preload text templates.

System messages

MediaWiki:Sidebar is your left hand main navigation bar

Default language

Depending on what language package you imported for default language these are either german or english

MediaWiki:Badaccess-groups, where you can disable the display of necessary groups for a certain action
MediaWiki:Cascadeprotected, a help page for (cacascade)-protected pages. Should display links for help pages and a working target for the "Submit an edit request"-button. See also the template {{Protected page text}} for more customization on this message.
MediaWiki:Editpage-head-copy-warn, a message displayed above the textarea when editing an existing page. Link here to help pages and helper templates
MediaWiki:Newarticletext, the note displayed above the textarea when creating a new article. Here you could add links to existing forms as alternative to manual creation (of course, only when using forms)
MediaWiki:Noarticletext, the text displayed when surfing to a non existant page. Add some links to your lokal help pages. When using semantic forms, this is also a good place to reference existing forms.
MediaWiki:Noarticletext-nopermission, same as before. Is displayed at a non existing page where the user doesn't have the rights to create the page
MediaWiki:Nocreatetext is displayed for anonymous user, if you disallowed creating new aricles for them. Please link to help pages for rights policies
MediaWiki:Protectedpagetext, a help page for protected pages. Should display links for help pages and a working target for the "Submit an edit request"-button. See also the template {{Protected page text}} for more customization on this message.
MediaWiki:Semiprotectedpagewarning
MediaWiki:Tagline is the line displayed right below the page title. Please costumize but do not leave empty. This would both up some vector stylings.
MediaWiki:Uploadtext is displayed every time some is uploading a file. It is a rather long text concerning naming conventions and adding file descriptions. Just fit them to your policies.

English

Please refer to Section "Default language" for the description. When you use english as your wikis default language, you can ignore these pages.

German

Please refer to Section "Default language" for the description. When you use german as your wikis default language, you can ignore these pages.

Templates (all languages)

The "Protected page text"-templates display text for protexted pages. They contain suggestions for the user, how to proceed. You should link your help pages and maybe add some indivudual guidelines.

Some predefined Editsummaries

With the Gadget defaultsummaries you can give users an assortment of default edit summaries, increasing the chances they add summaries. You can edit the list here: MediaWiki:Gadget-defaultsummaries.js.

Extending SMW

You can add some more Semantic Special Properties for pages. Here is how!
Add some nice Semantic Result formats!

Start your own subproject

This platform comes with a wide variety of templates and modules. It gives you a good working base to start your own project. If you want to build your own sub-project, it is recommended, that you use the already prepared file structure. Just switch to

 ./_opt/init

You'll find this structure:

drwxr-xr-x 6 www-data www-data  4096 Dec  8 13:43 base_content           // here you find all base packages. imported automatically by script init
drwxr-xr-x 2 www-data www-data  4096 Nov 16 09:49 base_images            // here you find all base images. imported automatically by script init
-rw-r--r-- 1 www-data www-data 53212 Nov 16 09:49 db_init-binary.sql     // this generates your db structure, if you use collation binary (done by script init)
-rw-r--r-- 1 www-data www-data 54337 Nov 16 09:49 db_init-utf8.sql       // this generates your db structure, if you use collation binary (done by script init)
drwxr-xr-x 2 www-data www-data  4096 Dec  8 13:43 local_content          // place your project's .*list files here. update_content will use this list files to dump
                                                                         // your content. script init will ask whether to import xml-files located here
drwxr-xr-x 2 www-data www-data  4096 Dec 16 12:53 local_db_init          // if you have sql files to be run by script init, place them here
drwxr-xr-x 2 www-data www-data  4096 Nov 16 09:49 local_images           // place your project's image files here. script init will ask whether to import these or not
-rw-r--r-- 1 www-data www-data     0 Dec  4 15:57 use_script_'update_content'_to_update_your_content

A short howto:

create your new project on a dev system
branch. either from master or swm_core
if you have special sql requirements, place these files in local_db_init to be included by script init
put your list-files in the directory local_content
1. remember: you can easily place a category name in the list file, update_content will dump all files in that category
2. if you want only the category, preface its name with a double colon ":"
run update_content to generate your dump files. run url first, to see if your scripts have the correct source system
place your projects images in the local_images directory
commit your changes in the new branch.
your project is ready to be deployes (and filled with content)

If there is a change in branches master or smw_core, merge them with your project and redeploy. If you make changes to your project's template/module pages, just repeat steps 4 to 7 and redeploy. Include changes in target systems by running script import_dumps in the directory base_content or local_content respectively. You can import new images with the corresponding mediawiki maintenance script.

Hint: Most scripts have a user help. Just use parameter --help