Platinum sponsors
You can use the backend module to configure the categories and boards in the mm_forum. To do so, select “Board administration” from the drop down list. In this view, you will see the whole forum structure in a tree view. On the first level there are the categories, while on the second level the subordinate message boards are listed. To create a new category, just click on the New Category item in the tree view. To create a new message board, click on the New Forum item in the child branch of the category you want to create a new forum for. To edit a category or message board, click the regarding object in the tree view.
In both the category and the forum forms you have the following input fields to fill out.
Title: This is the forum/category name. Should be self-explaining.
Description (forum form only): A short description of the regarding forum. This will be displayed below the forum name in the forum listing view.
Order: This field describes the position of this category/forum in relation to the other categories/forums. The categories/forums will be displayed in exactly the same order as specified in the backend module.
Read/Write access: Here you can specify, which user groups should be allowed to read or to write in this category or forum. If you do not specify anything, all users will be able to read or to write in this category/forum. Subordinate forums will inherit this attribute from their parent category, although you can also specify group rights for single forums. For more information on user access management, you can read Administration ► User rights management.
By clicking on the page icon in the bottom right corner of the form while editing an existing category or forum you can open the advanced category/forum editing form that allows you to edit nearly every attribute of the category/forum record in the database. This feature should used only by administrators.
Under the point “Tools” you will find several useful tools allowing you to customize your version of the mm_forum extension.
With this tool, you can define your own BBCode elements. In the mm_forum extension, a BBCode consists of three elements. First the code itself, second a regular expression telling how the code is recognized in a post's text and third a replacement pattern. The second and the third value are parsed by the PHP function preg_replace (see http://www.php.net/preg_replace for further information).
Furthermore, you can take a look at the already existing BBCode elements that were installed along with the mm_forum in order to understand how the BBCode implementation system works.
You can also add custom smilies to your mm_forum. Defining a new smiley is very simple. You just have to define which image file should be used for the smiley (the backend module looks for smiley images in the directory EXT:mm_forum/res/smilies) and the code this image is associated with. This code will be replaced later on with the actual image.
The mm_forum extension uses the Generic Syntax Highlighter plugin (GeSHi) by Nigel McNie in order to offer syntax highlighting of code samples in various programming languages. To configure which highlighting options you want to offer, you can select the Syntax highlighting option in the Tools menu. The syntax highlighter options work pretty much like the BBCode options. You can specify a programming language (you can only select languages that are supported by GeSHi) and a replacement pattern (again, see http://www.php.net/preg_replace for further information).
Using the data import tool, you can import data from other forum applications, like for example the phpBB board or the CHC Forum extension for TYPO3.
Using the phpBB data import tool, you can import nearly all data from an already existing phpBB board into your newly created mm_forum board. The import tool is specified for the newest phpBB version, which is 2.0.22.
In this step, you can choose, from which application you want to import. For a phpBB data import, of course you choose phpBB as import option.
In this step you can specify a database connection that is to be used for the data import. This allows you to import data from an external MySQL server. If you select Use local TYPO3 database, the local database will be used for the data import. In case you select an external server as data origin, you will have to specify the connection data for the MySQL database on this server, i.e. the server address and a MySQL user name and password. On the other hand, if you choose to import from the local database, you will not have to specify any access data, since this data is already known to the import script.
All phpBB tables are prepended with a specific prefix, allowing to distinguish different phpBB installations in the same database. Since the install tool does not know, what prefix your phpBB tables have, you will have to specify this prefix before starting the import process. This you do in step 1.
As soon as you click on “Update”, the install tool will check in the database, if all required phpBB tables do actually exist. Since in some of the latest phpBB versions, some new tables were added, the import tool does not make a great deal of some tables missing. However, it will display a warning message and ask you to confirm if you really want to go on with the import. At this point you do not have to worry about the import maybe going wrong. If there is a vital table missing, you will get to know in the next step.
However, if the install tool does not find any of the required phpBB tables, you will not be able to proceed with the data import.
NOTE: Although all phpBB table names follow the pattern [prefix]_[table name], you will not have to append the underscore (_) to the prefix you specify. This will be done automatically.
In this step, you can specify, what data exactly you want to have imported. The import tool will show you, which tables are required for each data. If one of these tables does not exist, you will not be able to perform the import. You will also notice, that there are interdependencies between the different data areas. The reason for this is that there is a high amount of references between different tables. For example, in the post table it is stored, which user did create a certain post. Now of course without importing the users also, the link between the post table and the user table will be broken and it would be impossible to determine who actually wrote this post.
However, it is possible to import all the data in several steps, since the import tool knows, which data have already been imported and which have not.
If you have selected everything you want to import, you may proceed with step 3.
On this page, you can define further options for data import. The fields you see on this form are depend on the fields you selected for import in step 2. The import script proposes default values for most of the fields, that it gets from the data you specified during the installation. However, you should check this data before importing.
You have also the possibility to completely clear all data from the mm_forum tables before importing. If you have just installed the extensions, this will not be necessary, since the tables are still empty anyway. Anyway, this feature might prove useful, if you want to override data that already exists, maybe from a previous data import.
NOTE: Although TYPO3 handles database record deletion by just setting a “deleted” flag to 1 while the actual record remains in the database, this is not practised if you select all data to be deleted in the import tool. The records will be deleted by a MySQL DELETE order, so be careful when deleting the entire mm_forum database.
You will not be able to get back your data once it has been erased.
When you are sure that all settings are correct, you may proceed with step 4.
In step 4, finally the actual data import will take place. However, if you checked one of the “clear all” fields in step 3, you will be asked, if you really want to delete all data. Additionally, since this process might also affect the global fe_users table, you will have the possibility to define, which entries from the fe_users table shall not be deleted. You can do this by just defining a list of user UIDs and user group UIDs. The users/user groups with these UIDs will not be deleted. Alternatively, you can also define a complete MySQL WHERE-clause.
After you have entered all these settings, you will be able to start the import.
The mm_forum and the phpBB software have different ways to organize their regarding data. That is why there are so many setting you can make before actually performing the import. For example, the phpBB distinguishes between forums and categories, a difference that the mm_forum does not make. So both the phpBB category and the phpBB forum data are imported in the tx_mmforum_forums table.
Another difference is in how the phpBB and mm_forum handle user authentications. The phpBB user authentication offers a wider range of options regarding access control, which makes this more flexible, but also more complicated. For example, the phpBB makes a difference between the right to create new topics, to create new posts and to edit posts, while in the mm_forum, all these rights are combined in the write access field. In addition, the mm_forum does not have an extra table for storing user authentication like the phpbb_auth_access table in the phpBB board, but stores these data directly in the forums table.
Furthermore, the phpBB offers some functionalities that are not implemented in the mm_forum, such as the mm_forum offers some functionalities that are not implemented in the phpBB. For example, the phpBB offers the possibility to create polls or to change between different color profiles. Since these functions are not supported in the mm_forum, the regarding data will of course not be imported.
Using the CHC Forum import tool, you can import all data from the CHC Forum TYPO3 extension. Please notice that all mm_forum data will be erased before the CHC Forum data import.
NOTE: Although TYPO3 handles database record deletion by just setting a “deleted” flag to 1 while the actual record remains in the database, this is not practiced if you select all data to be deleted in the import tool. The records will be deleted by a MySQL DELETE order, so be careful when deleting the entire mm_forum database.
You will not be able to get back your data once it has been erased.
This step is analog to the regarding step of the phpBB import. Of course, you will have to select CHC Forum instead of phpBB.
In this step, you can choose which data you want to import. You can import all data from the CHC Forum extension. Furthermore, you can import the private messages from the CWT Community extension. If one of these extension is not installed, you will – of course – not be able to import the regarding data. The missing of one of these extensions will not affect the data import of the remaining data.
Hit “continue” to start the data import.
You can use the installation module to configure your mm_forum in a very easy way. The input fields in the configuration module are described in detail and should be self-explaining. You will find more on the configuration module in the Configuration chapter.
The search function in the mm_forum :: Search plugin needs a search index in order to function properly. Only indexed posts will be found in a search process.
So, in order to guarantee a high search efficiency, an indexing has to take place in regular intervals. In general, there are two ways, to index the posts of the mm_forum for the search function.
If you are logged in as an administrator, you will see a link labeled Start indexing below the search function. If this link is clicked, the script will automatically update the search index. However, this has to be done manually in regular intervals.
A more elegant solution is the automatic indexing using a CronJob.
If you have access to a crontab you can call the index script by using the text browser LYNX. Insert the following line into your crontab and the script will run all 15 minutes:
-*/15 * * * * user Lynx "http://www.domain.tld/forum/search.html?tx_mmforum_pi4[ind_auto]=1&tx_mmforum_pi4[indexingPassword]=admin" –accept_all_cookies > /dev/null
This line (notice that the code above is a single line!) calls the text browser Lynx every 15 minutes. Of course you will have to change the URL to the page where you have inserted the mm_forum :: Search plugin. Furthermore, you will have to change the user name to a specific system user, and the password to a value defined in the constant plugin.tx_mmforum.indexingPassword. The result of the page call is put to /dev/null. It is highly recommended to change the indexing password specified in the TS constants (see above) to another value than “admin”.
Of course you are free to alter the indexing internal from 15 minutes to every interval that you like. You should however notice, that the search is the more precise than the interval gets shorter.
If you have no access to crontab you can use a web cron service. Ask Google for good service.
The mm_forum extension offers a flexible user rights administration. As you may have already seen in Administration s Categories and Boards, you can specify for each board and category which user groups may read or write in this category or board. You can specify several user groups that are allowed to read or to write in a board or category, however, users have to be in only one of these user groups to have access to this category or board.
Another interesting aspect is, that boards inherit the access settings from their parent category. This means that all boards in a category that can be read only by administrators, can also only be read by administrators, without this being specified in the regarding board records.An interesting consequence of this fact is, that this provides you with a possibility, to combine user access settings in many ways. If there is for example a category that is only accessible by Group A, and this category contains a board that is only accessible by Group B, then this board is in fact only accessible by users that are in fact members of Group A AND Group B. On the other hand, a board that is accessible by Group A and Group B, may be accessible by users that are members of either Group A OR Group B (or Group A AND Group B).
If you do not specify any groups at all, all users will have access to this category board. However, there is one small discrepancy: If no groups are specified in the Read-field, then all users are allowed to read posts in this board; even visitors that are not logged in at all. On the other hand, of to groups are specified in the Write-field, then only visitors that are logged in are allowed to write something; the visitors that are not logged in are not allowed to write contributions in any case. In other words, there is no difference between leaving the Write-field empty and just specifying the mm_forum default user group that contains all users.
Because all of this might seem very abstract, you will find a list of possible applications of this user rights management possibility in the following paragraph.
Internal sections: By limiting read and write access to moderators and/or administrators, you can create an internal section in which moderators and administrators can discuss about internal topics that the rest of the community does not have to know about.
Announcement boards: By allowing read access to all users and limiting access to e.g. moderators and administrators or a special group of news reporters, you can create an announcement board in which only a small group of users can write announcements that can be read by all users.
As you may have noticed, moderators and administrators have the possibility to apply a certain prefix to a topic, like e.g. “HowTo” or “Info”. The mm_forum extension offers a functionality to display all topics with a certain prefix.
The idea behind this feature is that moderators can e.g. apply the prefix “HowTo” to topics where a solution to a certain problem is explained in a very easy and comprehensible way or that contain a detailed description on how to do something, and that users can later on see all topics marked as e.g. “HowTo”.
To implement a prefix listing functionality on your site, you just have to create a link to the page the mm_forum :: Forum plugin is placed on, supplemented with the following parameters:
&tx_mmforum_pi1[action]=list_prefix&tx_mmforum_pi1[list_prefix][prfx]=PREFIX
Replace PREFIX with your own custom prefix (without brackets).
You can also list all posts that have not yet been answered. To go to this special list view, you have to create a link to the page the mm_forum :: Forum plugin is placed on, supplemented with the following parameters:
&tx_mmforum_pi1[action]=list_unans
Furthermore you can list topics that contain replies the user that is currently logged in has not yet read. To access this special list view, you have to create a link to the page the mm_forum :: Forum plugin is placed on, supplemented with the following parameters:
&tx_mmforum_pi1[action]=list_unread
As of mm_forum version 0.0.4, you have a FlexForm configuration field for the mm_forum :: Forum plugin. There you will have the possibility to create a shortcut to one of these special listing without specifying such a complicated url as mentioned above. You just have to create a new page in the page tree, insert a new instance of the mm_forum :: Forum plugin on it. In the FlexForms configuration of this new instance, you set “What to display” to “Message board” and “Show special page” to “List unanswered topics”, or to whatever you like.
NOTE: You will have to save the plugin instance once after setting “What to display” to “Message board” before you will be able to see the “Show special page” item.
If this plugin is called in the frontend, it will redirect the visitor to the main instance of mm_forum :: Forum (defined in the TS constants in plugin.tx_mmforum_boardPID), with the URL being supplemented with the correct parameters (that are also explained above).
The mm_forum extension offers the possibility to extend the user profile by a (theoretically) unlimited amount of additional fields. These fields can then be filled out by the users on registration and edited later on. The administrator can define whether the information entered in these fields shall be public or only visible to the administrator.
To extend the user profile, go to the menu point Extend user profile in the mm_forum backend module. Here you will see a list of fields the user profile was already extended with. Here you will see that most of the input fields that are displayed during user registration and editing are actually handled as a custom user field. These default user fields are imported with the static table data during the installation of the extension. You can use the button labelled New field to create an additional profile field. You can sort the profile fields using the up and down buttons.
The delete, up and down buttons should be self-explaining. Using the Edit button, you get to the user field editing form. Here, you have the possibility to configure your user field to the finest detail:
Field Name. This is the title of the user field. It will be used as label in the registration and editing form and the public profile overview. This field is multilingual, so by clicking the flag, you can add a translation in a language of your choice.
Required. This check box defines whether this field is required to be filled in by the user. If the user leaves a required field empty on registration or an update, an error message will be displayed.
Restricted visibility. If this field is checked, its contents will only be visible to the user him-/herself and to the administrator.
Link with fe_user table. Here you can define, in which column of the fe_user table the contents of this field are to be saved. If you leave this property empty, the contents of this field will be stored in an additional table and not in the fe_user table.
Field Type. Here you can specify the field type of you user field. There are four predefined field types (text field, radio button, check box and selection list). However, by using the custom field, you can specify a user field of any type you like. See the section Custom user fields of this manual for more information.
Although the interface presents a set of predefined field types, every user field is defined by a certain typo script configuration. If you choose one of the four predefined types, this configuration will be written automatically. If you choose Custom, you are on your own.
In the typo script configuration, three content elements have to be defined. These are called label, input and output. The label object is used for generating the field label in forms and the public profile. The input object is used to generate a input field for the registration or user editing form, while the output object is used to render the read-only output for the public profile. All these objects have to be regular typo script objects. The rest is up to you.
A variable named “fieldvalue” will be loaded into the data array, allowing you to dynamically access the user field's field value. Furthermore, the markers ###USERFIELD_NAME###, ###USERFIELD_UID### and ###USERFIELD_VALUE### will be substituted in the generated content.
To make the whole topic more understandable, you will find an example field configuration in the following paragraph. This will create a simple checkbox in the user settings field. The field value will be translated to “1” or “0” in the public user profile:
label = TEXTlabel {value = Likes beer}input = COAinput.1 = TEXTinput.1.value = <input type="hidden" name="###USERFIELD_NAME###" value="0" />input.2 = CASEinput.2 {default = TEXTdefault.value = <input type="checkbox" name="###USERFIELD_NAME###" value="1" />0 = TEXT0.value = <input type="checkbox" name="###USERFIELD_NAME###" value="1" />1 = TEXT1.value = <input type="checkbox" name="###USERFIELD_NAME###" checked="checked" value="1" />key.field = fieldvalue}output = CASEoutput {key.field = fieldvalue0 = TEXT0.value = No1 = TEXT1.value = Yes}Another example field configuration for extending the user profile with a dropdown field:
label = TEXTlabel {value = Design}input = CASEinput {stdWrap.wrap = <select name="###USERFIELD_NAME###">|</select>default = TEXTdefault.value = <option value="1">Night</option><option value="2">Tag</option>1 = TEXT1.value = <option selected="selected" value="1">Night</option><option value="2">Tag</option>2 = TEXT2.value = <option value="1">Night</option><option value="2" selected="selected" >Tag</option>key.field = fieldvalue}
output = TEXToutput {value (<select name="###USERFIELD_NAME###"><option value="1">Night3</option><option value="2">Tag</option></select>)}The mm_forum extension offers a functionality for forum users to obtain user ranks in dependence of their post count. In simple words: The more posts a user has written, the higher is his/her rank. The user ranks can be configured using the User ranks section in the mm_forum Backend module.
The post count described in this table is the minimum post count a user has to have in order to obtain this rank. In the example above, a user with 30 posts would have the rank “Newbie”.
Ranks with the predicate “special rank” can be applied to certain user groups. Users from these groups will always have this rank no matter their post count. This is a useful feature in order to label administrators or moderators as just that.
To apply a rank to a user group, edit the regarding user group using the TYPO3 list-module. There you will be able to select the user rank applied to this group:
If the user rank is marked as “exclusive” (see picture above), this is the only user rank members of this group will have. If a user rank is not exclusive, members of this group will have two ranks, first the one that is dependent from their post count, and then the one resulting from the group configuration. If the rank is marked as exclusive, than only this rank will be displayed.
As of version beta 0.1.0, the mm_forum extension includes a statistics module allowing you to see information on the development of the amount of posts, topics and user registration. You can select between different resolutions, which reaches from whole months as smallest units down to single hours.
The mm_forum extension offers some special functionalities in order to support the RealURL extension. Because the mm_forum extension works with a whole lot of parameters, it is very difficult to configure RealURL to create nice looking links in the mm_forum extension.
In the res/ directory in the mm_forum extension directory, you will find two example files for a mm_forum RealURL configuration, once in English and in German (tx_mmforum_realurl_en.txt respectively tx_mmforum_realurl_de.txt). In this file, the fixedPostVars array of the RealURL configuration is stored. You have to copy this array into your RealURL configuration array in the localconf.php file. If for example your RealURL configuration array looks like this (notice that some passages have been cut for lack of space):
$TYPO3_CONF_VARS['EXTCONF']['realurl']['_DEFAULT'] = array('init' => array('enableCHashCache' => 1),'preVars' => array([...]),'fileName' => array ([...]),'postVarSets' => array('_DEFAULT' => array (),),'pagePath' => array([...]),);you will have to insert the fixedPostVars array like this (notice the passages in red):
$TYPO3_CONF_VARS['EXTCONF']['realurl']['_DEFAULT'] = array('init' => array('enableCHashCache' => 1),'preVars' => array([...]),'fileName' => array ([...]),'postVarSets' => array('_DEFAULT' => array (),),'fixedPostVars' => array([...]'PI1_PID' => 'mm_forum_pi1','PI3_PID' => 'mm_forum_pi3'),'pagePath' => array([...]),);One final step will be to replace the place holders 'PI1_PID' and 'PI3_PID' with the page UIDs you have places the plugin mm_forum :: Forum or mm_forum :: Private messaging on.
It is important you do this last step. Otherwise, the mm_forum will not work with RealURL!
If you run the mm_forum with this RealURL configuration, you will notice that the links that are generates do not look really nice. Instead, you will see links like these:
forum/user//////admin
as RealURL representation for e.g.
index.php?id=forum&tx_mmforum_pi1[action]=forum_view_profil&tx_mmforum_pi1[user_id]=3
The reason for this lies in how RealURL handles parameters. Due to the RealURL configuration, RealURL expects a lot of parameters (since the mm_forum works with a lot of parameters). This means, that a mm_forum-RealURL-URL is generated following the pattern below:
forum_page/[action]/[forum id]/[topic id]/[post id]/[page]/[user]
Now of course, if one of these parameters is not being submitted, RealURL just leaves out this parameter, resulting in multiple slashes (like ////) because the regarding parameters are not submitted.
You can encourage the mm_forum extension to submit more parameters that are not actually needed for the content generation, but allow RealURL to generate nicer URLs. For example, if a topic is displayed, regularly only the tx_mmforum_pi1[tid] parameter is expected. Now, when generating the link to this topic, the mm_forum can also append a tx_mmforum_pi1[fid] parameter to the URL, describing the board the topic is placed on. So the board name will also appear in the URL generated by RealURL.
You can enable this feature by setting the property General ► Enable RealURL support in the mm_forum configuration module or mm_forum – General ► Enable RealURLspecial links in the TypoScript constants.
As you will probably have noticed, the main mm_forum plugin brings an own rootline menu with it. Now if you already have your own rootline menu integrated in the page layout, this can be very disturbing, since there are now two rootlines on your page, one for the page structure and one for the mm_forum. So it would be a nice feature to integrate the mm_forum rootline into the page rootline.
For this, you first have to disable the original mm_forum rootline. Do so by checking Disable mm_forum rootline in the mm_forum configuration module. After doing this, the mm_forum rootline will not be displayed anymore at all. Now you have to integrate the rootline into your own menu.
If you have already a rootline menu integrated into your site, something similar like this will stand in your TypoScript setup:
ROOTLINE = HMENUROOTLINE {special = rootline1 = TMENU1 {NO = 1}}Change this configuration to the following (pay attention to the lines in red):
ROOTLINE = HMENUROOTLINE {special = userfunctionspecial.userFunc = tx_mmforum_pi1->createRootline1 = TMENU1 {NO = 1}}This will replace the default rootline with a special rootline created by the mm_forum extension. Probably you only want this special rootline on your mm_forum page, so it would be best to create an extension template for this.
As of version 0.1.2, the custom rootline function accepts the parameter “entryLevel”, that allows you to define on which level of the page tree the rootline menu shall start. See the following example to see how the entryLevel property is used:
special = userfunctionspecial.userFunc = tx_mmforum_pi1->createRootlinespecial.entryLevel = 2
As of version 0.1.5, the mm_forum extension offers the possibility to execute certain PHP scripts as cronjobs directly on the server (meaning that you do not have to call a specific URL anymore). The mm_forum cronjobs can be configured using the mm_forum install tool in the TYPO3 backend. You will notice that there is a certain redundancy in the configuration variables for the cronjobs, like for example the language has to be specified for the cronjobs. This is necessary since the cronjobs are not executed from within the TYPO3 framework and thus do not have access to the TYPO3 configuration variables (like for example the TypoScript setup).
It should be self evident that the whole cronjob thing only works on UNIX-like system. Suggestions on how to realize a cronjob-like setup on Windows based systems are appreciated.
In the following section you will find a list of all cronjobs you can set up:
This cronjob notifies a certain frontend user group (can be configured in the mm_forum install tool), typically the moderator group, about posts that wait to be published by a moderator. Of course, this only makes sense if the forum is run in the moderated mode. The email that is sent to the recipients contains a full list of all posts that are to be published.
This cronjob notifies users about new PMs that were received after the last notification mail. The email is sent only to users who have enabled this feature in their user profile.
First of all, in order to set up a cronjob on your system, you need – of cource – SSH access, except your hosting provider offers the possibility to set up a cronjob automatically. After logging in, you can edit the crontab using the shell command
crontab -e
Alternatively, you can put your cronjob into an own file and place it into the /etc/cron.d or /etc/cron.hourly directory.
All cronjobs are started by the script cli.tx_mmforum_cron.php. This script expects a parameter telling the script what exactly to do. To identify the cronjobs, you can use the cronjob names mentioned above.
Please regard that it is necessary to start the cronjob script using it's absolute path; not a relative path.
For example, a typical cronjob entry could look like the following:
*/15 * * * * /srv/www/typo3conf/ext/mm_forum/cron/cli.tx_mmforum_cron.php indexing > var/log/mm_forum/indexing.log
This cronjob will start the indexing process every 15 minutes and write the results of the cronjob into a logfile.
