stoppingby4now

One thing to note, TES4 is not a namespace, so you are really creating a page titled TES4:Mod with a bunch of subpages under it. That's not ideal. But given our lack of a proper environment and that you are putting forth the effort to learn SMW, I won't complain too much. However, your great efforts are going to make me think about how to handle cases like this sooner than I realize, and that is supporting other games with a viable and supportable structure. Setting properties belongs in the template, not the form. It's the forms job to get input from the user, and then pass it to a template to handle the data. I took a look at your template, and there isn't any code that is assigning values to those properties, which is why nothing is being returned in the query. You're second example is also missing a colon. Setting SMW properties is always: [[PROPERTY::VALUE]]

What you are trying to do won't work. Remove the "forminput", access the form directly then save. The forminput method is used to create the actual page, which means it's existence is already defined when the form comes up, and the "page name" attribute is ignored.

Copy works, we removed the file extension requirement.

Correct, which means it is a Pack detail, not a Mod detail. You don't store information about consumers in low level data objects. The Merged attribute would go away with implementing Patch pages, and IsCore is a Mod unique attribute within the system since all Packs build upon STEP:Core. Recommendations are the only other information that should be decoupled from STEP and be unique to the Mod. The STEP Guide would then contain the specific instructions for Mods like Packs will. To drill down a bit deeper, we are also now introducing Patches. If I were writing a software program from scratch to manage all of this, I would naturally end up with the following objects: Mod - Entity that implements a Mod (and should ONLY describe a Mod) Patch - Container that implements a collection of Mods (and should ONLY describe a Patch) Pack - Container that implements a collection of Patches and Mods A Mod object should only contain information that is unique to the Mod. A Patch would be a container that manages a list of Mods and has information that is unique to the Patch. A Pack would be a container that manages a list of Patches and Mods. In other words, Packs rely on Patches and Mods, and Patches rely on Mods. Not the other way around. I would not store Patch or Pack specific information in the Mod, because it breaks the purpose of the Mod object as being a singular collection of information that specifically describes the Mod. If the Mod disappears (extreme example), all information about the Patch or Pack it stores is lost. That's not good. The more likely scenario is a Patch or Pack disappears. If done correctly, it's simply a matter of destroying the right object (or page in this case), and everything is good. Store top level data in low level objects, then you wind up with additional tasks to clean up the data. That makes no sense. Since Packs consume Patches and Mods, and Patches consume Mods, reversing the dependency at any level makes it much harder to maintain and control data. It's why I'm against storing Pack specific instructions on Mod pages, they just don't belong there. They are Pack details, not Mod details. You would do the same thing we do for STEP now in regards to it being a Pack that contains a list of Mods. You can now have a Patch that contains a list of Mods. In turn, you would then have a Pack that would contain a list of Patches and Mods. It would be faster to implement as a Mod attribute, but that doesn't make it right. I very much disagree that it is more intuitive. It breaks dependencies by causing data that does not uniquely describe a Mod to remain should a dependent object be deleted (Patch or Pack), and disassociates information further from the object that it does uniquely represent. It may seem simple at first, but it's an illusion shrouded in speed of implementation. You're still breaking dependencies, causing data leakage by separating said data farthest from the object that it naturally describes, and also creates unnecessary editing tasks. Why would I want to individually edit 10 Mods to indicate that they are required for a Patch, when I can edit one Patch and indicate that it requires 10 Mods? If it doesn't uniquely describe a Mod that ALL consumers will universally use, then it's not a Mod attribute. Author, Name, URL are all unique to the Mod. "Must be installed if using Patch A" and "Must be installed if using Patch B" are not unique to the Mod. They are unique to the respective "Patches". Main answer is, neither, because the information doesn't belong there. :P EDIT: I can work getting a Patch implementation setup.

It seems to me that this kind of information would be useful to all packs. This information is not Mod specific, but rather Pack specific (which is inherited via the Patch). In this case, a Pack consumes Mods and Patches, but Patches also consume Mods. To that end, it would be better to have a Patch page (similar to Mod page) that allows one to identify all of the mods required for it. An alternative would be to create mod pages for the patches and allow for identifying it is a patch, and then required mods could be linked. I would prefer the former, as there are a lot of attributes on the Mod page that aren't relevant for Patches. By having a separate Patch page, specific instructions can also be added which, I hope is obvious, are specific to the Patch and not the Mods.

I don't know why puu.sh is black listed when sites like imgur.com aren't. All of these hosting services end up with malware on them trying to bait folks. However, a valid reason not to use puu.sh is the time limit before files are removed (1 month if not accessed for free accounts). Dropbox or similar are much better for sharing images because they stand the test of time. There are no policies on removing files that haven't been accessed for X amount of time. All of the image sharing sites do this at varying degrees, and there is nothing more annoying than doing a search and coming across a page/forum/wiki that has images that no longer resolve.

There are no classes as one might equate to programming languages. It's just their term for attempting to create everything at once based the semantic properties you define. This includes the properties themselves, templates, and forms. It's not the ideal way to create an SMW structure, as it can lead to a lot of manual cleanup, especially if you are first learning about SMW as you will go through several revisions.

If you want any kind of control for the layout of a Form, you're going to have to edit the Form source by hand. You can use the Create Form special page to at least add all of the fields you want, then edit the source to modify the layout. The biggest issue is allowing for creating multiple entries on a page. It's a bit painful to implement and also hard to maintain. The initial pack implementation that Farlo did was mirrored from the setup that I did on the Project:Data_Dictionary page. It's pretty cool, but I cringe every time I need to go in and update that monster. Still trying to find a better method.

Just a heads up in regards to the blocking issue. I have resolved it in my dev VM, and we are getting close to doing some site maintenance to upgrade software and infrastructure. It will be resolved soon.

It was agreed that the CSS extension was not going to be ripped out from under everyone. The underlying agreement was that the skin would be updated to better accommodate as much as possible for what is being used currently, as well as investigate additional functionality that has been requested from time to time. The fact is, we need consistency in presentation, and the CSS extension breaks that. It's use has spread beyond it's intended purpose, which was a stop-gap for the STEP Guide until a skin refresh, which admittedly has been a long time coming. We purposely did not advertise it's use because we did not want it being used for mainstream editing, but that obviously did not last. As to the other guides for other games, the Wiki is a single system and all pages hosted on it will need to conform to its look'n'feel, and the primary purpose is currently for supporting STEP for Skyrim. However, we can certainly look into options for providing separated spaces for other games where they can have their own distinct look'n'feel. This impending change also is not going to be a huge loss in functionality either. Styling can still be applied within the rules of the MW parser. Eliminating the CSS extension will prevent the breaking of display for elements that should not be touched, unless it's a skin level change. Re-use of ANY wiki markup is not a valid excuse either. That's why templates exist to prevent repetitive coding.

There will be things implemented in the skin within reason based on feed back when we get to that point. But yes, we do need consistency within the Wiki, and the css extension is being used for purposes it was not intended for. Sorry, but it's being abused and will continue to be as long as it's available. Certain styling can still be applied in wiki text, but modifying major elements that isn't supported by MW will be discontinued in the future.

Just a gentle reminder that the css extension will be going away when the wiki skin is refreshed. Far too much hacking going on with it.

What you are seeing is because of the H5 element which has a text-decoration of "underline" applied to it. Wiki headers get wrapped within a span element tagged with a class of "mw-headline", and you are clearly including the image and the link within the header element, and thus the underline gets applied. It has nothing to do with the link, and is not "odd wiki behavior". It's perfectly normal. Applying additional "stuff" inside a header is uncommon. They were meant to be plain text, and adding images, links, and whatever else one could attempt to do is bound to produce odd behavior.

The original implementation of the extra external links was foobared. I hadn't noticed before, but it's fixed now.

I don't want it hiding without a very clear indicator that there is supposed to be something there. Even then, hiding it by default will make it even harder for those folks too get around that don't know about the menu bar

It's the churning that is the tricky party.

The anchors are working exactly how they are supposed to. The issue is the permanently placed top nav bar which ends up hiding the header that was jumped to. A work-around is possible in CSS (and was implemented at one time), however it only worked well in Firefox, and not 100% in IE or Chrome. It also ended up screwing with the padding surrounding the headers and made everything look out of place. There are javascript solutions which work much butter and more consistently, I just haven't gotten around to implementing.

@Crazy_San You should be able to log-in to the Wiki now.

I did verify that the wiki does not have a previous record of you. That means it is definitely the underscore that is causing the problem. Should be an easy fix, but won't be able to work on it till the weekend.

I'm currently in St Louis on business travel, and unfortunately don't have a means of investigating right away. I'm flying back home Thursday night, so can take a look Friday or sometime over the weekend. Also a follow up to Crazy_San, were you ever able to login to the Wiki? Particularly before we switched forum software?

The "issue" in regards to the same browser not being able to handle multiple requests concurrently in MW can be resolved, but it's going to require an additional component, and subsequent recompile of PHP. Not going to happen overnight, but it's on my list.

That is mostly because the other tab in the same browser is utilizing the same php process (session related) that is currently handling the save edit request, which is causing the blocking within the same browser. If you load a page from a completely different browser, you should not get blocked during a page save. I'll do some research to see if there is way to help alleviate the issue.

There is no auto-save in the Wiki. You can enable edit section however, it is available in your user preferences on the Editing tab. Make sure that Enable section editing via [edit] links is checked. Headertabs also allows edit links to appear, but we had disabled them due to display issues when there were a lot of tabs. We can enable the edit links for Headertabs again, but it is also a case for not including a large number of tabs. At some point, the Wiki skin will get an overhaul to provide much better navigation, particularly with respect to table of contents. Once that occurs, there will honestly be very little reason to keep Headertabs around. Breaking content up into multiple pages based on major content will be preferred as it also helps to keep the amount of information required to be loaded to a minimum (which is particularly important with respect to the inclusion of a large number of image resources). That's a ways out though. However, using Headertabs liberally is still a good idea today.

I can see edits on the wiki potentially causing 504 errors. There is a timeout that is set for php scripts, so that may need to be increased. Saving edits shouldn't block other users from being able to view pages though. I'll do some tweaks tomorrow and see if it improves things.

I just did 50 page edits on random pages and didn't see an issue. The editor loads lightening quick each time. One guess is a cache issue, in that the javascript is not caching in your browsers. For firefox you can check the following by typing "about:config" in the address bar. Click the button that says you will be careful, and search for the following settings: network.http.use-cache browser.cache.offline.enable They should both be true. If they are true, will have to brainstorm a little more. EDIT: If any of you get to the point that the Wiki Editor display is reproducible, you might want to open up the debugger (Ctrl-Shift-S) and profile a page load.