stoppingby4now

It is possible, and something I plan on addressing.

Not 100% sure without further inspection of code, but based on the hook points that are required for the CSS extension to work, I'm almost certain it is due to the MW parser rejecting the URL. There are protections built into MW to prevent people from doing bad things (can't use anchors directly, have to use MW markup for URL's so they are properly sanitized, etc.). If that is the case, nothing we can do about it without opening ourselves wide open to much more serious problems. EDIT: Just read DoubleYou's post, and I'm absolutely certain now it's the parser scrubbing the contents and ultimately breaking the CSS entirely due to invalid formatting. Result: no changing of background using url's.

There was a problem we experienced where the first element override was not applied on the STEP guide, and the fix was to create an empty reference. Doesn't appear to be working here. I have no idea why it's not working. Maybe it's because the css on a page that is the standard for user overrides. Maybe the extension doesn't allow overriding the body (the MW page says you can, but who knows if that changed and documentation wasn't updated). Plan is still to eventually get rid of the CSS extension.

The plan has always been to get away from needing the CSS extension. It was never intended to be used by everyone. If we are at the point of looking to start support for additional games, we might want to see about standing up additional instances of MW so they have a common look and feel that is their own. In addition, I just checked the page you linked, and I see the background image applied.

I'm not entirely sure what method is being used, as Z linked me to https://wiki.step-project.com/User:TechAngel85/MassEffect.css. Overriding CSS is applied Wiki wide, and is done by either overriding a specific skin, or making global changes. In our case, both will have the same effect since we only have one skin enabled. SKIN SPECIFIC https://wiki.step-project.com/Special:MyPage/step.css GLOBAL https://wiki.step-project.com/Special:MyPage/common.css The link that Z provided me from Tech is not valid and will not override anything. There is the CSS extension, but that was only installed as a workaround for the STEP guide. It is not intended for the masses to modify pages, thus altering the default look as it applies to everyone. Once MediaWiki is updated and the skin updated (which is required due to changes in MW), changes will be made to better support the Guide and similar rare cases where the CSS extension was necessary, thus making it obsolete and removed.

I just read the thread on IPB forum. The changes to auto save in 4.0 will make this a non issue.

Image type remains being enforced for now. The only way to do that is by way of extension. This does not mean that this won't change. I'm doing some research.

I've personally found the auto-save feature more than sufficient. Being aware of it's behavior does help, and that just takes knowledge sharing. Though I have to say, I'm having a hard time believing that one can generate so much content in less than two minutes, that needing to save a draft manually is actually "that" beneficial. Such content could easily be recreated. But, the other problem is you look at things like this purely from a user perspective. The mention of multi-quote is not a valid comparison, as that is purely a client side function until you initiate the reply (cookies keep track of selected posts). Editor saves uses Ajax to send data to the server, and saves the data in the database. The problem with that is a bad guy could script that easily to initiate manual saves in tons of threads without ever leaving any trace of spam on the forum. The auto-save feature prevents that from happening because it can't be forced. Again, the only way to prevent said behavior would be to limit the frequency in which manual saves can be performed. Get too many users doing it at once, and suddenly you can't manually save, and hence loss of user functionality. Granted, such a problem would only be problematic with higher levels of users being logged in potentially writing posts, and then a small portion of them wanting to manually save them. But it's still a dangerous feature without safeguards. Cost to benefit ratio is very low IMO. In any case, I highly doubt any traction will be made on it becoming a feature, so I suggest getting used to the behavior of auto-save. It truly is useful when you are aware of it.

@Z That is why education is key. You now know the feature is there, and it is worth making a sticky of it so that the community is aware. The only non-intuitive piece of it is not knowing about it without hitting the first 2 minute auto-save point. Having a manual form of auto-save could also allow a baddie to spam it across the forum to build up useless data, and/or spam the web server. The only way to prevent that would be to limit the frequency in which such a manual process could be performed. Having an automated save alleviates the need to do that, is consistent, and works everywhere, all the time. This is not a desktop application, this is a web interface that supports multiple users. @CJ You need to click in the quick reply box to engage the editor for the message to show up that Saved Content is available.

Yes, really. Auto-saves occur every two minutes. When the editor auto saves, you will see text in the bottom bar that states "Last auto saved: XX:XX:XX PM". They are also associated at the thread level. You can test by typing something and waiting until you see the text. Then navigate to another thread and start typing and wait for the auto save to occur. Then go back to the first thread, and you will see text in the bottom bar that says "View Auto Saved Content", and you can restore the "draft" that you were working on for that thread. Same thing at this point, go to the second thread and you will be able to restore your last saved draft for that thread. The functionality is there, and it's even better that it's automated. If you really need to work up a draft, offline is a better method. Consequently, this is similar to desktop applications that auto-save content at set intervals so it can be restored should the application crash, or be force closed. There just is no need for a manual Save-as Draft.

Short Answer: It should be very simple to get the same look and feel in the tables. The STEP tables are nothing more than a template that generates table contents based on results from a SMW query. The same should be true for Packs, which means the "styling" can be setup to mirror the STEP tables. I wasn't involved with the setup of the Pack stuff, so I'm not completely familiar with what was done (yet). Pack look'n'feel should mirror that of the STEP guide though, so it's something that deserves attention.

Hate to burst your bubble, but this functionality already exists in the form of auto saves. For what ever reason, If what you were typing is not available and you go back to the thread to reply, it will ask you if you want to restore your last saved draft.

"It will be ready when it's ready" I am indeed working on a plugin to get high slide implemented in parts (same as I did for old forums). Modifying IPB behavior is significantly more powerful than with MyBB, but with that comes a greater learning curve. I'm about 60% done. Have been able to quick hack it of sorts, but need to separate things into their proper implementations. The time consuming part of learning how to override things is at least out of the way. I'm also on call this week (till Friday), and that takes priority, along with work at home. Gotta keep my better half happy. Not even going to attempt an ETA, because life tends to get in the way and make a liar out of me. But soon.

I don't want anything above 20, especially when threads end up having a lot of screenshots. It adds to load time, and not everyone wants a really long page that seems to scroll forever. Either we go with 15, or 20, but it needs to be finalized. Continuing to talk about It further messes up the search engine results if it is to be increased. Once chosen, it will stay.

IPB removed the user setting for number of posts per page due to SEO support. If users were able to change the settings individually, links to a particular page that contains a matching post likely won't match. This could be affected by someone copying the URL and passing it on to someone. However, the bigger issue is when dealing with search engines. They would always gain the default, so let's say that was 10. You set your personal preference to 20 (if it were available), and then do a Google search and a link is available to the forum that matches what you searched for that is on page 4 (based on the default of 10). Due to your settings, it would actually be on page 2, and thus the dilemma because the link would either attempt to take you to a page that doesn't yet exist (not enough posts), or would take you to the wrong page entirely. I have no problem with a setting of 20, and there is no technical reason why we can't go higher than 10. 50 is too extreme as a global default.

For some reason today, I can't edit now. XExternalEditor loads, then throws an exception: "Edit time not found in HTML document". That was one of the errors I used to get with a corrupt ini file, but not helping this time. Based on the page history, it looks like you can at least edit normally via the Wiki. I'm not finding any cause as to why you would get that error, but still digging. However, as a heads up, version 1.22 of MediaWiki has completely removed the ExternalEdit functionality. When we upgrade, that capability will be lost.

I have 4 Hitachi Deskstar's in an external chasis which have been running for just over 4 years now. I have had two DOA's in about 8 purchases, but no premature deaths so far.

I have only found a few users so far and corrected them. The majority seem to be just fine. A sure fire way to tell for any user would be if they have edited their user page, but suddenly it appears blank when they visit it. Second would be to search for any edits they have done, and they will seem to have vanished. If none of the above apply, they will never know if they are/were affected. The cause is I'm now enforcing username case to be matched with what is in the forum via the Auth IPB plugin. I wasn't doing this with the AuthMyBB plugin, which was an oversight and the case as applied on initial creation was matched with whatever the user typed in to login for the first time. However, that causes problems. I first became aware of it while testing when I noticed there were two users for the compiler. One titled Thecompiler, and one titled TheCompiler. That's not good, and I have fixed that from occurring again.

I fixed this yesterday for Tech, but others may be affected.

I agree. WD drives back in the late 90's were top notch. I had 5 brand new WD's fail on me awhile back, 2 DOA's, 3 spindles were going bad after about 6 months, failed in under a year. Just unacceptable. I stopped RMA'ing them and ditched them for good. I've been mostly sticking to Seagate drives. It's been a long time since I've had one of those DOA, and I've only had one in the past 10 years fail prematurely (under a year). I even have a much older 500MB Seagate IDE drive installed in my Firewall box, and it's still purring. Most of these varying drive types are ultimately a disguise for varying "acceptable" quality levels, wrapped in marketing jargon. It comes down to, you either pay top money for a product that has a much higher guarantee of quality and has been fully tested, or you pay much less for a product that has been deemed "good enough" or "acceptable risk" and shoved out the door without a moments thought. I don't know the practices of every manufacturer, but I've seen a manufacturer first hand take the "failed" Enterprise, RAID quality drives and demote them to Consumer level as long as the spindle still spun and data could be written/read, and the firmware re-flashed. These were 10K/15K drives, demoted to 5.2K to hide the issues.

I rarely close my browser either. Maybe you didn't restart it after you installed Adblock Plus? Can't remember if that plugin requires a browser restart.

He already stated he has no other browsers installed, and that you couldn't pay him enough to open up IE. :P

Go figure. Their calendar allows users to choose the time format. Why this wasn't carried into the forum is odd.

My average JS load time is right around 300ms. The next thing to try in Firefox is forcing it to reload with addons disabled and see if you experience the same thing. Firefox->Help->Restart with Add-ons Disabled. Also, which JS is taking the longest time to complete?

I've been checking the forum all day, and have not experienced any slow down at all. Since you are using Firefox, try running the profiler to see if any javascript is taking a long time to complete. My initial page loads are timing in around 300-400ms, and a little over 2s for full rendering to complete. From a server perspective, there isn't anything causing this.