Adam

As MedTechie said:

I used to think the same, but over the last couple of months I've got used to Chrome's tools and there's really not much between them, except that Chrome's feel a little more stable as Dan was getting at.

1) I wouldn't replace the BBCode before you save the data. What you have in the database should be kept as close to what the user entered as possible. What will happen when you allow the user to edit their post/input? Or what if you decide to serve the data on another platform (Android / iOS)? You should parse the BBCode and convert it to HTML as it's output to a web page. 2) On top of what scootstah suggested, can you show us the code you're using to insert / display the data?

You would need to use sentences, otherwise there would be no context and it just wouldn't make sense. Paragraphs would be even better. I don't think Dan meant word quite so literally.

IE would throw an error because the function doesn't exist, which would likely break any JavaScript that follows.

Just give each text element the directional class, and at the top of your page have a very small in-line stylesheet that conditionally defines it as left to right, or right to left. Personally I would only define it if it's right to left.

Pardon?

Has anybody seen the new built-in DOM inspector that comes with FF10? Its got a fancy overlay, but functionally it's lacking a bit! When inspecting an element you can't edit text nodes at all, only existing attribute values. You can add and switch on/off the CSS rules as well, but that's about it. There's no new additional tools for tracking HTTP requests, browser resources, etc. Seems like they spent all their time on the GUI and left you still reliant on plug-ins to do everything Chrome does by default. I think Firefox will be playing catch-up with Chrome for the rest of it's days to be honest, they haven't had an original idea (that I know of anyway) in years!

Just be aware this won't work for your IE friends using <= 8. addEventListener() is not supported until IE9 (despite it being a standard since DOM level 2 was released).

As pointed out before, storing user information within a friend relationship table is a bad idea. You said there was a separate table for the user data - I guessed a couple of the column names in my SQL. What's the point in showing the status if you can't say anything about who posted it? Joining the user data would be something you would need to do at some point. s, u and f are just aliases: You could also declare them with an optional "as" if you find it easier: The parentheses are also optional - personally I just prefer them.

You'll need to modify the user table column names, as I had to guess what they're called.

You know I posted a query that will do what you want (and even join on the users table) about 12 posts ago, right?

How are you viewing the source? If it's through a tool like Firebug or Chrome's developer tools, then it probably re-formats the HTML (correctly). Why are you leaving out the quotes out of interest?

Can you post a test account?

You wouldn't hard-code the API key within the class, just declare the property (with no value). As you construct the object you would then pass it in as a parameter: $short = new shortenGoogle('sadasdfasfasfds'); The constructor method now just needs to assign the passed value to the property: public function __construct($google_api_key) { $this->google_api_key = $google_api_key; }

JavaScript can also inhibit the browsing experience though, which is why there's the option to turn it off. That said, JS should only enrich the the user's experience; if it's disabled the site should still be usable. Of course 9/10 that's probably not the case. HTML5 is actually introducing built-in browser validation, to try and tackle the problem: http://blog.mozilla.com/webdev/2011/03/14/html5-form-validation-on-sumo/ Given that IE9 and Safari don't support it at all yet though, JS solutions are going to be around for a while -- especially considering IE6 is still a major headache for those of us unlucky enough to have to support it still.

Works as expected for me? Can you provide a simple piece of mark-up that we can run to recreate the problem?

You could just keep a small stack of the pages last viewed by the user in their PHP session. If they didn't come from 'page1 > form page', then just redirect them to page1 or display an error. Even if it was impossible to disable JS in the browser settings, it's still code ran on the client's machine and is therefore not trustworthy. Anything from the client can be manipulated.

Shadow box?

Get rid of the constants. Pass in the Google API key to the constructor to store within a property, and move the end point URL constant to a class constant. You could probably centralise most of the curl functions into a separate method too, and just pass in the URL for each request. Personally though I would separate the two methods into their own classes, as they do different things.

There's a fault in your testing, I guarantee you. You say it matches status updates of all the user's friends right? How does it know who the current user is? If it doesn't know that, then there's no way of finding that user's friends, and so their status updates. All the query is doing right now is retrieving everyones status updates that has a record within 'friends'. So anyone that doesn't have a friend will see nothing, as expected. Anyone that has at least one friend, regardless of who it is, will see everyone's status updates.

I'm glad you're making progress, but you realise that will just return a list of *all* statuses? [...] WHERE friend_id=Friends.friend_id You're comparing Friends.fiend_id to Friends.friend_id there, which will always be true.

I was referring to the Friends.friend_name column; keep the relationship table, but remove this column and use a JOIN to retrieve the friend's name. The MySQL manual has a page dedicated to converting tables to InnoDB. I appreciate that, but it's worth understanding first why you should do something in a particular way, rather than just doing it. This is roughly the query you would need: select s.statuses, s.whens, u.id, u.name from Statuses s join Users u on (s.users_id = u.id) join Friends f on (u.id = f.friend.id) where f.users_id = 123 order by s.whens; Had to guess the users' table column names, and obviously couldn't run this myself to make sure it worked, but should do the trick. Replace 123 with the user's ID and add a LIMIT clause.

You don't necessarily need a defined foreign link between two tables in order to JOIN them, but it is highly encouraged to keep your tables in good shape. Personally I would get the foreign keys working before proceeding -- you'll need to use the InnoDB engine, not MyISAM. Are those all of the tables? You're missing a 'users' table. Storing the friend's name within the relationship table is very bad practise - what if they change their name later? You're going to have to do a - possibly very large - update on the table. Large updates cause a bottleneck due to table locks and will slow down your application. Instead you should use a JOIN to pull in their name from the alluded 'users' table, as you query for the data. That way you're "normalising" that piece of data, by only storing it once. Also you should store the user content in UTF-8, especially since you may have users from around the world posting statuses.