demongoddess061

AFF hosting company having issues again

2009-08-13T02:14:00Z

As the primary purpose of this LJ, is for archive related stuff, more so than personal....

Apparently the hosting company (Nexcess) is having a hardware issue or three. I expect it will be resolved shortly, please be patient while the techs there fix the problem.

Thanks!

AFF's hosting company is having problems

2009-03-20T05:58:04Z

And here I thought it was just me...

In any case, please be patient, I'm sure Nexcess will have the problem straightened out shortly.

Next step

2008-12-02T06:41:53Z

Well, considering that for at least the next year, I'm STILL limited to three category levels, only of two of which are posting levels, I've come up with something that will help a bit for the single fandom subdomains.

I've already deployed it here. I'm planning on doing this archive wide within the next few days as well.

Now, while I may be limited to what I can do RIGHT this second, this does not mean that I cannot continue cataloging for when the new software is finished.

At that point, I can make similar changes, down a level, in the multiple fandom subdomains. As well as put sub sub sub categories with specific pairs listed in their parent categories for the Crossover toplevels.

We (manta2g and I) are also looking at possibly incorporating some python generated scripts and mini programs in efforts to help further enhance what we're doing for the future software. Dunno for sure yet on that, we're still kicking it around. Good thing about python is that it is truly cross platform. That makes a difference.

Plus, I'm thinking with a combination of different algorithms we've been looking at for security purposes, I expect there will be many huge improvements we can make over all.

Back at the ranch here though...

Here is how this last change will work for the immediate. Please keep in mind there are only three levels I can work in right now. Top level, sub level, sub sub level.

At top level, will now be an AU/AR category, and a Crossover category. These are non posting, as all top level categories are.

2nd level in AU/AR is comprised of the default schema I've already deployed throughout the archive, for pairing types.

3rd level in AU/AR are pair specific categories.

2nd level in Crossovers is a bit more complicated. First, there are the pair types, plus, where the crossover world (i.e. BtVS/AtS) has 5 or more stories, it then gets a sub category.

3rd level for Crossovers is at the moment being devoted to pair type in the crossover world 2nd level categories, for pair types.

Once we have the new stuff written and in place, I'll be able to work up to 9 levels deep. At that point, that is where all this cataloging comes in to play. Just as now (in single fandom subdomains) we've set a minimum of 10 stories for a specific pair for a subcategory, it will apply there too. So, while I may not be able to ADD those right this minute, it will be done when we have the software written to handle it.

For example, in the BtVS/AtS subcategory in Crossovers alone, I already have earmarked 7 different specific pair categories that need to be created. We've still got to sort through the rest of the het sublevel, as well as the entirety of slash, femslash and threesomes. So I expect more will be added as we finish up.

Now, to why this is being done. Those of you visit AFF regularly know that the search engine is not designed to handle the amount of data we have. At maximum, that search engine is only able to handle up to 200mb of data to search. It has to search through 6.3GB, so searching is pretty useless. We have a search engine module which can handle very large datasets. That's not the problem. The problem is the current software itself. It simply will not support more in the way of major changes without imploding in on itself. That, of course, is not what we want. The data loss would be huge and simply unacceptable. If you look back at the other related posts about that here, you already know that's why we're repairing the corrupted table inserts, rather than outright deleting them. If at all possible, we're striving for NO data loss at all for stories already there, as well as maintaining whatever new is added. So, this is to help compensate for the search engine that can't. This way, a reader likes AU/AR, they can go straight to it an find what they like much easier. Same goes for Crossovers.

Apologies for the time this is all taking, I wish we could do this faster. Both the clean up, and various moderation tasks. But, there are only a few of us doing all this, and real life commitments and little things like sleep tend to make it so one can't devote every waking second to the task. *sigh* The site itself is huge and takes much time to go through, whether as a moderator, or when looking for the glitches and marking/noting them for repair.

Next few weeks, for example, my time is even more tied up in knots than normal. I'm down to one day off only a week, while we find a new hire to replace someone who was let go last weekend. It's temporary, but overtime is always good. ;-)

Archive update stuff

2008-11-03T15:52:49Z

this is going to be a loooong post...

After I was out sick for over a week, there was much that fell behind. Needless to say, between my being ill, and another of the mods having to replace her computer, there is much that is backlogged. As a result this post will detail several upcoming things, as well as general status of some things.

Disclaimers and updating them
I did a one time task, and updated the disclaimers archive wide, with the exception of stories in crossover sub categories. Those need all worlds involved in the story to be properly disclaimed. For the miscellaneous categories and sub categories, the disclaimer I added is quite generic. It still covers the pertinent points, for the most part. The authors need to finish that part of the update. I simply do not have the time to manually edit each and every story in the many crossover sub categories, nor the many miscellaneous categories and sub categories.

As before, the moderators will be going through and checking these, and letting the users know what, if anything needs changed and/or corrected with the disclaimers. The link to the FAQ I'm giving below contains the bare bones of what is needed for each type of disclaimer, as well as other information the users should be aware of.

More information at this link:
www2.adultfanfiction.net/forum/index.php

Tasks in progress that have been delayed

These will all be addressed and caught up, and not necessarily in the order listed.

Dealing with the plagiarists (there seems to have been an explosion of this lately)
Upgrading the forum so that guest posts no longer have to be approved, and are immediately visible again. I do this work from one of my other machines which was infested with viruses, took about 30 hours for the damn thing to completely scan a little over 260GB of data. So, now that the machine is clean, I can do this and a few other things I do from that machine.
Eliminating the minor infestation
Adding the requested FAQ files
Adding in a couple fairly major changes to the archive which are admin functions (for more than anything, handling the spam bombs in review boards), but making sure it doesn't crash it due to the script's age. That's always an issue, so we have to be very, very careful when adding in tools and/or improvements. Because of the difference in language structure with what we're currently writing in, and what the archive itself is written in, it can cause all kinds of weird problems, as well as crashing the whole thing. So, as I said, we're very cautious in adding anything very new to the old scripting.
Continuing the clean up of the archive itself in preparation for the new stuff being written.

There's bunches more, but I'm tired so I'm not going into more detail than this at the moment.

*sighs* back at it I go....

Hopefully back at it with the repair

2008-09-10T16:08:20Z

Well, I've been a bit sidetracked from it, while getting the archive moderator situation fixed. All the new mods are training up very well, and the entirety of the archive is now looked at daily. Apparently this is not the way things were done before? However, with an archive THIS size, it's truly necessary. 21 subdomains to check, and my head is still spinning at the fact that they were not each looked at every day, as they should've been.

Anyway, still in Buffy>Het>Buffy/Spike(William), almost done with it. As soon as that's complete, the rest of it should fall right into place in very short order. Then, we go on to cartoons. Hopefully, we'll get back into it quick enough to make some real progress here very very shortly.

AFF repair update

2008-08-02T10:42:18Z

Well, as a result of this ongoing repair, the archive now supports successfully over 1 million unique visitors a month! This last month, July, the site overall had the most traffic ever in its history; 1051030 unique visitors. Mind you, were it not for the ongoing repair and organization, there is no way in HELL the database would have supported that kind of traffic for the archive. It's actually the first summer I can remember in quite a few years where there wasn't constant "downtime" because the database was getting overloaded.

We've finished the sort for both the Crossover and AU subcategories in the buffy subdomain, and are now working on the het sub sub Buffy/Spike. There were 667 stories that were unsorted yet, so we have to go through those and note the glitches and etc.

We've added another sub sub to Crossovers, Anita Blake/BtVS. I expect as we continue to go through the remaining sub categories, that there will be more sub subs added to both AU and Crossovers.

Details as to new top levels and sub subs created

2008-07-15T01:04:54Z

This, after only sorting the General category in the buffy subdomain..

forum post detailing added sub sub categories and where they live

Archive clean up and repair progress report

2008-07-14T09:28:20Z

To date:

Have found and repaired the various glitches and other problems in the books sub domain. Have recategorized and sorted where a sub category has 75 or more stories and is remaining at second level. Where a sub category has 200 or more stories, it has become top level, and has been sorted accordingly.

The sorting helps to compensate for the sucky search engine. until we actually get the thing replaced with one that is meant to work with a large database. That IS a ways away, however.

Have found all the glitches in the buffy>general category, also sorted from it to the second level categories where the stories should actually go now. Most of those second level categories did not exist prior to this. Also, for second level categories, where there have been ten or more stories concerning a specific pair, a sub sub has been created, and the stories moved. For Crossovers, the sub sub sort is based on crossover worlds.

Am about two thirds done with repairing the different corrupted stories and chapter that have been found and posted in forum so far for where we've sorted in general. This being the oldest part of the archive, I'm not surprised that so far, it's got the worst of the corruption. My team and I are currently working in AU for final sort and corruption check for that sub category. Next up is Crossovers, followed by the pairing types.

The joys of database repair (NOT) part 4

2008-04-28T04:40:27Z

This is the last of it....

Here, I'm going to detail out EXACTLY what we're doing.

This is the cleanup phase and what is entailed.

First of all, what we're doing now, much of it SHOULD have been done following the subdivide of the database tables. However, due to being politicked out of what she was doing, manta2g wasn't able to do anything about it until recently. So, those that were left in charge, did not do what was necessary to finish up fixing things after the first major crash, nor did they do things to prevent the subsequent minor crashes which followed.

This is actually where I come in. I actually have done this sort of thing for years, as part of my job IRL. Not only have I prevented major db crashes, I've had to recover from them as well.

The DIFFERENCE is, when doing it for a business one has hard copy records to work from, should the data be unrecoverable, which I encountered more than a few times. In this for instance, we do not. So, in order to prevent another major crash, which would've caused tremendous data loss, I've set up this whole project. manta2g has been aware of it, of course, every step of the way. We (the techs) all have our strong suits, this one is mine. The nuts and bolts of how a database works, and keeping it healthy and viable. Also, making it so a crash can be prevented.

So on to the project...

Phase one is already complete. This was the initial recategorization across all the subdomains, and the deletion of the categories now handled in the forum. This meant that I subleveled and split as much as I could, to cut down the query load.

Phase two, is going through each subdomain. A category at time, a story at at a time. What we are looking for are the following:

"wordord" glitch in chapters. These are the remnants of the 2003 crash. Where they have been found, I go direct into that table and fix it. I am NOT proofreading, simply fixing the duplicateplicate (yes that's intentional) words where they are found.
no author glitch in chapters. There are chapters which lost their link to the author who added/uploaded them. Once this happens, the author has no way to access that chapter. Ever. Unless it's relinked. They are being relinked.
endless horizontal scrolling...
About half is corruption (a variation of wordord) and about half is user input error. Regardless, it's all getting fixed once it's found. Whether in the chapter or the review board.
Review board checking. There are duplicate entries, there are glitched entries (they have no data at all, just a user name, usually). Troll and spam entries as well. These are being found, noted, and deleted.
Orphan stories. When one is looking at a page of stories listed, there are stories with no author attached. They, and their associated records (review, chapter, rate) are being deleted once found.

Then, there are the new top level categories, and the categories which look like they will grow IN to top level categories. Each are being sorted and the data shifted around. The new top levels, this allows us to further subcategorize the larger ones where a story, for example is a pair type. Then, it features a particular pair. This makes it so we can work those three levels. Which once again reduces load on the database and the server. The categories which look like they will eventually grow into top levels at this point, are being subdivided as well. Not to the level of a top level category, as that is not possible, but subdivided nonetheless. Again, the end result is reduction of stress on the database.

Hopefully, I've explained this in plain english enough to where it's easy to understand.

The joys of database repair (NOT) part 3

2008-04-28T04:21:51Z

Data insert and how it works with this program. In other words, why certain categories were redirected to the forum software....

The archive software treats each chapter insert as a FILE, not a flatfile text record. The FORUM is written to flatfile posting data. A chapter is equivalent to a forum post. I don't care how hard I try, I could never duplicate the sheer size of some of the records in the archives for chapters. It can't be done. It has EVERYTHING to do with how the software itself handles that data insert.

Also, the search function for this archive, was designed with really no bigger than a 200MB or so archive. Once it exceeded that, the search engine became pretty useless. Yes, we are aware of the limitations of the thing. Yes, it is going to be replaced. But, it can't be done NOW. So, this is why we've made it so that "searching for a fic", "resources", "challenge/request" and "rants/journals" are now to be done in the forum. The forum can handle the load, the archive cannot. By eliminating these categories from the archive itself, we ease the load that much more on the database for it.

Believe it or not, it started out at 6.2GB. So far, I've successfully trimmed 400MB from it. The goal is 1GB. That will help tremendously. After we're done finding and deleting the orphan records, as well as the posted search and etc fics that will no longer be allowed, across the various tables, we actually should reach that goal, or come very close to it. This will help to stabilize the database that much more.

The joys of database repair (NOT) part 2

2008-04-28T04:06:56Z

On to the next segment (I am not normally this wordy dammit).

Query basics.

This should help explain exactly HOW a relational database works, by using SQL (structured query language), and why certain levels of nesting are better for a database.

How this works is actually simple. I'll use the anime subdomain as an example. For each instance a page is drawn, each record that is called up for display, is a query. Because of how many categories were in that section alone, it basically executed 260+ queries per page draw, when browsing to the category page from the top level link. This is NOT good for an SQL server. What can and does happen when too many queries are executed at one time, is the SQL server will, in effect, shut down. For up to an hour at a time. Depending upon where in its self check cycle this occurs. What this means to the end user, is that the programs which depend upon the databases to run, CAN'T run. If the SQL server is in the middle of shutting itself down because too many queries are open, a user adding a record to it, will end up adding corrupted data. Sometimes the record is accessible after the server resets itself, sometimes it is not. If not, then what happened is an orphan record was created. There are many, many, many of those throughout this database. Orphan records end up causing an overall corruption effect, which can have adverse consequences for a database. Sort of like stacked dominoes.

In order to prevent query overloads, a simple and quick fix is to nest with sublevels. Of course, at this point in time, the software itself limits us to only three levels of categories. Period. Ideally, one should be able to nest downwards many levels. That will be addressed with the software rewrite in progress. It can't be now, so in the meantime, I've had to devise something that would work, working within those limitations.

This led to the initial recategorization of the entire archive, subdomain by subdomain. Some categories were made top level categories, to be further subdivided, and I've incorporated alphanumeric top levels for all the many titles. This has cut the query load significantly. The end result of this initial part of all this, is that there is far less of a likelihood of the SQL server having too many open persistent connections. Which leads to what the end user sees as "connection reset", "unable to load page" etc. As I said before, depending upon when in the SQL server's cycle this occurs, is how long one can't connect to the software at all. If it happens at the beginning of the cycle, you're looking at an hour of wait time. A few minutes before the end of the cycle, only a few minutes.

Something the end users were unaware of, when this part was started, is that we (manta2g and I) have had to LITERALLY babysit that database 24/7 for months. Since mid-August of last year. All this was so it wouldn't crash. When she came back on board, and I came on board for all this, at that point in time, the database was trying very hard to crash. Due to some query updates (xax is the query GOD you know...) that helped to forestall a crash. As did some major and minor coding changes, because the program itself is coded in outdated versions of the language it's written in. All of these stresses to the database itself were found and fixed as we could. However, it was and is not enough. There was still a very high probability of failure, hence the work that is being done now. This has all been done to STABILIZE the database. Which it has. Stabilizing the database buys us time to actually recode from the ground up, which is necessary.

The joys of database repair (NOT) part 1

2008-04-28T03:43:45Z

Yes, I say part 1. I'm going to be going in depth about many things, including past history with this particular database that I'm working on.

So, let's start with the 2003 crash, and how it came about.

First of all, at the time, the operating system for the dedicated server only allowed a maximum 2GB size database.

So, in order to AVOID a crash of this database before it ever got to that size, the then lead tech had wanted to split the tables, according to a split across subdomains. What this would have done, was to trick the OS into thinking that the database wasn't actually the size that it was, allowing for it to get larger without problems. A simple concept, a fair bit of work to implement, but it would have prevented the subsequent crash had it been implemented when it was suggested to do so.

Well, her suggestion was put to a committee. While she waited on a committee decision, the database kept growing. It eventually reached that 2GB limitation and exceeded it. This caused the crash. That crash was severe in nature. It CORRUPTED the data to the point that what was recovered, was near unreadable. Multiple repetition of words, where they had replicated themselves, and in many for instances the record entry was bad enough it couldn't be restored at all.

So, how this worked was this:

First the large tables were split, named according to the names of the subdomains created, and then the data transferred from those tables, to the smaller ones. Secondly, the program which accessed this database was then installed to each subdomain, and the scripts modified to ONLY parse the tables which related directly to the subdomains for most of the data. So, in effect, the operating system thought the database size was only however many megabytes each subset of tables was, rather than the actual size of the thing, which exceeded 2GB.

The end result of the crash, for the crew who's cleaning up all this crap with me, is we get to find all the STILL corrupted records, and then I get to fix them.

There were actually 3 crashes to this database, 1 major and 2 minor. The minor crashes created another set of glitches. The first makes it so that the author's id is no longer attached to the chapter. What happens as result of that, is that if the author wants to edit that chapter, delete that chapter, or whatever, he/she can't access it. At all. The end user can't fix this. It's certainly a simple enough fix, in that I just re-input the user ID and relink the chapter to the author. The second glitch was sometimes created by the db crash, and sometimes by incorrect user input. It's a variation of what I've come to call the "wordord" glitch, in that it frequently took a line of characters, and duplicated it. Which makes it so the screen doesn't draw right. Once again, to fix it easy enough. I simply go into the record and remove the extra characters. That restores the page draw.

The upshot of all this, is that if there hadn't been a damn COMMITTEE to work through, many problems could've and WOULD HAVE been prevented. So, now there are no more committees. WE no longer have to do that. We see a potential problem, and it gets fixed before it BECOMES a problem.

Skinning it...

2008-01-24T13:55:06Z

It is SO much easier than it used to be. Now all I gotta do is make sure all the images are there, edit the css the way I want it to look, and it's DONE.

the forum modification that wouldn't die

2008-01-24T12:24:26Z

UGH. Damn thing wouldn't go away. I finally MANUALLY removed ALL fields from my db, but was left with a menu entry in my forum. Killed it in the ACP, killed it everywhere else. Turns out that the damn function call for the menu was actually in TOPIC view of ALL places. Anyway, it's no longer there. So now I can actually SKIN the thing.

Upgrades and mods....

2008-01-12T00:42:59Z

The upgrade took a BIT longer than I wanted to. Had some weird glitches in the process, and had to have an Invisionboard tech finish it up. Once that was done, got to the adding modifications part.

So, have added several in the last ten days, all but ONE are working well. The one that did not, I uninstalled, of course. Have a couple more to do (mostly having to do with extra maintenance options) and then I start skinning the thing...

In the meantime, the SQL server is behaving in a bit of an odd manner. Seems to be running slow. So, have the site host doing tracking so we can see where it's bogging down and fine tune the thing.

Oh yeah, will finally be able to upgrade and re mod my OWN damn forum now. LOL.

BIG project on my plate

2007-12-31T22:16:49Z

The kind I like of course. =) As soon as it's all set for me to do what I need to do, I'm doing that forum upgrade. Have all the mods that need to be ported in ready to go as well.

Archive restructuring

2007-12-16T15:52:01Z

Oh yeah, making definite progress there.

These are the sections completed.

Anime sub section

Anime 2 subsection

Bleach

Final Fantasy (all)

I was right

2007-12-16T15:28:04Z

UGH. KNEW it was gonna be a booger to convert from 2.x to 3.x of phpBB. I went through contortions to get the thing done with a populated board. Took a bit over 9 hours altogether to get just the conversion of the database done. From there, there are updates you have to do in the admin panel (all for the search function), or the search engine in the forum will NOT work, as well as other things to be sure that everything actually is done, and the db came over correctly. Then of course, you have to reskin the thing after the upgrade. At least that part is easy.

Then we get to the SMF board and skinning IT. It's just downright weird. Sort of a combination of skinning a board and skinning a CMS. No big deal, I'll get it down in no time...not like I've never skinned a board more difficult (*cough* Invision *cough*) to skin. Gotta make a gdk for the thing tho, it'll certainly make things easier.

HOPEFULLY, I'll have some time off in the near future (my two days was cut to one, the other third shifter got sick) so I can actually reskin my own damn board.

Let's see....(been busy)

2007-12-15T01:49:38Z

Got called into work tonight. URRRRGH. AFTER working 56 hours, so..we'll see when my next days off are supposed to be. blech.

Upgraded my restructure forum from RC7 to 3.0 final (phpBB3)
am upgrading another forum from 2.x to 3.x of phpBB (that is going to be a booger)
installed the SMF forum for skin development purposes for it
have COMPLETED through the Final Fantasy archives for restructure.

Now, I just gotta get my ass in gear and get some housework done. Oh joy.

What the hell....figured I'd try it, was bored.

2007-12-12T20:55:45Z

What Fantasy Race Are You?

You're a Dragon!! Intelligent, graceful...and..rather big... But not always! You can change your form into human.. or elf.. though your hair will generally match the colour of what your scales are as a dragon... That's fun.. You're one of the oldest and wisest races alive....
Take this quiz!

Quizilla |
Join

| Make A Quiz | More Quizzes | Grab Code

forum stuff

2007-12-07T05:01:09Z

First, have to refresh my memory on how to skin an SMF forum for a friend of mine. It shouldn't be that bad, as I remember. Even tho it's been a couple years since I messed with one.
Learn the new ins and outs of skinning the IPB for the latest version. Gotta update my default Sea Lords forum skin so it works instead of doing that weird all in the left thing its doing in the menu bar
Continue the archive restructure setup, ALMOST done with the anime section
Start porting in the mods selected, so that I can be sure that they work as I expect.

Quite a "to do" list. Blech. 'sokay, it'll keep me ...urrrm... busy for a while won't it? LOL

Making progess!

2007-11-18T18:52:00Z

Well, thing is with a relational database program (which is what a forum/discussion board IS), one of the ways one makes it so works in a less bloated fashion, and thus more efficiently, is to do nested structures in the program.

For example, you have your main categories that display on the index page. How that's set up with it's subsequent subcategories determines how many queries are actually USED to draw that page. The less the queries used, the more effiiciently the program itself will actually run. The forum I'm working on currently is woefully out of date. However, I'm doing the legwork NOW to make it so that when we upgrade it, it takes hours instead of days or even weeks for the changes to become apparent and useful. Not to mention reorganizing a large forum can be quite a pain in the ass, as it's got to be done in a way to minimize the actual queries used per page draw.

To do this, I actually have a working test bed that's offsite from my current project location. IT has the most current version of the software installed, so I can test and set up for when the upgrade goes live.

The main page draw I've only reduced by four queries altogether. It started with 11 queries at the index, and I now have the current forum at 9. In my test forum, the query count is 7. I don't expect to be able to get it less than that. Up to 10 is actually okay, but a bit more than I like to see.

In the categories themselves, the query count is now down to five in my test bed. In the current forum, those query counts go as high as twelve per page draw, depending upon the size of the initial category. I've gotten the query count down to 5 as well for the sub forum categories, and THEIR subforums as well. All in all, a very good thing, in that the database will handle the flow of the data much more efficiently. Makes the board run faster, and less likely to have problems. Also keeps the bloating down that one finds in any relational database program. Most importantly, it's MUCH easier on the hardware framework.

Part of the problem I'm having is strictly language related. i.e. in how php 4+ parses php 3 scripts. They don't play well together at all. Hence, the unlimited subforum modification now isn't working correctly. Neither are other ported in, major modifications that are currently in that board. The newest version of the board has that written in tho, so by creating the subforums now, once I upgrade, all I have to do at that point is make sure they're all living in the right place. That's a minor adjustment and doesn't take all that long. Even WITH all the subforums that are there now. As to the other modifications, I've simply downloaded the updated versions written in php4+, so that when the board is upgraded, those modifcations that aren't actually a part of the board can be ported back in, and actually WORK the way they're supposed to. Unlike now, where they kick unexpected errors, and such things.

And finally.....the login problem from hell.....

How that was fixed was kind of an odd thing. I'd initially set the guest view option to "on", and set up a few forums where the masks allowed guest view and access. Also had edited the guest group and mask to be sure that it work. Under NORMAL circumstances, this would've worked damn near instantaneously. However, for whatever reason, there was a snippet of code placed in a global footer element, of ALL places (this would normally be elsewhere, not the footer). Why, I haven't a clue. But in the meantime, after going through 400+ html snippets that apply to how a skin draws, I finally found what I was looking for and killed it. So, now guest view is actually a viable and working option.

Coding headache....part 2

2007-11-13T03:23:43Z

I decided to quit looking through all that, and just keep prepping the forum for the upgrade. Getting as much done now and out of the way before we do it. INCLUDING testing all modifications I need to add to it.. That's something I've always done, thoroughly tested things out before I actually DID them. I've already tested just how the forum will upgrade, despite all the mods added, so it will not be an issue when the time comes. So, won't be derailed any more by trying to get that forced login killed, as the new install/upgrade will kill it anyway.

Bad news today

2007-11-10T22:08:17Z

Not much to say, other than that my friend who is boarding my mares, had to call and tell me my older mare died today. Such a very sweet natured animal, but she did live a long life.

coding headaches

2007-11-09T20:17:21Z

I've been using Invisionboard for years and years. Unfortunately, haven't messed with THIS version (1.31f) in close to three years now. Hell, my own board's been at version 2.x for a long time, and it's quite a bit different than 1.31f. Sure, it's paid licensing now, but the board software itself is far better. Faster, cleaner code, just BETTER in general.

ANYHOOOO...

In trying to kill this annoying forced login box, I've been going through html snippets one snippet at a time to find exactly WHERE the redundant function call is. Have found it and changed it in a few places, but those weren't the only places they were. Something that completely mystifies me is WHY bother hardcoding that in in the first place. It's easy enough to do from the admin panel. There's no NEED to hard code it into the skinning files. If "guest access" is enabled, simply by changing the various forum permissions, is how one determines whether a guest can actually post to a particular forum, or ANY part of the board. A simple fucking mouse click. All it takes. NORMALLY.

So, while looking through the html snippets, I get to look through the actual skinning files line by line, to see where ELSE it might be, if it's not actually showing in where I can edit the skin files in the admin panel. It IRKS me when people who really don't understand an IPB and how it works in ALL aspects, take on the task of actually messing with the code in the files. They can cause unbelievable headaches for anyone else. Not to mention the code in its original format is clean, designed to not be as much of a resource pig as this board can be, when set up / configured in a sloppy manner.

Oh yeah, then there's the thing where some may not actually take into account the actual hardware framework that this actually runs FROM. All adds up to one big mess that needs straightened out. I don't give a damn what the program is, but relational databasing is relational databasing. There are certain conventions you HAVE to follow in order for the relational program to work at it's most optimum efficiency, without it actually overloading the hardware framework as well. Doesn't MATTER what the end user's hardware is, what matters for that part is what the physical hardware is that the application runs off of.

Then of course there's the very large changes in language from php 3 to 4 and above, and the same for mySQL. It makes for some interesting and unique little weird issues. I have a fix I'm going to try to address that for this forum, which should actually correct a number of things all at one time. Interesting thing is, this particular fix has been available for close to a year. Was revised recently to incorporate up to php 5 and mySQL 5. So, this'll make the board ready to work in EITHER environment without the communication problems from one language version to another. Since this version of the board was written in php 3, these are things that have to be done just for the stability of the program overall.

Well, this is certainly a challenge for me. Which makes it fun. I just hate having to go behind and clean up / remove crap that is redundant in the first place. Aggravating at best.