jeremyckahn / universalblogproject Goto Github PK

Some of the info on the Info page is outdated.  Some of the values are 
incorrect and should just be proofread for consistency.

Login page needs password recovery functionality from old site.

There should be an automated installer for the site.

There needs to be modal dialogue/popup manager.  

There need to be a modal that prompts the user for confirmation, and a 
modal that prompts the user for their password.

Both in JS and PHP, JSON data is parsed out incorrectly when an array is 
present and sends back useless object data.

The JSON data that is sent back to the client for post validation is 
functional, 
but it is not straightforward.  It should be re-implemented to be easier to 
understand.

When the user enters a carriage return in the post form, it doesn't show up in 
the preview and is not sent to the server.

RSS readers such as Google Reader are not linking back to the site.

The user settings page does not exist.

The style manager does not work correctly.  There are trailing spaces left 
when a class is removed, and multiples of the same class can be added to the 
same element.

The whole site is AJAX driven, so there should probably be a <noscript> tag 
to warn users of this.

Sometimes, when a field on the post form is shown as errored, clicking on it 
does not make it look like normal as it should.

The login page is very static.  It could be improved to be more user friendly.

Functionality tweaks:

1.  Automatically bring focus to the first text box on page load.
2.  Let the "enter" key act as page submit.


UI tweaks:

1.  Implement error highlighting.

Users can potentially put harmful characters in their username.

A lot of the views are using PHP short tags and should be converted to the 
non-short variety.

Limits for posting (title, blog) are hard coded.  They should be read from the 
DB and calculated dynamically.

The blog view needs some kind of output to let the user know that the blogs 
are loading.

Currently, blog posts are formatted and constructed as a giant colossal string 
and then echoed out.  They should be created in a view and then sent to the 
client.

When making a post, going into preview mode makes the footer appear funny.  
Issue found on a netbook.

Exact-size requests are causing problems, use following SQL dump to test:

-- phpMyAdmin SQL Dump
-- version 3.2.0.1
-- http://www.phpmyadmin.net
--
-- Host: localhost
-- Generation Time: Mar 25, 2010 at 02:37 AM
-- Server version: 5.1.36
-- PHP Version: 5.3.0

SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";

--
-- Database: `ubp`
--

-- --------------------------------------------------------

--
-- Table structure for table `blacklists`
--

CREATE TABLE IF NOT EXISTS `blacklists` (
  `blacklistID` int(11) NOT NULL AUTO_INCREMENT,
  `userID` int(11) NOT NULL DEFAULT '0',
  `blogID` int(11) NOT NULL DEFAULT '0',
  PRIMARY KEY (`blacklistID`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 AUTO_INCREMENT=6 ;

--
-- Dumping data for table `blacklists`
--

INSERT INTO `blacklists` (`blacklistID`, `userID`, `blogID`) VALUES
(5, 1, 1),
(2, 4, 4),
(3, 1, 7),
(4, 1, 4);

-- --------------------------------------------------------

--
-- Table structure for table `blogs`
--

CREATE TABLE IF NOT EXISTS `blogs` (
  `blogID` int(11) NOT NULL AUTO_INCREMENT,
  `title` varchar(450) COLLATE ascii_bin NOT NULL,
  `post` varchar(15000) COLLATE ascii_bin NOT NULL,
  `userID` int(11) NOT NULL DEFAULT '0',
  `blacklistCount` int(11) NOT NULL DEFAULT '0',
  `isBlacklisted` int(11) NOT NULL DEFAULT '0',
  `cannotBeBlacklisted` int(11) NOT NULL DEFAULT '0',
  `datePosted` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`blogID`)
) ENGINE=MyISAM  DEFAULT CHARSET=ascii COLLATE=ascii_bin COMMENT='This 
stores blog posts.' AUTO_INCREMENT=9 ;

--
-- Dumping data for table `blogs`
--

INSERT INTO `blogs` (`blogID`, `title`, `post`, `userID`, `blacklistCount`, 
`isBlacklisted`, `cannotBeBlacklisted`, `datePosted`) VALUES
(1, 'Yeaaaaaaah', 'WAMP+was+goofy.++I+am+not+goofy.', 1, 2, 0, 0, '2010-03-
01 23:32:40'),
(2, 'Constants.', 'Regression+testing.', 2, 0, 0, 0, '2010-03-15 
21:10:20'),
(3, 'Refactoring', 'Making+sure+everything+still+works.', 1, 0, 0, 0, 
'2010-03-16 20:28:37'),
(4, 'The+great+renaming+of+2010', 'Regression+testing...', 3, 2, 0, 0, 
'2010-03-16 20:59:34'),
(5, 'Converting+to+short+tags...', 'Not+done+yet.', 1, 0, 0, 0, '2010-03-17 
21:25:31'),
(6, 'PHP+short+tags%2C+still.', 
'Converted+the+server+to+not+accepting+them%2C+regression+testing.', 4, 0, 
0, 0, '2010-03-17 21:41:12'),
(7, 'Just+making+sure...', 
'I%27m+always+paranoid+when+I+haven%27t+committed+for+a+little+while.', 4, 
1, 0, 0, '2010-03-17 22:35:08'),
(8, 'Moved+a+function+around', 'Regression+testing%21+Whee%21', 1, 0, 0, 0, 
'2010-03-24 21:19:21');

-- --------------------------------------------------------

--
-- Table structure for table `passwordresets`
--

CREATE TABLE IF NOT EXISTS `passwordresets` (
  `passwordResetID` int(11) NOT NULL AUTO_INCREMENT,
  `generatedDate` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `userID` int(11) NOT NULL DEFAULT '0',
  `uniqueIdentifier` varchar(50) CHARACTER SET ascii COLLATE ascii_bin NOT 
NULL,
  `used` tinyint(4) NOT NULL DEFAULT '0',
  PRIMARY KEY (`passwordResetID`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 AUTO_INCREMENT=7 ;

--
-- Dumping data for table `passwordresets`
--

INSERT INTO `passwordresets` (`passwordResetID`, `generatedDate`, `userID`, 
`uniqueIdentifier`, `used`) VALUES
(1, '2010-03-16 19:54:37', 1, 'e8a70c368463ea3089c0e736086cbdf8', 0),
(2, '2010-03-16 19:54:40', 1, 'e8a70c368463ea3089c0e736086cbdf8', 0),
(3, '2010-03-16 20:01:41', 1, '8e9059933ba178b05fe7eb0d37044663', 0),
(4, '2010-03-16 20:02:36', 1, '8e9059933ba178b05fe7eb0d37044663', 0),
(5, '2010-03-16 20:03:29', 1, '8e9059933ba178b05fe7eb0d37044663', 0),
(6, '2010-03-16 20:04:01', 1, '8e9059933ba178b05fe7eb0d37044663', 0);

-- --------------------------------------------------------

--
-- Table structure for table `users`
--

CREATE TABLE IF NOT EXISTS `users` (
  `userID` int(11) NOT NULL AUTO_INCREMENT,
  `username` varchar(60) CHARACTER SET ascii COLLATE ascii_bin NOT NULL,
  `password` varchar(150) CHARACTER SET ascii COLLATE ascii_bin NOT NULL,
  `email` varchar(150) CHARACTER SET ascii COLLATE ascii_bin DEFAULT NULL,
  `timestamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `feedPageSize` int(11) NOT NULL DEFAULT '5',
  PRIMARY KEY (`userID`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 AUTO_INCREMENT=5 ;

--
-- Dumping data for table `users`
--

INSERT INTO `users` (`userID`, `username`, `password`, `email`, 
`timestamp`, `feedPageSize`) VALUES
(1, 'jerbils', '5f4dcc3b5aa765d61d8327deb882cf99', '[email protected]', 
'2010-03-01 23:32:11', 25),
(4, 'test_user', '5f4dcc3b5aa765d61d8327deb882cf99', 
'[email protected]', '2010-03-17 21:40:25', 15);

All POST data must be run through encodeURIComponent() before sent to the 
server.

The sign up page needs some UI tweaks:

- Incorrect fields should be highlighted as such.
- Error messages should be placed next to their respective fields.

The ubp object on the back end is getting bloated.  Functions that are only 
called via AJAX should be put into their own class.

The UI needs some customization to improve usability.

-  Bring focus to the first text field on page on load
-  On the last text field, "enter" should register as a page submit - on static 
pages only.

The string being created by this function is only helpful to the code inside of 
the JSON helper, therefore it should be moved to that file.

When the user tries to make a password recovery submission, there is a 
JavaScript error upon 
submit.  This indicates a JSON parsing error for data coming back to the 
server.  However, no reset 
entry is made in the DB either.

Implement Atom feed functionality from old site.

The current method of handling the blog list is kind of silly.  It should use 
standard methods and be JSON-driven.

When logging in, if the supplied password is incorrect, a flood of PHP errors 
are thrown to the client.

Any column that holds text needs to be three times what it currently is.  This 
is because the data is HTML encoded and could potentially take up that space.