| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Because of FeedBurner's recent move to Google, the links to it had to be fixed.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the comments table referenced users by username. However, if user ever changed their username, everything would become messed up. To fix
this, the index has been changed to the user ID. This change obviously requires maintenance:
This SQL must be run: "ALTER TABLE `comments` ADD `user_id` INT( 11 ) NOT NULL AFTER `page_id`;"
This PHP will generate some SQL that must be run:
<?php
$getusers = "SELECT DISTINCT username FROM comments WHERE is_anon = 0";
$getusers2 = mysql_query($getusers);
while ($getusers3 = mysql_fetch_array($getusers2))
{
$getuser = "SELECT * FROM phpbb_users WHERE username = \"" . $getusers3['username'] . "\"";
$getuser2 = mysql_query($getuser);
$getuser3 = mysql_fetch_array($getuser2);
echo("UPDATE comments SET user_id = " . $getuser3['user_id'] . " WHERE username = \"" . $getuser3['username'] . "\" AND is_anon = 0;<BR>");
}
$getusers = "SELECT * FROM anon_commenters";
$getusers2 = mysql_query($getusers);
while ($getusers3 = mysql_fetch_array($getusers2))
{
echo("UPDATE comments SET user_id = " . $getusers3['id'] . " WHERE username = \"" . $getusers3['username'] . "\" AND is_anon = 1;<BR>");
}
?>
This SQL must be run: "ALTER TABLE `comments` DROP `username`;"
|
| |
|
|
|
| |
There was a bug where, if an anonymous commenter used a username that was being used by an actual member, Four Island would think the anonymous
commentor was actually the member.
|
| |
|
|
|
| |
Previously, when phpBB3 was integrated, the user group 2 was mistaken as the Admin group when it was actually the Registered group, thus allowing
anyone who could log in to access the admin panel.
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Because Four Island is now usable in IE, there is no reason to turn back IE 6 users. Thusly, the jQuery library has been deleted, which also saves
bandwidth, as the file was 60K.
|
| |
|
|
|
|
| |
Previously, IE had a problem with IE 6 that made it impossible to use Four Island. The rightbar was cleared to the bottom, the posts' text were
invisible, the top-fade obscured text and The Fourm was illegiable. This has (mostly) been fixed with a conditional stylesheet. Four Island doesn't
look perfect in IE yet (and probably never will) but at least now it's usable.
|
| |
|
|
|
|
| |
For some reason, the 404 page was previously filled with terrible semantics, IE classes and it didn't look great. Now, the HTML has been improved.
The Search clause has been fixed, there was a bug with displaying the search terms. Also, the error document has been set to the 404 page so the 404
page is actually shown when a page cannot be found.
|
| |
|
|
|
|
|
| |
The whole pingback RSS error was, at the core, the fault of bad
redirection. The problem was that the redirection from the "www"
subdomain was the last priority in the file, while it should have been
the first.
|
| |
|
|
|
|
| |
As the functions defined in functions_quotes.php are only used in the
quotes.php module, there is no reason to have them located in a seperate
include file.
|
| | |
|
| |
|
|
|
| |
Ages ago, Four Island used mod_rewrite and a module called fourm.php to integrate The Fourm into the main site. However, now that task is
accomplished by The Fourm itself by including the Four Island header.php and footer.php
|
| | |
|
| |
|
|
|
|
| |
Also fixed spelling of maintenance in places where it was incorrectly spelled.
Maintenance Required: Rename "mantainenceMode" config to "maintenanceMode"
|
| |
|
|
| |
Now, changes can be remotely pushed to the central repository and updated using the Admin panel.
|
| |
|
|
|
| |
Previously, the RSS feed wouldn't display because it attempted to display parsed blog posts, but the parseText() function was not defined as parsers.php was not
included.
|
| |
|
|
|
| |
Many SQL queries were using the function addslashes() to escape their content. They have been replaced with the more secure
mysql_real_escape_string() function.
|
| |
|
|
|
|
| |
Previously, if a draft was being moved into the pending queue, it would be deleted instead. The problem turned out to be the fact that when the tag
system was changed (409d99f03471), the single instance in the admin panel of a draft being changed into a pending post was not fixed as the rest
were. The extra column in the "INSERT" query annoyed MySQL as that column no longer exists.
|
| |
|
|
|
| |
The [thumb] bbcode takes the content and creates a thumbnail of it. The thumbnail fits perfectly inside the post bubble and is wrapped with a link to
the original image.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Certain posts, when moved around, were strangely deleted from the pending queue. This was actually two seperate bugs, both causing the same problem.
1. When looking for the post to swap with, the movePending command would search for the next post with an ID greater than or less than the current
ID, but it wouldn't actually sort the results correctly so that the corrent posts wouldn't neccessarily always be the post shown. This resulted in
a seemingly random pending posts being deleted. This has been fixed by adding a simply "ORDER BY" clause to the SQL "SELECT" commands.
2. When re-inserting the pending posts into the queue (after swapping IDs), if one of the posts contained invalid characters requiring escaping,
MySQL would reject the post without error and simply not insert it, resulting in one or more of the posts involved in the switch to be deleted.
This has been fixed by wrapping the text of the post in the mysql_real_escape_string() function.
|
| |
|
|
|
| |
The admin panel's movePending was suffering the same Every Item Is Exactly One ID Away From One Another syndrome that the main blog was facing in
changeset 8c0096629f88 (Fixed blog post Next/Previous links)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The movePending command is used to re-arrange the pending queue. However, it's output had two errors:
1. If the move completed sucessfully, the pending queue would be shown again. However, the URL would still be the movePending command, with it's
parameters. Because of this, if the user refreshed, it would try to re-arrange the queue again, which could cause some strange things to happen as
the post in question had already been moved. This problem has been fixed by redirecting to the managePending command after executing the
movePending command instead of simply running the managePending command internally as used to be the problem.
2. As a collary of the preceding error, if the move failed, the error would simply back up the browser's history and refresh. If the previous page
was the output of a sucessful movePending command, strange things would happen. This was fixed dually by the previous solution and the fact that
now the error messages simply link to the managePending command.
|
| | |
|
| | |
|
| |
|
|
|
| |
I decided that, because I use the :) emoticon so often, I might as well replace it with an actual image. I've added a Smiley parsing system to
complement the BBCode parsing one.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
I don't know, a lot of stuffses happened that I don't quite remember anymore. Goodness, that's not good.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
As previously seen in the 24 Ways post, there was a strange BBCode parsing glitch caused by a few circumstances. There had to be a BBCode tag that
had a parametered definition and a non-parametered definition. Both had to appear in the same post and the parametered had to appear before the
non-parametered.
Because the Four Island BBCode parsing system parses non-parametered tags first, it finds the opening tag of the non-parametered tag first, but when
it tries to find the closing tag, because it is searching from the beginning of the tag, it finds the closing tag of the parametered tag. This causes
strange things to happen.
This has been fixed by forcing the parsing system to start searching for the closing tag after the position where the starting tag is.
|
| |
|
|
|
| |
Previously, when a post was deleted, it's adjacent posts displayed nothing for the respective Next/Previous link because there was no post with an ID
exactly one before or after it. Now, blog.php just looks for the next or previous ID, regardless of if it's actually adjacent.
|
