stoppingby4now

I had a misconfiguration on the database and had over-allocated resources. Should be resolved now.

The recent issue with the forum revealing the database problems has nothing to do with thread size. It was a configuration on MySQL that was causing out of memory errors (I over-allocated). IPB is somewhat decent on its queries, using LIMIT's on a thread view to reduce the number of rows returned, and it caches frequented views. I currently don't see an issue with the forum, and breaking apart threads right now would only induce a placebo affect. The Wiki is the real beast currently.

We had a spike in requests again today. Any reports of slowness?

Performed maintenance tonight to implement some relief for the Wiki. Please continue to report any 5XX errors.

Testing is in the works to get a solution in place to help with the slowness. Likely won't be able to fully implement till the weekend assuming my testing pans out OK. Either way, there will be a last minute maintenance to implement when I'm ready, since I don't know when I'll be fully ready and I want to get this setup ASAP.

Current caching is good. I can't test during the day, but during lower peak usage, the wiki is loading fast for me. The larger culprit is being driven by a spike in in-bound connections that starts just after 9AM server time. This directly impacts server load. Increasing the number of processes to handle more connections will also directly impact server load, potentially more negatively than the current state. You also have to take Pingdom with a grain of salt to a certain extent. It is connecting as if it is a first time user, which means there is no benefit of client side caching of all of the resources such as CSS, JS, images, and initial page view. There are a lot more resources being loaded for the Wiki compared to the Forum. A test via Pingdom in the past 10 minutes reported a little over 10 second load time, but a refresh in my browser was under 3 seconds. There are some things I can look at implementing to help reduce the stress further, but will take some time to setup and test.

We had a 4X increase in normal traffic, and had a configuration issue that was rectified. Should be performing a lot better since yesterday early evening.

I just implemented a fix to the site backups so that they won't affect Wiki performance anymore.

Unfortunately, there's no way to search for pages created by a specific user.

Very interesting. It was the single quotes in the caption portion that was breaking it. Looks like I have a bug in the Highslide extension.

There is no search capability for history. MW search only searches wiki pages based on their current state, so searches won't match on text that was removed from a Wiki page for example. Two things that pop to mind you can try: You can do an advanced search to limit the pages that are searched. Sounds like you would want to limit based on the Category Mods. Not entirely helpful if the category in question contains a lot of pages like Category Mods, but it would weed all of the guides which may be enough. You can also see your history by using the menu option for your name and selecting Contributions. Not search functionality, but it will show you the edits you've made and maybe you can spot the page you edited.

It is better to add a post at the end of the topic referencing the correct topic, and lock It like You did.

The letter-spacing is a nice touch, and offers by far the best improvement for reading the actual header. Not going to implement width due to the pulling of the EDIT link along with it. The alterations to the headers I'm just not feeling. There is plenty of space for separation between a header and the content above it, and you're modifications are adding more. I'm sorry, I'm just not seeing the difficulty in identifying the logical separation in the current setup. I've updated the wikidev with the letter-spacing (0.02em) on the header content itself, as well as the borders on h2/h3.

I've been wanting to delve into drupal for the means of providing the actual guides, with queries into mediawiki to get mod information, etc. The wiki, and even semantic mediawiki just isn't meant to handle the kings of things that are needing to be done to support things like packs. EDIT: Corrected my phones autocorrect.

There will also be changes coming down the road with the integration of Zurb Foundation.

I did not like that the version initially reviewed referenced JS from another site. I have no issue with adding syntax highlighting support, but I would rather the JS be hosted locally. Will review for the Wiki upgrade.

I can agree on that. I can certainly help with Dev wiki updates, as well as the navigating guide.

Except where it causes confusion in regards to how links are being generated. Given the problems associated with the external link method, regardless of how infrequent, it is far better to teach users new tricks via a short blurb at the beginning of every guide that not only helps them on this Wiki, but on the internet as whole. It also removes the case of someone else coming along 5 months from now and saying, "Why are these links using external when internal is so much better? (because they are)". It also provides poor examples to new-comers on how to generate links if they take guides as a reference point to learning how to do things. Learn one new trick, or risk N number of problems with the current solution? Seems like a no-brainer to me. This is feeling like a "Can't teach an old dog new tricks" situation. :) EDIT: Bottom line is, internal links are better than external links for pages on the Wiki. They exist for a very good reason, and it is not best practice to use external link's for internal pages. There are edge cases such that you have to use an external link to use the API (such as providing a link to edit the page within the page itself). Best practice is consistency, and that is being broken on more than one level. While I agree it is desirable to have the links open in a new tab, it is extremely simple to do so without breaking convention, while also avoiding confusion. The needs of the many can be applied here, however in the sense that there are more problems that surface through the use of external links that can be avoided by simply educating users on a means by which to open links in a new window/tab that is simple, provides an additional option (window versus tab), and can be applied in all aspects of their browsing lives. We should not be second guessing what is best for the masses based on personal preference, especially when it reduces their control.

I stand by that you are enforcing behavior that is ideal in a specific situation, but causes more issues on the flip side than it solves when there is already a mechanism in browsers to do exactly what you want. In other words, alter the unspoken standard on the web, rather than learning to ctrl click which does not incur any more effort from the user, while introducing higher potential for confusion on the wiki, which is why this thread exists in the first place. Ultimately, it it's far better to solve issues with navigating versus forcing UI behavior that limits user choice.

You need to re read my post. It is not 4 clicks.

I should also point out that in terms of best practice for MediaWiki, internal links are preferred because when databases are migrated (mirrored to other domains) internal links always work, where-as external links would incur a maintenance cost to update them all. For anyone running MediaWiki for their own site, should they move to a new domain, internal links will just work. There is a reason why there is separate internal versus external link handling. Not a huge case for us in terms of fearing a domain change, however, for development purposes and thinking of wikidev, all of those external links will point back to the live site rather than the new instance.

I disagree with the argument on the Guides needing to force internal links to open in tabs by treating them as external links. You are relying on a mechanism that could go away, deviates from standard practices that the majority of the internet as a whole follows, and adds confusion in how links should be generated on the Wiki. The extra click argument is also bogus. All major browsers support shift-click to open in a new window, or ctrl-click to open in a new tab. I use it all the time when searching on google and want to open several links without losing the search page. No extra clicks involved. It should be up to the user to control beyond the standard practice, which is external links open in new window, and internal links open in same window. It's also easily rectified by putting a short blurb at the top of Guides explaining the shift-click/ctrl-click behavior. Also ensures consistency in proper link generation on the Wiki as a whole.

Not true. Default behavior is to open a link in the same window. Links that open in a new window are using the target="_blank" attribute on the <a> element. The Wiki is configured to open external links in a new window using the above method. There is no configuration for internal links, and even if there were, it would not be changed. If a user wants to ensure a link opens in a new window, they can right click and select to open in a new window/tab. If a page really does need to force internal links to open in a new window, you must build them such that they are treated as external, but this should not be the norm.

My late dog that passed away back in 2012. Really hit me hard, she was my best bud.

There was a configuration issue in regards to the update of the Tapatalk plugin, and cache expiration was causing the forum not loading issue. All should now be resolved.