It's better when it's simple

User Tools

Site Tools



This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
tips:homepages [2012-01-25 16:55] old revision restored
tips:homepages [2020-05-12 17:11] (current)
gholk add her because previous comment use her too
Line 1: Line 1:
 ====== How to create user homepages ====== ====== How to create user homepages ======
-| Author: | [[|Oliver Geisen]] | +DokuWiki can be configured so that it links user's name to a user's personal wiki pageAdditionally the ACL rights for these user pages can be set precisely to your wishes. 
-| Overview: | Create homepages for dokuwiki-users without the need of complex ACLs | +
-| Based on: | dokuwiki-2006-03-09 | +
-| Plugins needed: | none |+
-**:!: Please note: This TIP is a simple hack. It would even be better to think all over and find a better solution to provide homepages for users, especially the way to authorize the namespaces they are in. Maybe a variable like %USERID% could be used in ACL.**+==== User's name linking to homepages====
-updatejust use %USER% in your acl.auth.php, it will be subsituted by the current logged in user, and include **tpl_link(wl("user:".$INFO[userinfo][name],'do=show'),"My homepage");** to your template.+The [[config:showuseras]] config setting can be set to "User's full name as interwiki user link"Setting this option will display all the usernames in the wiki with a link to the ''user:<loginname>'' page 
 +The default location of the user page can be modified via the [[:interwiki]] configuration.
-===== Motivation =====+==== ACL for user pages ==== 
 +The access permissions for the user pages can be set with some configuration lines. The Access Control List (ACL) of DokuWiki can handle two placeholders ''%USER%'' and ''%GROUP%''. The placeholders are replaced by the loginname or respectively the group of current logged-in user. This allows to define generally with some lines for all users the wanted read and write access.
-We (dokuwiki admins) want to give our dokuwiki-users the ability to create their own homepages. These should be in their own responsibility and therefore in their own namespace. The user may create as many pages as he want inside this namespace (Think twice: "should'nt there be some kind of quota ?"). Each user created with the usermanager should be provided with a namespace dedicated to him and a simple starting templateAlso there should be a "My page" button in the navigation bar, so users can easily access their pages.+Currently ''%USER%'' and ''%GROUP%'' cannot be used via the [[plugin:config|Config Manager]]. Therefore you need to manually modify the file ''conf/acl.auth.php'' to add the lines using them
-===== How is it all done ? =====+**Tip:** Create first the desired line for one user page using the Config Manager. Next you modify the user page config line by replacing the loginname by the ''%USER%'' placeholder.
-Each page the user see's is requested from the browser like+Example
- +<code - conf/acl.auth.php> 
-  http://<server>/doku.php?id=<wiki-path+# Additional lines for conf/acl.auth.php : 
- +# 
-doku.php itself will initialize some environment, sets global variables, checks ACLs and will then call main.php from the currently selected template, which is found at+# user can modify/delete page in his/her namespace 
- +user:%USER%:*          %USER%  AUTH_DELETE  
-  lib/tpl/<template>/main.php +user can create/delete his/her own page 
- +(AUTH_EDIT is not enoughbecause page is not exist before
-So we must decide where to hack the code: Inside ACL checking or where page is shown. I decided to do all the work needed just before the page is shown because I want to keep ACLs clean and simple. Therefore we must make some decicions now: +user:%USER%            %USER%  AUTH_DELETE 
- +# all logged-in users can read the user pages 
-  - Where should the homepage namespace be ? +user:                @user   AUTH_READ
-  - Should other users have access (mostly read-only) to homepages ? +
- +
-I decide to: +
- +
-  * start my user namespace at''home:'' (just like unix do) +
-  * keep users pages private. In order to edit the pages add <code>home:*  @ALL    0 +
-home: @user   16</code> to conf/acl.auth.php. +
- +
-===== Extend ACL if user requests his own homepage-namespace ===== +
- +
-The next challenge was to find the place in code where user should be given full access to his namespace. We've discovered that main.php is called at least, so let's look inside and we found a call like: +
- +
-  <?php tpl_content()?> +
- +
-Let's do a simple grep-search inside the dokuwiki base-directory to find the lib which exports this function: +
- +
-  grep -r "function tpl_content"+
- +
-The answer is: ''inc/template.php''. So lets look inside the function and determine how it works. It imports some globalswhere $ID contains the wiki-url to the page requested and $ACT the thing to do (mostly "show"). +
- +
-So this leads us to "html_show()", which we can find, using grep-search like before, inside "inc/html.php". Further look show that it simply displays/renders the wiki-source-text, so this is too deep to implement the code needed. I decide to put in into "tpl_content()" right after the global definitions: +
- +
-<code php> +
-  ... global imports ... +
- +
-  // if $ID (requested page) starts with 'home:' and we are not the "admin" do some extra checking +
-  if((substr($ID,0,5== 'home:') && ($INFO['perm'] != AUTH_ADMIN)){ +
-    $userid = $_SESSION[$conf['title']]['auth']['user']; +
-    $allowed = 'home:'.$userid.':'; +
-    // if user requests the page of another users homedir, deny access to it +
-    if(substr($ID,0,strlen($allowed)) != $allowed){ +
-      print p_locale_xhtml('denied'); +
-      return; +
-    } +
-  } +
-  // only admins, users requesting pages from their own homespace, or users requesting other namespaces will get here +
- +
-  ... regular code continues ...+
 </code> </code>
 +More about ACL and wildcards, with examples at: [[:acl#User wildcards|ACL User wildcards]].
-===== Add "My page" button to navigation bar =====+====Prefilled template==== 
 +You can create a template page, which is put in the edit window when an user creates his/her user page. Here you can suggest some minimal content you like the user completes.
-Add the code to display the new button inside main.php of the template:+See at [[:namespace templates]] how to create your namespace templateWhen you create a template for the default ''user:<loginname>'' pages, you want to create e.g. ''user:_template.txt'' via your filesystem. 
-<code php> +**Tip:** If you would like to modify the namespace template via the browser, you need the plugin [[plugin:Templatepagename]]. This plugin lets you configure via the [[plugin:config|Configuration manager]] a page name that is recognized as template page. Default ''c_template'', but of course you can choice your own name.
-  <?php tpl_button('mypage') ?> +
-Now let's find out where tpl_button comes from. Just use grep-search again and see it'inside inc/template.php (haha, surprise surpise, who had thought that all functions prefixed with "tpl_" comes from template.php ;-)))+=====See also===== 
 +  * Customizing [[:interwiki|Interwiki links]] let you modify the user page location 
 +  * Change [[config:showuseras]] config setting to use the user'name with interwiki link to its homepage. 
 +  * [[:ACL|Access Control List]] (ACL) about configuring access permissions. 
 +  * [[:Namespace templates]] for prefilling content in new pages
-Ok, i just added a new case-statement for my button: +\\ \\ 
-<code php> +
-  ... +
-  case 'mypage': +
-    $uid = $_SESSION[$conf['title']]['auth']['user']; +
-    $id = 'home:'.$uid.':index'; +
-    print html_btn('mypage',$id,'u',array("do" => "show")); +
-    break; +
-  ... +
-Next, we need to add the button-label for "mypage". A quick look inside "html_btn" (which is found in inc/html.php) shows that each label is prefixed with "btn_", which results in "btn_mypage" in our case, and is looked up in the language-file. This is found at:+===== How ToAutocreate homespace for users =====
-  inc/lang/<language>/lang.php+|:!: Please move this example into a plugin|
-Here i append a new line containing: +Use case: Because users are not able to create an own page in namespace "user:" in our wiki setup, we must provide them one. Best place to do this is when adding the user with the usermanager. The usermanager is a default plugin of DokuWiki and it's code is found at:
-<code php> +
-$lang['btn_mypage'    = 'Meine Seite'; +
-</code> +
- +
-**Please note "Mein Seite" is German. Just put whatever YOU want, of course ;-)** +
- +
-Now you can try it, and find a good place for the button inside main.php. +
- +
-===== Autocreate homespace for users ===== +
- +
-Because users are not able to create own namespace in "home:" we must provide them one. Best place to do this is when adding the user with the usermanager. The usermanager is a default plugin of dokuwiki and it's code is found at:+
   lib/plugins/usermanager/   lib/plugins/usermanager/
-Next we must find the place where the new user is created to add our code to create the homespace as well. In the "handle()" function we found a case-switch with a ''case "add"    : $this->_addUser(); break;'' - this is our man! +You can create the functionality by doing changes in ''[[xref>lib/plugins/usermanager/admin.php]]'':
- +
-So lets follow the call to the function "_addUser()". It first gets data from the POSTed form, which normally contains the params of the new user to be created (name, mail, password, etc.). Next it wraps to ''$this->_auth->createUser($user,$pass,$name,$mail,$grps);''. This function is not contained here, because "_auth" is another object which will be dynamically set by the choosen authentication method. +
- +
-I use "plaintext" authentication so i found out that inc/auth/plaintext.php is the place to search for "createUser". All this function do is to add the credentials given to the "user database" and returns "false" if the user already exists, "null" when an error has occured and "true" if everything went well. +
- +
-Because our solution should not depend upon the selected authentication method, it's best to add it to the usermanager code. The problem here is how to build up the path to the namespace for the user to create with mkdir (or better io_mkdir_p() from inc/io.php). +
- +
-So lets start thinking reverse again. What happens if one clicks on "Create page"? Yes, a page opens with an empty editfield and a "Save" button under it. This buttons is worth a closer look, so check HTML-source and found out that it will call doku.php with "do=save" and "id=<pageid>". Now i go all the way through doku.php down until inc/actions.php where "save" is handled and came up to the function "act_save($ACT)". After a few checks it will call "saveWikiText(...)" which i found in inc/common.php. +
- +
-Here i found two very interesting things: +
- +
-  - the call to "wikiFN($id)" which in result gives us the full path into the local filesystem, where page $id is/should be stored +
-  - and the call to "io_saveFile($file,$text);" which will store the wiki-page into $file, where all needed dirs will be created +
- +
-For now "io_saveFile()" seems of interest and i found it in inc/io.php. There i found how it's done. The call to +
- +
-  io_makeFileDir($file); +
- +
-creates the needed directory structure upon the given filepath. So this is the function to use in the usermanager plugin. +
- +
-Now all there is to do is just create the path to the wanted namespace-id, which is in our case "home:<userid>:index", and create the directory. +
- +
-//One note about the wikiFN-function. If the last part of the argument given is ':', it results in a path where the element just before the ':' is suffixed with '.txt'. I think this is an error, but maybe not... just keep this in mind ! For heavens sake "io_makeFileDir()" expects also a file as last argument, so there is no problem at all.// +
- +
-Now it's time to fill our code into the appropriate functions of /lib/plugins/usermanager/admin.php:+
-==== append new function ====+=== append new function ===
 <code php> <code php>
-    /*+    /**
      * Create homedir (namespace) for user      * Create homedir (namespace) for user
      */      */
Line 166: Line 86:
 </code> </code>
-==== change _modifyUser() ====+=== change _modifyUser() ===
 <code php> <code php>
Line 177: Line 97:
 </code> </code>
-==== change _addUser() ====+=== change _addUser() ===
 <code php> <code php>
Line 188: Line 108:
 </code> </code>
-===== Comments ===== +===General note=== 
- +Please read everything carefully and be aware that if you change the sourcecode of DokuWikithat you need to update it every time DokuWiki is updated.
-Ok, thats it! Please read everything carefully and be aware that if you change the sourcecode of dokuwiki, you are unable to upgrade easily. +
-  * This should become a standard feature.  I created a namespace for myself on the one doku installation I have, but, I just did it by symlinking a dir in my /home in /var/lib/dokuwiki/data/pages.  I had to chown it to wwww-data.  This bought me more space, too, since / only had 20gb and /home had 180gb.  But automagically creating a userpage/profile (à la mediawiki?) and a namespace for users seems incredibly useful to me. [[|tazman]] 
tips/homepages.1327506927.txt.gz · Last modified: 2012-01-25 16:55 by