stoppingby4now

If you are going to support creating multiple guides, then the forminput is the only way to go. If you are only going to support the one guide page, then add the following to Dev:TES4Mod/Guide: [[Has default form::Oblivion_Mod_Guide]] Then you can go to Dev:TES4Mod/Guide and "Edit with Form". Don't place custom links/buttons on the form page. Regarding the tables, what exactly were you trying to do that wasn't working? I questioned this because if you already have a table, what is the purpose of inserting another one when creating additional rows/columns will suffice? I see you created a table surrounding the fields in your template, were you trying to create yet another table inside of that? You can also take a look at Form:Mod on how alignment was accomplished without the use of tables.

First off, the method you are using with the custom button to create a new page is wrong. There is no way for the form to know where to create the page. You need to use the following which will automatically create a field for the user to enter the page name, and a button to create the appropriate page. {{#forminput: form=Oblivion_Guide_Form}} Second, you were missing a third ending curly brace (}) on the notes and install field declarations. The missing one on the notes field screwed up everything after. I updated and they are showing now. Third, what do you mean by putting a table in a table in a multiple instance template? Why would you even want to place a table inside a table?

Deletion of content is currently limited to members of the siteadmin group in MediaWiki, which is why the option isn't available.

There is a delete link in the first column when viewing the File History. I see an upload for FNV VanillaTexturesDirectories after Optimization.jpg, is that the one? I see 3 uploads on the 17th. The last two are of the same area of a window, by they do contain differences, albeit subtle.

Extension:MyVariables will never be installed on this Wiki. Parsing is done after a save of a wiki page, and all wiki syntax, parser functions, and template calls are converted to html and cached for quicker load times. Any extension that allows parser functions for displaying dynamic data must disable the cache entirely. Grabbing the username is dynamic as it must be queried on every page view. That means the entire page must be parsed on every page view. Obviously, that negates the entire benefit of the cache, and the problem compounds itself should such usage be allowed in templates. Not gonna happen. The extension page does a disservice by not disclosing that the cache is disabled when those parser functions are used.

The easiest route is to install a WAMP (Windows/Apache/MySQL/PHP) stack and you can develop on Windows. On the Linux side, there are LAMP (Linux/Apache/MySQL/PHP) stacks available as well if you want to setup a VM. For running a VM, I recommend VirtualBox. A list of AMP stacks can be viewed here. We will be setting up a Dev Wiki soon however.

There is no problem using {{#set}} parser to help with creating links. You can't use Wiki markup in a property with type URL. I updated the template to use the {{#set}} parser. The property gets parsed ok, it's the display on the page that hasn't been parsed and shows the Wiki markup. Not exactly ideal, but going to have to live with it that way.

There isn't a problem using #set to set a URL property, I was referring to not attempting to format the link with wiki markup like you were attempting before. For the URL type, SMW will attempt to make a URL out of whatever is passed in. That means that it needs to be plain text. Wiki markup is not supported. You could in fact pass in "forum.step-project.com" and will convert that into a URL as "https://forum.step-project.com". The reference to using #set is to be able to format a link inside a Text property. It's the only way to do it because the normal method of [[MyProperty::SomeValue]] will not parse the brackets correctly, for what I hope are obvious reasons.

Using Wiki markup to send a URL into a template works. It's assigning it to an SMW property that will break. It's not supported, and interferes with SMW markup. To begin with, SMW is not meant to store pre-formated text, which is what you are trying to do. A limited amount of wiki markup works which will get parsed appropriately. Using the set parser function is your only safe bet instead of the normal [[Property::Value]] method. {{#set:OblivionNotes={{{notes}}}}} DO NOT use the set parser function to attempt to set a URL Property using wiki markup.

I had changed the template to use {{FULLPAGENAME}} when setting OblivionModPage. The use of {{PAGENAME}} in the ifeq parser function is correct.

No, I moved the pages that were on Dev:TES4Mod/* into the namespace. {{PAGENAME}} would have worked before because of the fact that Dev: was not a namespace. Now that it is, it will show TES4Mod. Refer to this. I also agree that we need to get a dev wiki up soon. The live Wiki isn't a good learning ground.

Use {{FULLPAGENAME}} as that includes the namespace. That is likely the reason there are bogus links and data showing up in SMW, because {{PAGENAME}} does not include the namespace. The next question is, do you have everything related to the Mod pages setup the way you want? Throwing in a multiple instance template into the mix before the underlying pieces are done is not wise. The Pack implementation is a bad example, so I wouldn't follow it. You definitely want a multiple instance template, but you don't want to imbed it in another template. In it's simplest form, you would do something like this. {{{for template|TES4ModList|multiple}}} {{{field|modName|mandatory|input type=combobox|values from category=TES4Mod|existing values only}}} {{{end template}}} Then you would create Template:TES4ModList and use that to display data from the Mod page. {{#show:[[modName]]|?OblivionModUrl}} {{#show:[[modName]]|?Author}}

The first question is, what are you trying to accomplish exactly? The second block of code is only for doing multi-instance templates, and is identified by the used of the "multiple" and "embed in field" arguments. Those are more complex and are not the same as simply including two template calls within the page. If all you want to do is include two different templates, it's just a matter of defining a new "for template" call. {{{for template|MyTemplate1}}} <stuff> {{{end template}}} {{{for template|MyTemplate2}}} <stuff> {{{end template}}} I also noticed that on some of your test template pages you are providing an example display of the contents. That is not good to do when you are using SMW properties, as your template pages end up with SMW data which is undesirable. If you want to provide an example output, it is better to add logic to handle dummy displays. Such as calling the template with no arguments, or passing an argument like "debug" or "test" to indicate you only want to provide an example output and not set SMW properties.

Yes, those are the extra links I was referring to which are bogus. Cool It's not a limitation, it's just how the Wiki works. A URL Property expects a link, and at the time of the value being retrieved it is parsed as it should be. You can't take a link that is already turned into HTML and use the wiki syntax to re-create it. The only option would be to turn that Property into a Text type so that it is treated as a pure string, which defeats the purpose.

Several things to comment on. The additional entries appear to be residual links within the Wiki that are still referencing TES4Mod/Roads of Cyrodiil. The link points to the Dev: namespace, however it shouldn't be resolving. I tried cleaning up links with a MW maintenance script, but at one point it bombs. It's going to be in a funky state until I can resolve. Use named args for Semantic queries using a template format. Dealing with number place holders is horrible, because it's hard to maintain. Need things to be descriptive when dealing with so many arguments into a template. I updated your query page and template to show you how to do that. (use "named args=yes" and you can add =<name> to query arguments to rename them). Replacing the link with a title is not going to happen. It's already parsed by MW. You'll have to display the whole link from the query. Formatting the URL only works at moment of setting the variable because it has not been translated into a URL yet (it's still a string), which means it only works on the page it is defined on.

Hmm, for some reason that namespace was commented out. Re-enabled, working on getting the pages to populate correctly now. EDIT: It's fixed now. Updated Dev:TES4Mod to use the template at DEV:TES4Templates/ModQuery.

They have nothing to do with each other (Templates versus SMW Forms and Properties). It doesn't matter if templates reside in the Template: namespace or on some other page, it in no way breaks association. PRO Placing templates in the Dev: namespace during development would not be searchable by default. The Template: namespace is searchable by default, Form: Property: and Dev: are not. CON Forms would need to be updated when a template is made live by putting it in the Template: namespace. This can be negated by developing the template first. But I do agree, it would be nice to have a completely separate dev wiki.

I'm not sure what caused the rouge property, and there were some other properties that needed to be cleaned up that weren't. The cleanup involved deleting all SMW data and rebuilding it. No pages were deleted.

I had to rebuild SMW data last night which would have caused any pages with SMW properties/queries to temporarily lose the data they had.

I describe what happens in this post. The above would need to be {{User:Z929669/MyTemplate}}. It is not true for Properties and Forms, they still need to reside in the Property: and Form: namespaces. For templates, the namespace is the key. If the call doesn't include a valid namespace, then it is assumed to be the Template: namespace. EDIT: hishutup me EDIT 2: Also, to prevent the wiki from assuming the Template: namespace, you can put a leading colon in the template call like {{:MyTemplate}}. That would then transclude the MyTemplate page in the Main namespace.

Did some cleanup, it's all good now.

Templates are moveable. Any page can be a template.

Queries only return the data that is stored in the properties. If you want to do any kind of formatting, you will have to use a template format. All of the data that is returned is then passed to the Template and you can format it any way you want. That is defined by adding the following two parameters to the ask query: |format=template |template=<template name> The dev namespace is Dev:

As to the Dev namespace, I had forgotten that we created that. It's not your fault. And no one can create namespaces in the Wiki, they must be defined in the configuration on the server. String should no longer be used as it is depricated. In the current version we are running, it is an alias to Text, but when we upgrade SMW, we'll need to convert any Properties that are defined as String to Text. EDIT: Also to add a bit more information, templates can be used from other namespaces by transcluding the page with the namespace. If no namespace exists, then MW automatically tries to load the page name from the Template namespace. Examples: {{MyTemplate}} - transcludes [[Template:MyTemplate]]{{Games:MyTemplate}}If "Games:" namespace exists - translcudes [[Games:MyTemplates]]If "Games:" namespace doesn't exist - transcludes [[Template:Games:MyTemplates]]Form's on the other hand always start with "Form:"

I updated the Template to fix it. Several things to make note of: Z makes a good point. During development, you should use pages within the Dev: namespace. That doesn't apply to Forms and Templates, but any pages that are created are much easier to hide away. Doing active development in the main STEP namespace is not good because the page can be returned from searches. Some HTML elements are illegal to use in Wiki's, and the <a/> element is one of them. It will be parsed and displayed as regular text. Semantic Properties of type URL do not need to have wiki markup to build the link. SMW does that automatically, which means the use of external links markup is useless and thus ignored. In this case you need to use the form of the setting a property such that when it is set, it uses alt text. [[MyProperty::some_value|alt title]] In this case, however, using the setting of the OblivionModTitle does not work because it's the wrong parse phase, and messes up the link. In order to work, it must be set prior to the display of the link and the {{#show}} inline query used to retrieve the value for the alternate text.