stoppingby4now

The long load time after saving is due to the Wiki rebuilding the page cache which it has to do after every edit, as well as saving information for the edit (diff of changes) for the history. It's what allows regular page views afterwards to be much faster. 504 errors are due to timeouts, which could be at any point in the chain from the web server, to the database. For those that get 504 errors, do they occur during specific time ranges, or are they random?

Issues like this are generally due to javascript not fully loading. Can you think of something you are doing that may interrupt a full page load? Also, what browser are you using? Any plugins for said browser that may interfere with scripts from loading, or any security software recently installed? I've tested a few pages and haven't seen an issue yet.

You can't have a cookie created by wiki syntax, but the core code uses them to associate your session. With JavaScript, a separate cookie could be used for storing other useful information such ads settings.

You can keep the topic alive, but I don't want you getting frustrated attempting to do something that can't currently be done. Truth is, some of what you want to do would be beneficial to the masses, but i don't currently have time to work on the solution. But, if someone wanted to develop something in their own test environment and submit it for review, it could be implemented. JavaScript would be able to handle your idea regarding selecting mid manager and then only showing specific content, and the settings could be saved in a cookie. That would be better than a user setting page because then guests could utilize the functionality too.

I don't know what you are referring to about dummy images. Browsers treat resources based on url. If an image is used multiple times and the url is the same, it only exists in the browsers memory once. If the url is different, it's loaded multiple times. So if you end up using the same image on the wiki, and one is 200px wide, and the other is 400px wide, the urls to thumbs are different, and there are two images loaded by the browser.

I hear ya, but your vision will have to be flexible in regards to the number of images you are planning on using. For example, if you prefer a single page to be able to display 50 images, having 450px thumbs will cause a significantly higher load time than 150px thumbs. While your vision may have been to have the larger sized thumbs, to be practical you may need to use much smaller ones. Google images is a great example of what really needs to be done, and that is to load in stages, and to initially show compressed lower quality previews, both of which we don't have a mechanism for.

The user settings affecting the display of the guide won't work. Providing the user a choice of mood manager to affect what gets showed won't work either without custom JavaScript, unless there is some css3 way of handling that (which there might be). Having things remembered per user won't be possible however. That is, not without custom code, either via JavaScript, or an extension, and using cookies. I do like the ideas, and i had traveled down a similar path when trying to utilize a users system config information with tickets, but it's just not doable.

Grouping a large number of screenshots into sub pages would be one alternative (just no main content in sub pages). But also don't be afraid to break up the content of a guide and place major sections into their own top level pages, particularly if there will be a lot of images. Using a category to correlate them ads Z mentioned would then tie them together. There is no hard and fast rule that says a guide must be one page only.

Before we get off into solutions, I need to review the extension. It just hit me that I believe I was using wiki methods for the initial generation of the html for drawing an image if it was hosted local, and then wrapping HighSlide around it. The implication being that what is initially shown on the page would be a much smaller in size thumb, and not the original full-size image. The full-size image would then be loaded when the gallery is first opened in HighSlide. Can't do that for external images though. It's been awhile since I wrote it, so will review and report back. EDIT: Yup, that is what I did. Obviously there would have to be some testing, and I doubt you'd still want hundreds of thumbs all loading on the page at once, but it really depends on what the thumb size ends up being. In this case, the smaller you can make the images for adding to a page, the better (like 100 or 150px in width). That's what makes Galleries so great. A smaller thumb size on the page should not matter, as the real glory is displayed when the gallery is opened.

We'll just need to work out a multiple page structure for your guide so all of the images aren't loaded at once. A guide with smaller images that depict UI, or clips of settings aren't bad even in mass, but when you start throwing 1080p screenshots, 10 is really the limit for an acceptable user experience. Best to probably break off the screenshots into separate pages, and associate everything with a unique category.

There was an implementation already called HighslideThumbs, but it did what almost every other gallery extension did and considered all images in a page to be in a gallery. I wrote HighslideGallery because not only did I want to create multiple galleries in a page, but I wanted control over what images would be galleryfied (new word), while leaving others as basic images in-page. From what I can tell, my extension is also the first gallery type one that generates all of the code for the galleries during the page cache phase and is saved in the actual cache, while all the others modify the html on-the-fly for every page view pre-render. Though to be fair, the others were all written before a hook was added in I think version 1.17 which made that possible. :)

No they won't. All of the code for the page is loaded in one go, so the links to the images exist, and the browser will load them. Makes for awesome instanct views when switching tabs, but not so great on the load time.

If you have a mic, I can see about setting aside some time some evening and work with you through using SMW on our Mumble server. The highlighted text in the quote above makes me cringe, and I would say just from the words used it is not a good solution. You should never have to create a dedicated Wiki page just for the sake of containing "variables" (and I'm not sure what you mean by that...semantic property?)

What are you trying to do with a user settings page? If you are wanting a wiki page to be able to reference a users "settings" as it were, I can pretty much guarantee you will not be able to do that. There is no mechanism for being able to determine the username that is viewing a page. As to Z's reference, I don't necessarily work backwards from Forms, though I have on occasion because the Form is the first thing I wanted to create. What I don't do is define property pages as the first thing. I find it too limiting during the design/implementation phase as I'm often restructuring before the final solution. When using the Wiki provided Special pages, they require properties to be defined in order to be useful, which is fantastic if you have a a very clear and solid design up front. If you don't, you'll be in maintenance hell with a slew of Property pages that need to be cleaned up. Which leads to a potential question you may have, and no you don't have to have Property pages defined for them to work. The system will figure out what they are. Though I do believe there was a special case or two regarding forms where if the Property wasn't defined, you couldn't use some functionality. I just don't recall what those cases were. But at some point Property pages do need to be created so the system can be efficient. You can also create test pages in your user area (sub pages). You can delete any sub-page in that area.

There is no hard limit, however there is a practical limit in that you don't want 100's of images having to load on a page for every view. The gallery ID can also contain letters as well as numbers. 1, A, 1A, 2345ABC, ABCD12 are all valid for example (it's just a string that is used as part of a div id attribute, and associated in highslide during initialization). If you don't specify an ID, one is randomly generated and guaranteed to be unique, in which case that image will be the only one in its own gallery for the page.

SMW is great at making associations. It's what it was designed for. The problems with implementations are when associations are attempted that have no consistency. Even given a number based solution, who is to say that your 1,2 & 4 selections will produce the same result as someone else's. That is when it becomes specific to a particular guide or pack or whatever. The parser functions won't help in this kind of scenario either on a generic level. This means authors will have to implement additional functionality themselves.

html 5 includes a new button tag, and there is still the input tag. They won't do anything, however, as the tags will be scrubbed by MW. I don't see it as being an easy task to implement what you are wanting. A selection of n choices, with the potential for a resultant set of instructions that don't have a direct mapping to those choices. That leans to needing javascript that is coded specifically to your case. How would one go about embedding anything in the page that would provide the means for determining what text should show when the choices and results may not directly map? If the choices directly mapped to the result, this becomes much easier to implement, though still not without a little bit of headache. Things like this take me back to the Data Dictionary I created. The goal was to provide an easy means of entering data via Semantic Forms which is great for ensuring consistency in presentation, while allowing for management of "blocks of information". That means, that I only wanted to have to edit a form table, or a template table, without having to edit the whole bloody page. I succeeded in that task, but the implementation is rather ugly and hackish since the implementation is somewhat out of the bounds of what Semantic MediaWiki was made to handle. It required the use of sub-pages, which I don't like, I think 9 different templates, and three forms if I recall. The whole setup can be hard to follow, even for me. I'll caveat this all with I'm pretty sure I understand what you are wanting to accomplish, but there is still the chance that I don't fully understand and that it isn't as complex as I currently believe it to be. I'll re-read through things again when I get a chance and work on ensuring I believe I understand 100% of this. For now, I have to prepare for a maintenance schedule for work tonight.

I agree with you on the interactive part. At some point though, a wiki becomes less ideal. It wasn't designed to be dynamic, and in turn lacks the ability to have anything but the most basic logic. Nor do you want that in a wiki. Their power comes from caching pages to eliminate expensive database lookups. JavaScript is really the only avenue at that point, allowing manipulation of displayed content with data that is delivered with the page. I've felt this way awhile now, but it's almost time to think about an in-house solution, or specifically something that provides more power than a wiki for complex setups.

What you are trying do isn't readily possible. There may be ways to get close, but it will surely break when options become complex, or rather the possible combinations and expected results doesn't have a 1-1 relationship. In regards to adding JavaScript and making it trusted, that certainly can be done, however it needs to be applicable at large as well. We don't want to allow a process of having a bunch of requests for JavaScript additions that only apply to a specific page, or very small corner of the wiki, as the benefit is small as the amount scripts that need to be loaded by the browser increase. There is also the issue of tweaking JavaScript to be usable in MW since they lockdown it's use so nothing had global scope.

Is this what you were using the collapsible content for? To initially hide the extended text, but allow the user to show it if needed? Based on what you just said though, there isn't a way to control asset the level you are seeking. The mechanisms that are available are very simplistic and don't provide logic mechanisms that you would require.

Ok, I see. It would be possible to use a Boolean semantic property for this, which is what a checkbox would represent. You can also only make a tie to a single field, so you're example of an AND wouldn't work, but I don't think that will be a problem. Unless you the expected result of the AND would differ from what each selection individually would produce. To make this generic, would likely also require the ability to add selection choices within the form, along with result that should be displayed. But given all of this, I'm not sure what making all of this semantically would buy you, since this would be managed purely within the form. The only way at present that I see this making sense is if all the options are maintained as data associated with a mod, such that associating mod would result in the choices being available within the form. So I guess I need to understand, is this intended for use with packs?

I'm only seeing a description about the user experience. Can you describe more about how you want the form to handle choices? Ideally with some examples. The intended use will ultimately determine if it will be feasible or not.

I'm not sure I entirely understand as I haven't looked at this closer. If you are referring to the generated page, there currently isn't a mechanism for allowing a user to click certain things and have others show based on logic. MW does not provide that sort of functionality, and would certainly require an extension to be able to handle that. If, however, you are referring to the creation of the page via Semantic forms, there are methods to be able to allow certain fields to show/hide based on other selections. It can get very messy very fast though, and isn't easily done when the number of choices start becoming astronomical. You are essentially limited to what can be queried on things like a semantic property, categories, specific pages, etc.

Very odd. I have the same version of TT, but android 4.4.3, which shouldn't matter. I tried searching from main page, as well as the search icon inside a forum, and I get results. Not sure yet what could be causing the issue.

The TOC can be auto-numbered, but headings are not. The latter is a user preference available under the top menu. <user>->preferences->appearance Under Advanced Options, tick the Auto-number headings checkbox.