This is a translated document from module manuals in XUGJ
Function: Contents module
Type: Static contents making
System requirements: XOOPS2.0, head of the house version 2.2, and XOOS Cube2.1 (Do not work with Oreteki).
Duplicatability: [[Duplicatable V3]]
It is a module with a succession location of TinyD.
The migration path from TinyD is prepared.
However, in the codepicoTinyD is quite a regardless, and independent existence in complete.
It is possible to use it as a module of the type to permit the ordinary user the article contribution depending on the setting though it is suitable for the contents making by webmaster.
The directory name is not limited because it is Duplicatable V3, and either the update ends by one time.
In this module, the file composition is roughly divided into six kinds. Please distinguish respectively neatly.
Each module put on the module front end might be called "Module instance (substance)".
There is a feature mode of wraps mode in pico.
The point to use PATH_INFO of Apache in the image of enhancing version of the wraps module is the same. Notes concerning PATH_INFO are also the same as wraps, and refer to that, please.
When the wraps mode is made effective, URI of the article becomes the following forms.
(The mod_rewrite mode is invalid. )
(The mod_rewrite mode is effective. )
In pico, the part of "/index.html" is called "Virtual path". The extension of a virtual passing. Or, ..html (... Pico is output applying the XOOPS header and Ftta when ending by htm). It is page so-called wrap.
Wrapped contents are usually acquired from the file that the wrap directory corresponds. If a virtual passing is "/index.html", it becomes the following files.
An arbitrary virtual passing can be allocated about so-called DB contents. In this case, the text input on the contents edit screen is displayed. When the wraps mode is effective, a virtual passing is automatically allocated about contents for which a virtual passing is not specified specifying it. Contents of number 1 become following URI in default.
(The mod_rewrite mode is invalid. )
(The mod_rewrite mode is effective. )
The extension of a virtual passing. Html. The correspondence file of the wrap directory is forwarded with the MIME header corresponding to the extension about files other than htm. This operation is quite the same as the wraps module.
In pico, the function to wrap the page is provided as well as TinyD.
TinyD of page wrap function is compared with pico as follows.
|Difference with DB contents||Each it differs from the edit display, and another complete concept.||Difference only whether to pass "Page wrap" as text filter. Other text filters can even be put.|
|Depository of wrap file||Content/on side of opening to the public the under||Wrap directory The XOOPS_TRUST_PATH/wraps/(dirname) under|
|Treatment of relative link||WRAP2 and WRAP3 etc. of each contents were prepared.||Neither WRAP2 nor WRAP3, etc. exist. When a relative link is used, it naturally connects by using it together with the wraps mode.|
Is the former a setting "Where are contents of the specified number (contents) brought?", and very does the latter express "URI though it thinks page wrap to be confused easily with the wraps mode?Which contents number is called from the URI?Do you forward it if there is no corresponding number?It is ..".. setting.
(1) XOOPS_TRUST_PATHIt drinks and Sadamu is done. (If you never do. )
(2) The main body of the module is up-loaded XOOPS_TRUST_PATH/modules/pico as follows.
(3) The Smarty plug-in (two files) is up-loaded XOOPS_ROOT_PATH/class/smarty/plugins as follows. Please anxiously and overwrite though the file of this name might already exist if d3forum etc. were installed before.
(4) The PEAR file is up-loaded XOOPS_TRUST_PATH/PEAR/as follows. (TextWikiOnly at the time of it is time when ..no however... )
(5) WYSIWYG Editor for common is up-loaded XOOPS_ROOT_PATH/common/as follows. (Only when the WYSIWYG function is necessary. )
(6) The directory is made under XOOPS_ROOT_PATH/modules/by a favorite name (It is assumed contents), and the module front end is up-loaded there.
(7) Contents to display in the module there making the directory of (6) and this name under XOOPS_TRUST_PATH/wraps/ It up-loads it by the FTP. If the link between files is a relative link, the link need not be especially rewritten. (Only when you use page wrap function. )
(8) It enters the management screen of XOOPS used, and it installs it from the module management.
It is OK only according to the procedure of (6) - (8) to install pico since piece second.
As for the file composition, if only the main body of the module part is basically up-loaded in the superscription, it is OK. There is an announcement so when it is necessary to overwrite the front end part in some reasons (addition and default CSS change in the picture file).
All installed pico modules from the module management if necessary (There is an announcement when it is necessary)Module updateIs done.
The module update is indispensable to update from especially 1.0 affiliates to 1.1/1.2 affiliates.
Your should would being better to go immediately after the installation is an authority of top category setting. Please enter "Category access right limit" from the management screen, and give the permission setting appropriately. (Refer to the category access right limit. )
The first putting in the future because of becoming of this setting the base when the category is made might be and there not be trouble.
It is necessary to do import at this point when complete succession from TinyD and other pico is done. (synchronous import/reference)
Because when import is done later after new contents are previously made, all made new contents are erased. (The purpose of this specification is to succeed the article number etc. , and it is not avoided. )
The category and contents are only basically made there when it is possible to prepare it.
Properly, it edits and it deletes it.
Hereafter, it explains each controller.
It flies to a general setting of the management screen only a top category when "Edit" is done by a special category.
This is a specification of not abnormality but pico.
The reason for categories other than the top is that it is only a system that does a general setting that becomes basic in override.
For instance, the category title of a top category becomes "Message of a top module" of a general setting. The top category option is each setting of a general setting.
I think coming with the pin though it is not thought that it is easy to understand when making it to the word if it actually uses it.
When the edit is repeated several times, edit screen under "History" is accumulated. A past version can be referred to from a link here and it download it.
Moreover, the difference with the version just before the difference with present can be confirmed. Because the change point is classified, the difference might be understood only from glancing.
The number of preservation of histories is specified by a general setting.
|Filter item||Input value in management screen|
|HTML special character escape||htmlspecialchars|
|Automatic changing line||nl2br|
The shift from TinyD to pico must be not very difficult.
It is likely to become the following procedures though it becomes complex a little when shifting with same dirname.
If the import is done from the management screen, it operates almost without trouble when contents are only DB contents.
Please copy it onto the module front end side if necessary though only passing the image becomes a problem.
When contents are page wraps, it is necessary to copy a certain file onto the wrap directory under ..content/.. directory of TinyD. After the import is done from the pico management screen, it is likely to only have to copy it.
When the WRAP3 mode etc. are used with TinyD the former, pico the shift ahead should turn on the wraps mode.
Moreover, to copy it from TinyD onto pico in each article, you will individually still export the whole from management screen-contents managing for the import doing and temporary collectively to pico for temporary.
To make the operation etc. that step over the category easy to do, the controller who can manage contents by the batch on the management side is prepared though all contents can be edited and be managed basically on the side of opening to the public in pico.
First of all, the contents list of the object category is displayed on the screen lower half by pushing the right "Transmission" after the edited category is selected by the drop down. When "All contents" is selected, all contents are displayed without the category relation.
The batch change can be done by pushing "Transmission" button under the screen after each form element of this list screen is rewritten and checked.
After the check box in the rightmost of each line is checked, the button the under the table is clicked when deletion/movement/copying it putting the article together.
It is copied onto a top category of the targeted pico module when copying it to other pico modules (export).
Contents deleted in the past can be referred to to select the category by selecting "Contents that have been deleted". However, it will restore it from the downloaded content by the hand work when reviving because neither the edit nor the revival directly can be done.
In pico, an authority detailed in each category can be set.
First of all, the edited category is displayed by pushing the right "Transmission" by the drop down after it selects it as two screens of "Each group" and" ..the authority to the object category...
Because all groups are displayed in "Authority of each group", each group is checked to become an appropriate authority, and it removes.
In "Each user's authority", it controls by user-name (uname) or user number (uid). Please remove the check on the inspection authority when you erase the user who has already been added. The entry of the user is deleted when there is no inspection authority because the inspection authority becomes the assumption of all authorities.
As for these authorities, all logical adds (OR) become effective.
For instance, the inspection authority is only given to "Registered user group", and the user who belongs to both groups of that to which the moderator authority is given has the moderator authority in "Privileged Netscape User Group".
If the moderator authority is individually given, it still has the moderator authority in "Each user's authority" even if the user belongs only to "Registered user group".
Because the setting to deprive of the authority individually doesn't exist, each group will be giving an authority as low as possible.
Hereafter, it explains each authority.
The authority of the subcategory made from the side of opening to the public is made automatically by quite the same content as the parents category.
Therefore, time when the authority of an individual category is set again later will decrease greatly if it uses and an appropriate authority is set about a top category at the first stage.
Import can be done from TinyD or other pico installed in the same XOOPS site in each module.
As for the contents data in the current pico module, it is necessary to note all the deleted points because it is import of each module circle to the end. When import in each contents is necessary, the article is selected from "Contents managing collectively" in the reading origin, and "Copy to other pico" ..(.. is done. After the import is done to another pico temporarily made, similar work is done when copying it from TinyD in each article. )
The category of the current pico module (The authority setting to the category also :) is not deleted exceptionally only for import from TinyD. This is because the category doesn't exist in TinyD.
If it is import from other pico, the import is wholly done as for the category and the category authority.
Please use the contents managing collectively when you want copy/to move only a certain specific article.
Please execute it when tedious information that has been given to earn the speed like the number etc. of votes in the tree structure and contents of the category becomes amusing.
Following is php if it doesn't synchronize though must not be so. MyAdminThe vote table and the category table might be convenient for fixing up after it fiddles directly.
It is so-called tplsadmin.
The template of the module is managed.
Only when altsys is installed, it is displayed.
It is so-called blocksadmin.
The access control concerning the block management, the module, and the block can be done.
Only when altsys is installed, it is displayed.
|Block name||Template||Explanation||Block reproduction||Block option|
|Menu||(dirname)_block_menu.html||The contents list of each category is displayed.||Acceptable||Including category Shibori and block template|
|Content of contents||(dirname)_block_conetnt.html||Contents of the number specified by the block option (text) are displayed.||Acceptable||Contents number and block template|
|Contents list||(dirname)_block_list.html||The list display is done in order by which contents are specified.||Acceptable||Including category Shibori, the order of display, and block template|
"Including category Shibori" of the block option is a setting to target only a certain specific category.
To target only the top category right under (contents in the inside), it is specified only 0. It is necessary to note that only the right under of the category number becomes an object to the end.
The fifth category grader (cat_id=5) In the under, there are two of two pairs (cat_id=11) subcategories for 5 a couple years and (cat_id=10) and five years, and if it wants to make all contents concerning the fifth grader displayed, it specifies it as follows. (It is noted that the delimiter is a comma. )
If URI is seen in the category display, the category number is sure to be understood at once.
The contents number is specified in "Content of contents" block. When it is from URI on the side of opening to the public when virtual is passed in the wraps mode, the contents number is not easily understood. In this case, please refer to the link on "Contents managing collectively" screen.
In "Template of the block", the method of using a different template for an individual block is being offered. Default is DB template registered when the module is installed, and the following resource names.
An arbitrary template can be allocated in the block by rewriting here.
For instance, when file (themes/default/pico_block_menu_customized.html) named pico_block_menu_customized.html is put under theme default, and the file is made a template, it describes it as follows.
When the resource type is not specified, the standard of passing : It is necessary to note XOOPS_ROOT_PATH/themes/(It remembers because this is a basic specification of XOOPS and there is no disadvantage. )
Of course, the FILE template of the absolute path specification can be used. In this case, the resource type specification is necessary.
The number of DB templates is increased to use altsys and tplsadmin, and the hand is also effective. The file is added under XOOPS_TRUST_PATH/modules/pico/templates/and the module is updated. The DB template is only added only by it. (common specification of D3 module)
Of course, it is not necessary to worry the remainder as garbage because each added DB template is deleted when the module is uninstalled.
|pico_admin_category_access.html||For category access right limit of management screen|
|pico_admin_contents.html||For contents managing of management screen collectively|
|pico_admin_import.html||For import/synchronization of management screen|
|pico_block_content.html||For contents content block|
|pico_block_list.html||For contents list block|
|pico_block_menu.html||For menu block|
|pico_inc_breadcrumbs.html||Bread crumb part|
|pico_independent_print.html||Screen for print|
|pico_independent_rss20.html||For RSS output|
|pico_independent_singlecontent.html||For single content|
|pico_main.css||CSS when pico is displayed as the main part|
|pico_main_category_form.html||Edit form of category|
|pico_main_content_form.html||Edit form of contents|
|pico_main_listcontents.html||For contents list display|
|pico_main_menu.html||For the automatic generation top menu display|
|pico_main_viewcontent.html||For contents detailed screen|
The part of pico replaces the module instance name.
The event notification prepared in pico is only kinds.
There is a category in pico unlike wraps.
The HTML file put on the wrap directory can be automatically Categoraized by setting a virtual of the category passing well.
For instance, it is assumed that the pico module was installed with dirname named class to make the class homepage of the elementary school. XOOPS_TRUST_PATH/wraps/class/solving, and the directory of each school year is made in the right under, and the wrap directory in that case makes the directory of the class though it becomes each school year directory under. (construction of hierarchy)
20class/ (Correspond to a top category. ) 5/ (Correspond to category "The fifth grader". ) 5-1/ 5-2/ (Correspond to category "It is two pairs for five years". ) profile.html
The directory of each class is still made from the category management like the tree on that, and a virtual passing is specified. For instance, the category of "It is two pairs for five years" :. Parents..category..virtual..pass.(Naturally, it is necessary to make the category "The fifth grader" first. )
In this case
The access assumes that it is automatically a category of "It is two pairs for five years" and is treated. It is even if not registered as contents. Of course, to the bread crumb
20 top > the fifth grader > It is two pairs for five years & gt; (page name. )