stoppingby4now

I'm getting results in Tapatalk, and so far have been sorted accurately. What version of TapaTalk are you running?

Hiding text is not ideal either. If a TOC is too wide, then it's not a good candidate as a floating TOC. Let's not go altering things in the Wiki that is not consistent. This is one example of why I don't like the CSS extension.

I want to implement a side TOC pane that can be hidden/revealed. Will make these issues non-relevant.

There is no mechanism for adding a character limit. About the best that can be done that I can think of would be to force the TOC block to be at most X characters in width, in which case long headings will wrap within the block.

We upgraded our VPS today. Appears the upgrade process killed some services, and the search functionality was one. It is back up.

MW will automatically rename the file when it is uploaded so that the first letter is capital. The problem has been one of permissions, but I just fixed that so this shouldn't happen any more. Hopefully. :)

Yes, that would be possible. Expanding on the need for mod pages to exist on the Wiki, a pack author can add mods to their pack, which would allow the common information to be automatically imported such as author, download URL, forum URL, description, DLC requirements, etc. Then the additional fields can be made available for each individual mod to provide the pack specific data. All using templates of course, and semantic forms. I haven't followed this discussion 100%, but if you folks want to start a mock layout of how the ideal pack page structure would look like, I can help get all of the semantics updated/implemented.

The mw-collapsible mechanism is a jquery plugin delivered with MW. It handles everything related to managing the link that says expand|collapse. For now, the current state is how it will have to be. We don't modify core code as it makes upgrading a huge headache, that gets significantly worse with the more changes that are made. Taking this to the next level will need to have something incorporated into the skin, or an extension.

I just added that template, and the necessary CSS to support it. Try it out. I'm not sure what you mean by a table filled with templates. Could you expand on that more? Forms are made with Semantic Forms. Some URL's to begin with: https://semantic-mediawiki.org/wiki/Help:User_manual https://www.mediawiki.org/wiki/Extension:Semantic_Forms I know I removed that code from a few guide pages a ways back. Someone must have added it back in. The modified time has been there from day one.

Adding update time to a page is unnecessary. It is built into the skin and already appears in the bottom bar on every page.

I'm not a fan of sub-pages for things like this. They add extra maintenance, separate child information from their parent, and pollute searches. A better solution would be to use sub-objects to tie instructions with a mod within the pack page. Semantic queries can then be used to provide reports on things like what packs have instructions for mod X, or what mods have instructions in Pack Y. This can all be automated as part of the management of mods in a pack.

Sorry for any confusion. I'm not referring to any need to have mod tables. The structure can change to whatever is deemed best suited for packs, and if mod tables are not cutting it, then they need to go. Consistency and interconnectedness: Mod data is all managed via Semantics. That means it is all available to anything on the Wiki via semantic properties. You are correct that pack specific instructions/data do not belong on the Mod pages, but the Mod pages provide semantic data such as... Link to a thread on the forum for discussion on the mod Download URL (mod project page) Resource usage DLC requirements Section (Ultimately needs to be non-STEP specific and geared towards the primary category a mod should be associated with)All of this information keeps consistency by utilizing a single repository of information about a Mod that everyone shares. This eliminates discrepancies by providing that single source of information. If a download URL needs updating, change it once, and everything on the Wiki that references it is automatically updated. That is also how everything is interconnected. Whatever the resulting design of a pack layout ends up being, the above information when implemented within templates reduces the editing burden across all pack pages. All while helping to ensure that basic mod information represented everywhere is accurate.

Great suggestions so far. Main thing I will comment on right now... Z touched on this, but Mod pages are necessary. They are what binds the semantics of everything, for both STEP and packs. This is the core of enforcing consistency and interconnectedness of data. Pack structure definitely needs some love in this department.

Search is working again.

For Mediafire, just right click on the image and select "Copy to Clipboard". Paste that into the IMG BBCode and everything will work as expected. The following illustrates the image you are trying to add, and all I did is copy the full image URL to clipboard, and copied that into the IMG tag: [img=https://www.mediafire.com/convkey/9f46/4i8qdtbw9bwl1nkfg.jpg]

Public discussion was not the purpose of that forum, but rather a place for Mod Authors to discuss behind closed doors. Such setups will always have less traffic. The Mods and Packs forums are for public discussion.

The forum is locked down the same as it was. Only admin and staff can create new topics, but members can reply to existing threads, unless they are locked.

Due to our current layout, mod pages should only be for Skyrim. To support multiple games, the ideal solution is to create new namespaces in the Wiki. URL wise, that would end up looking like: http://wiki.step-project.com/Skyrim:Realistic_Overhaulhttp://wiki.step-project.com/Fallout:Some_Mod

Aye, I do. And you stated some of the reasons why I hate them just a few posts up.

Optional title support added. The current downside is that if no title is added, there is no default text (normally "Spoiler"). Limitation of the custom settings in IPB. I will rectify this later by creating a custom bbcode plugin. I will also be adding an additional feature to allow showing the contents of a spoiler in an HTML popup without having to expand it in the post itself (but you will still be able to expand in post as well).

For the Advanced search, fill out the following: Match: Only search in titles Find author: <user> Display Results: As a topic list Result Sorting: Title

I already added the tag because it at least exists and is functional. I also replied to your PM, you won't be able to do what you are attempting to do.

Part of the reason why folks edit OP's with answers is to make it easy for others to quickly find that answer. The "Best Answer" features removes the need for that, so it's just a matter of folks getting used to that. Training, training, training.

I had to completely remove the post cache for it to enable on existing posts with images. The caches are slowly being rebuilt with each client view.

I have installed what I have so far to get highslide working with galleries in posts. A little rough around the edges, and still some things to work on, but at least the functionality is there. If any issues are found, please let me know.