Extension:Page Forms/Common problems
|Page Forms - navigation (view)|
|Basics||Main page (talk) · Download and installation · Quick start guide · Hosting · Special pages|
|Using Page Forms||PF and templates · Defining forms (Input types) · The "Edit with form" tab · Linking to forms · Creating query forms|
|Resources for help||Common problems · Known bugs and planned features · Getting support · Developers' documentation · Testing|
|About Page Forms||Authors and credits · Version history · Sites that use Page Forms · Related extensions|
Below are common problems and issues associated with using Page Forms. This page does not contain known bugs in Page Forms - for that, go to Known bugs and planned features.
- If a template contains section headings (like "==Section 1=="), when the template is displayed on a page each section heading will have its own "Edit" link. Such links are not desirable, since they will take the user to editing the template, rather than the actual page in question. The easiest way to avoid this problem is to place the string "__NOEDITSECTION__" anywhere within that template; this will remove all section-edit links from any page that contains that template. Another option, though not recommended, is to use "<h2>", "<h3>", etc. tags instead of "==", "===" etc.
Page Forms issues
- You can change the way dates are entered in, and outputted by, the forms by adding the line "$wgAmericanDates = true;" to the main MediaWiki LocalSettings.php file. By default, dates are printed out as "2007/06/20"; making this change will set dates to instead be printed out as "June 20, 2007" (with the month name dependent on the language of the wiki).
- You can also manually set the display format for dates using the #time parser function, defined by the ParserFunctions extension. For a European-style date format, for instance, you can have something like this in the template:
- Similarly, you can change the way times are entered and displayed. If you have a form field with input type 'datetime', by default it will use the 12-hour format, with "AM" and "PM". You can change this to 24-hour format by adding the line "$wgPageForms24HourTime = true;" in your LocalSettings.php file.
- If a page (which we'll call Page A) gets transcluded in another page (which we'll call Page B), and Page A belongs to a category that's associated with a form, it can have the unfortunate side effect of making Page B a member of that category as well, thus giving Page B an "edit with form" tab at the top, even if such a tab is not appropriate. You can solve this problem by putting the category declaration in Page A within a "<noinclude>" block, which will make Page A a member of that category but not Page B.
- If, when you go to the special pages 'CreateProperty' or 'CreateTemplate', you see a database error message that looks like "Access denied for user...", it means your database account lacks permission to create temporary tables.
- Various of Page Forms' actions are done using the MediaWiki job queue, such as creating templates and properties using Special:CreateClass, and automatically generating pages. If these actions do not seem to be getting performed, it could be that the value of $wgMaxShellMemory is not large enough. By default it is 100 MB; to increase it, add something like the following to LocalSettings.php:
$wgMaxShellMemory = 512000;
- If a form contains a large number of fields - such as through the use of multiple-instance templates - and not all of them are saved, it could be due to a limitation in PHP. Increasing the value of the max_input_vars setting in php.ini may help.
- If you are having problems with WikiEditor within forms, make sure that the following line is not in LocalSettings.php:
$wgDefaultUserOptions['wikieditor-publish'] = 1;
- If you want to do any processing on a list of values before calling #arraymap on it, such as sorting it, splitting it up or printing its size, it may help you to use the Arrays extension.
- Page Forms only handles forms for adding and editing data in wiki pages. You may want forms for other purposes: fortunately, there are other form extensions you can use. EmailForm allows you to create forms for emailing data, and Simple Forms allows you to create generic forms for a variety of purposes. See also the MediaWiki forms manual for other such extensions.
You can also see other tips and hints for using Page Forms in the tips section of the SMW Community Wiki.
Data design issues
- One common issue is how to use categories. The Wikipedia approach is to have many categories on each page, to identify all aspects of that page's subject. Semantic MediaWiki was created in part to eliminate the need for categories, by allowing for semantic properties to represent this data. The general Page Forms approach is to only have one category per page, and have this category be set by the main template in the page: in other words, it is recommended that users not enter category declarations directly. The one exception to this rule is when there's a need for "hierarchical tagging", i.e. being able to add a page within different levels of a category tree. For this purpose, the 'category' and 'categories' input types exist.
- When creating a semantic property connecting any two "classes", or pages represented by different categories, you may be unsure about which way to point the property. Usually such relationships will be of the one-to-many variety, also known as parent-child relationships, in which each page of type A has a relationship to any number of pages of type B, while each page of type B always has a relationship to exactly one page of type A. An example is countries and cities: a country can have many cities, but a city always belongs to exactly one country. In such a case, you may not know whether it should be country pages that have a "Has city" property, or city pages that have a "Belongs to country" property, or even whether both properties should exist. In this situation, it is recommended that you specify the relationship only from the child to the parent, i.e. use a "Belongs to country" property for cities and not the other way around. This is for two reasons: first, it lets you guarantee the rule that every child has exactly one parent, by setting this property through a field within the child's main template; and second, it makes page-name autocompletion more reliable, since parent pages are usually created before their children's pages are.
- You may not be sure about whether to create one form or many for a set of related page types. For instance, in a wiki about restaurants, should you have a separate form/template/category set for regular restaurants, fast-food restaurants, diners etc., or a single form called "Restaurant", with a corresponding single template and category, that just uses a field to indicate the type of restaurant it is? A good rule of thumb is to look at the set of data that you want to be entered and displayed for each type of page. If it's the same across all the types, then you could probably use a single form/template/category set for all of them. If there are only a few differences, then you might be able to use the "show on select" feature to handle the different cases within a single form. However, if there are significant enough difference in the set of fields being displayed, then it probably makes sense to give such a page type its own form, template and category.
- It is possible to create a different namespace for each page type. Wikisource does this with an "Author:" namespace, for instance, and several SMW-based wikis have one or more namespaces for different page types. Whether you do this on your wiki is up to you, but it is not recommended that you do it unless there is a real possibility of naming ambiguity otherwise. A massive wiki like Wikipedia will have a great deal of pages that require disambiguation, but most small wikis will barely have any, and so having separate namespaces will probably be a needless complication. (Currently the only common examples of ambiguity in SMW wikis are caused by having pages for both cities and states in the United States: "New York" and "Washington" both fit into either category. There are various solutions to this problem, but the simplest may be to have all states referred to by their two-letter abbreviation, e.g. "NY" and "WA".)