stoppingby4now

Then it must be associated with thread/post cache somehow. If that is the case, it could take some time for those caches to get updated with tag changes.

Mod pages are essentially metadata. Ideally there should be nothing to be updated on a Mod page assuming it has had all relevant Mod information added. The Recommendations tab is intended only for the STEP Guide, hence the restriction for editing in the From since any changes will reflect in the Guide after edit. If you are spotting a lot of issues in that tab, I blame Tech. :P For what it's worth, the Recommendations tab will be going away at some point. Mod pages should be boring in the sense of not needing to be updated often, and specific instructions belong with the Guides (i.e. Packs).

Prefixes are tags, they are just an extension of them. If you look at the threads, they have the tag of "testing" on them. Which is why I'm calling this a bug.

The addon we are using is not very friendly in this regard. I've noticed that changing a prefix most often times invalidates the search completely, and the items never show back up, at least in the immediate term. The application extends the default tag system, so who knows what it's doing and why it has a hard time with this. Rebuilding the tag cache is not viable for this issue. I believe it to be a bug in the addon.

Start new threads for issues. That is not what I said. Reread my post.

There is no way to conditionally limit the Edit Source link. It would be all or nothing affecting all pages which would defeat the purpose for pages without Forms. Even if it doesn't exist, a user could still edit the source directly by specifying the correct attribute in the URL. That said, all Mod pages should ALWAYS be edited using the Form. Doing otherwise runs the risk of the page becoming corrupted where the Form isn't able to load it. The Mod pages are complex, which is why a Form is used, which also includes logic/rules for ensuring that the Semantic Properties receive the correct information. The Recommendations tab is only editable by STEP Staff, since as Tech has already mentioned, it directly affects the STEP Guide.

The DD is referencing Forms and the templates they use, so the notes regarding multiple instance templates are to the fact that they are used in the Form that way. The queries using a template format are calling the specified template for each row of returned data, so I guess you could refer to it that way. Semantic Forms uses that term to specify that a template can be called multiple times in a page. I don't consider it the same because the templates for a query aren't individual calls on a page directly, so avoid it's use in the context of queries to prevent confusion.

That just totally confused me. First off, there are no multiple instance templates. This isn't a form. You were attempting to query in the secondary template for OrderID which you will never get because it isn't associated with a Mod page. It is associated with all of the subobjects on the ModList page for the version of STEP you are querying, but the query doesn't pass that in (mainlabel=-). It is available to you in the primary query of the subojects by requesting it: |?OrderId A template format for a query is only necessary for one of two things (or both): Formatting results in a custom manner that isn't provided by SMW Chaining queries for additional information on related pages, as you can't place a query inside a queryAs for querying of subobjects versus properties, they are mostly the same. All properties are tied to a Wiki page (not templates), so you are requesting pages that match the query conditions, and then proceed to ask for Properties that exist on those resultant pages. Subobjects are slightly different as they reference the page in which they are used, so it's a reverse mapping. When asking for mods in a STEP version, the query condition is the subobject-property "Version", which returns the sub-object, which is mapped to the ModList page, and since each suboject has a unique ID (random ID which we care nothing about), you get all subobjects back instead of the actual page. No template is required for either scenario to get at the data. The only time you need a template is for the 2 reasons above. No, that won't work because the data isn't in the suboject which is what is being queried. The purpose of the subobjects for the STEP installation order is to record the Mod and it's order. Any additional information can then be queried from the Mod page itself using a template format. It is also always better to use {{#show}} when needing access to a single property in downstream queries.

I take that back, OrderID is required to sort the install order. I have also updated Template:CoreModOrderedList to use named args, and display OrderID if it is provided. This page does not display the OrderID: https://wiki.step-project.com/User:Stoppingby4now/OrderTest1 This page displays the OrderID: https://wiki.step-project.com/User:Stoppingby4now/OrderTest2

You don't query templates, you query pages. I updated your query to remove the template call as it's not needed for the example. The OrderID is added to the display, the list is sorted on the OrderID, and order is set to descending so last installed mod is now shown first. Primary exercise is to show how it can be used to sort, though the OrderID is useless for us as a sorting key. Your template was attempting to query for OrderID which is incorrect. That data is available from the primary query, just had to add it to list of properties you wanted. It's use after the first query is only visual if you choose to display it.

It is important to note that the orderID is not actually required for sorting in terms of the STEP mod list. The list is already in order just by querying the page and relevant section. I will take a look at the query in a bit Z.

Adding a mod order number is exactly what the STEP mod list does for each version. Though, it's primary purpose was for an automated install solution that would ultimately use it for ordering mods to be installed. It's also useful when querying a list of mods and being able to use it as a sort key.

Keep in mind that the production Wiki does not have those namespaces, and there is no guarantee there will be. We haven't gotten to the point yet of deciding how best to handle other games.

We can create namespaces on the dev wiki.

You'll need to clone the disk (not the partition) so you get the system reserved space, and the MBR (Master Boot Record). Clonezilla will in fact complain if you attempt to disk clone from a larger drive to a smaller. You're best option in this case is to use EaseUs Partition Manager Free which you can run in Windows, and it will get everything you need from the drive, and resize the partition. Then power down, unplug the original drive, and boot up into the SSD. Have your Windows, or recovery, disc available in case the MBR needs repair. Let the OS boot onto the SSD, then you can hook the hard drive up and reformat to serve as a data disk.

@hishutup The dev wiki will be a blank canvas. @Z $wgCachePages is a candidate for disabling which turns off client side caching. Page caches on the server are far less of a problem when developing a solution as the breadth of consumers is very low. A page cache is also updated when saving a page, so there is no real point to disabling that for development when saves are more frequent.

Being able to do something multiple ways is one thing, but it's about identifying the simplest and most maintainable solution. The subobjects are not creating multiple properties, it's wrapping information inside a pseudo object. You also need to consider maintainability. If you were done with this project, how easy would it be for you to pick it back up in 6 months? How easy it would it be for someone else to pick it up when looking at it for the first time? In terms of performance, using the subobjects would be less taxing than the chain of arraymap calls you are currently using.

Just saw this and need to chime in, as the above is not correct. For clarification, the sections missing that day was due to me rebuilding SMW data to fix some anomalies. That would have caused SMW data to disappear while the SMW data caches were being rebuilt, and the refresh of the guide had nothing to do with it showing correctly. The REFRESH option (which performs a page purge) is also not required after saving a page. SMW data that is modified will also propagate to all queries the same way that editing a template will propagate the changes to all dependent pages. It can just take a little longer for updates to propagate to SMW queries. Refreshing a page just for the sake of refreshing is not a valid recommendation. This is especially true for page edits, as the end result is the same, and constant refreshes only add to additional cpu cycles to rebuild caches when the Wiki is already doing this in the background. It can be used to force SMW query caches to be rebuilt when you are certain that dependent SMW data has changed, but in no way is it required.

You should be able to log-in now.

Sorry, wrong page. Each release of STEP gets its own page by version. STEP:ModList/2.2.9 contains the template calls, and the form uses multiple instance templates to generate the list of mods for each section. An example is calling Template:ModOrderSectionB, and each mod that is added uses Template:ModOrderSectionBItems. Inside the items template a subobject is used to store the mod name (ModName sub property) specific to the STEP version (Version sub property) and the section they are in (Section sub property). The list of mods can then be queried for the version as a whole: {{#ask: [[Version::2.2.9]] |mainlabel=- |?ModName= |link=none }} Or narrowed down to a specific section: {{#ask: [[Version::2.2.9]] [[Section::B]] |mainlabel=- |?ModName= |link=none }} For the guide, you could create the subobject in the template: {{#subobject:- |GuideName={{PAGENAME}} |ModName={{{modName}}} }} Then you can query on the guide name itself to get the list of mods. We don't make server stats public. As for performance, you only pay the cost on a page/template edit/purge. That has other implications based on the complexity of how something is setup and the number of jobs that would be required to update all of the dependencies.

Actually, scratch what I said. I took a closer look at what you are doing. Clever, but my god is that hard to follow. Sub objects would be a better method of managing the mod use on the page. Take a look at STEP:ModList and related templates for an example. This would allow you to easily query for every mod being used on the page and it would be a far cleaner format. Would have to dig into that logic to better understand how subobjects could be tied in though.

You don't need to store the list of mods on a page in a property. All you need to do is query the page for the list of mods being used. I used "show on select" in Form:Mod for the Contains ESP checkbox. You can reference that as an example.

The use of that property is not dependent on SMW. It can just as easily be solved by using a Category. SMW is about providing associations of information for pages. Categories work far better for the purpose of identifying like pages because they are searchable using standard MW, and SMW properties are not. Not everything needs to be a SMW property, and they should be used appropriately. Uses of properties that are deemed useless and a waste, I will remove at my discretion. I've had maintenance/deployments for work every night this week, so I haven't been able to finalize the update.

I see what you are trying to do. However I would say it's not good use of a SMW property. Using them in that way can lead to a lot of clutter that we'd rather avoid. If a property isn't directly adding value to associative content on a page that can't be handled via standard MediaWiki means, it's a candidate for deletion. Good work overall though in picking this up.

Complicating things more than they need to be. :) All you need to do is have a common category that the guides go in, and add [[Has default form::Oblivion_Mod_Guide]] to the category page. Then when a page is created using the form, the template would add the page to the category. Simpler, and doesn't incur the firing of multiple inline queries in regards to using multiple instance templates which will cause slow page saves as more and more mod's are included. For the layout, you can specify Mod Name to be be in the first row and have it span all columns. Then it sounds like you want two columns, left and right for the remaining items which is easy enough. All with a single table. If you'd like positioning with a column layout using div's I can help with that too. It doesn't involve any css.