Adam

I'll be honest, I don't think even your managers know what they're doing. The Javascript on that site is all over the place. Also the supporting website of the plugin used for the carousel seems to have shut down. Perhaps it's time to upgrade to a new one? We're not here to fix old, unsupported plug-ins, even if you had shown the code.

The lack of contrast between the text colour and the background colour makes my eyes strain. Also, have you modified a theme? Looking at the CSS you have a load of neatly, commented styles... Then at the bottom it just turns to .style1, .style2, etc. With all the properties on one line.

That's what version control and code reviews were invented for.

@KevinM1 @Jessica You've never been asked to complete a test to demonstrate your abilities? Of course people ask for that kind of thing. I've done several. For my current job I was given two hours to implement an MVC-esque application, with bonus points for unit tests. Since I started I also re-took their new test as a benchmark (of amazing of course), which was more about creating a RESTful API, again with bonus points for things like unit tests. Done several others in the past, one which had a three day delivery time. People ask for demonstrations of ability. Anybody can say "oh yeah I did that", or have their own little niche of ability in which they're comfortable, but asked to create something to spec and they could nose dive. It's about testing someone. @stacanovist What were the exact instructions given to you? Do you have an email or anything you can post? Also I think Gizmola gave you some decent advice, though to add, after looking at your code it is a little amateur if I'm honest. Looking at the login.php file in www/form_process for example, where does $admin come from? You're using POST vars before checking they're set. In process_employee.php there's just this huge jumble of code, that looks more complex than just doing it with vanilla PHP. Again you're also using some mystery var $db. There doesn't seem to be any kind of library or recognisable structure, things are just stuck all over the place. Your Database class is in the models dir. The models use super globals like $_SESSION and seem bizarelly indented. Your bootstrap file just instantiates everything, what happens when there's hundreds of classes? It's completely unscalable. Even some of the simple things like a DOCTYPE in the layout view are missing, and you've included jQuery just for one simple selector. A lot of this can be forgiven if you were under a time constraint, but you haven't mentioned one as of yet. I'm not ruling out this was a genuine test and they just weren't happy, but not giving you any kind of feedback is pretty disrespectful.

Don't know who's into this kind of thing.. but should be an entertaining watch! http://www.redbullstratos.com/live/

I see what you mean. The problem is you're using the var countsign to determine whether to show or hide the login form onclick, but you're not resetting that when the menu is hidden by clicking elsewhere in the document.

You should be using proper web fonts, TrueType fonts are not built for web browsers.

Just as an FYI, this form of browser matching is completely useless. You're able to detect an IE user with is_explorer for example, but how do you do know if they're using IE5 or IE10? The only thing those two browsers have in common is the name "Internet Explorer", branding them the same browser is going to cause you headaches later on. You should take a look into feature detection.

Which would make life hell if, like me, you do quite a bit of work on trains or places where you don't have an internet connection, or just don't have access to the network. SVN does not support rebasing or cherry-picking either, at least not natively or properly. My apologies, I wasn't sure if I was right there. Perhaps it's CVS that I was thinking of. Given it can't rebase or cherry-pick though, there must be some debilitating feature to it's storage engine that prevents it. That's why I assumed. +1

Okay, but it's been a while since I used SVN, tell me if I get anything wrong (anyone). So first SVN is a repository of revisions held on a central server, that the developers pull from and push to. The developer only has a working copy of the code, and uses the server's repository to update, commit and stuff. Git is also held on a central server, but each developer has a local copy of the repository as well, and whenever you do a fetch it syncs your local copy. That means you can work offline while making commits, checking out different commits, merging, etc. And be pretty much up to date with the server most of the time. That might sound trivial, but I tend to do a lot of work on the train, which would be a nightmare with SVN. Not to mention a local copy is always going to be much faster than transferring stuff across the network. For me though one of the main benefits to using Git is the way it tracks changes. Instead of storing incremental changes of whole files, which I believe SVN does, it only tracks what's changed in the files; kind of like a diff between the old and the new, if you're familiar with bash commands. That means the repository is significantly lighter, routine use is much faster, and you can apply these diffs wherever you want. There's no linear revision number it's just a bunch of changes you can stick anywhere -- so long as Git can resolve the change that is, otherwise you'll have to resolve it manually. (Generally though unless two developers have modified the same bit of code or you're trying to cherry-pick a commit into the stone age where the code didn't exist before, Git does a pretty good job.) That storage mechanism though also enables you to cleanly rebase your working branch onto your master/base branch; essentially taking all yours commits on the working branch and reapplying them to the top of the base branch, but back onto your working branch. If that makes sense? During development it's much nicer to have your commit history clean and only relevant to what you're doing, not having a merge stuck in the middle that pulls in everybody else's changes. You can't rebase with SVN, given the way it stores changes as whole files. Both SVN and Git have the concept of "branches" that I've mentioned a few times. Both have a completely different meaning though. SVN branches are basically forks in the code base that generally don't meet again, but subsequent revisions are/can be applied across them all to keep each fork up to date. Git branches on the other hand are just a set of commits "branching" off from the base branch during the development process, that are merged back in later. You can checkout different branches whenever, merge branches together, do anything you want. Everything in Git just boils down to small, flexible changes (commits) that build up a code base. That's it's power. I don't know if I'm babbling or making sense here now, but hopefully it's helped!

SVN? You need to try Git.

You already said the answer: a web service. Just implement it on the remote server so that each of the local servers can POST data over HTTP, and the remote server will handle the ODBC connection.

From my experience, agencies try to use web terminology but show they have no idea what its real meaning is by saying things like "the PHP is essential" in the advert. I think if you try to match every possible wording they will come up with you'll be at it forever. I think you should search for smaller, simple string matches like "zend" and "symfony" that translate into tags like "zend-framework" and "symfony2". Plus if you over complicate them you're going to end up with multiple different versions of the same tag, which I think kind of defeats the point in tagging together content?

Works fine for me in FF and I'm still on v13: http://jsfiddle.net/Btr8f/

The only problem I can think of with the approach mentioned by spdierwell, is people not actually noticing or taking the time to read the notification on the first view of the dashboard. It seems to me like a lot of the notifications would go unread? Perhaps a better approach would be to have a many-to-many table (called `unread_notifications` let's say) that stores the user's ID along with a notification ID. When the user logs in, check their last login timestamp and insert any notification IDs published since that point and within a valid time range or limit, into `unread_notifications` for that user. When the user clicks "I've read them all", or individually marks them as read, you just delete from `unread_notifications`. You can set an expiry date, or infer the expiry date from the publish date, to clean up any old notifications that aren't relevant any more. Edit: This way you're only inserting a limited number of notifications into the table, you're only doing that for active users, and you're clearing up after yourself to ensure the table doesn't bloat out of proportion. The action to mark them as solved doesn't need to be done with AJAX, just make it a link to start with that redirects back to the dashboard. You can then add in the AJAX request afterwards.

Yes fair enough, but what you're recommending here is the release process equivalent of recommending IE6 as a browser -- it's outdated. Version control was invented for a reason. Relying on the person doing the release to make a back-up is always subject to human error, and adds complexity and time. I only make a point of saying this for the benefit of the OP, I'm not just trying to call BS.

No, most don't. Version control allows you to create a build of the code from any point in history. Why would you bother backing up all the files every time you roll something out when you could revert the changes even easier/faster? Database changes are subjective. Sometimes you can write a migration that can easily be reversed and is of little impact, which in those cases a database back-up isn't necessarily needed. If you make any significant changes though, or changes that can't be reversed, then yes definitely create a back-up of the data. Edit: Back-up of the relevant data, that is.

You use version control, that's what most companies and people do. Under no circumstances should you be testing or making changes directly to a live production environment. The production box(es) are generally only configured to report higher level errors anyway, so debugging wouldn't even be practical there. Ideally you want 3 environments; production, local for development/debugging, and then staging that replicates production so you can give things a test run in a like-for-like environment (as close to as possible) before promoting live. Of course the odd code issue can slip through that doesn't occur locally or on staging, which is when you may have to jump on the production box and figure out what's going wrong, but they should be edge cases. For some scripts I would be inclined to agree with you there, but for login/registration, that's a key area malicious users will try to exploit. Better to use a trusted pre-written solution than to figure out security holes after someone's exposed them, or before you've got around to patching them.

SSL encryption can be used to prevent people observing the response and request, while sensitive data is sent backwards and forwards. However that doesn't stop malicious users faking a request to gain that data anyway. There's no point trying to hide the user's ID, they're generic. You know that if you're user 123, you know at least 122 other IDs. Malicious users could simply swap the ID sent in their own request and would receive another user's details. The server should validate the user before returning anything, that's how to secure it. Just to also add about the URLs, it's easy to strip extensions with a simple RewriteRule. In the future that allows you to change the back-end implementation without having to change the web service end-points.

Not sure why but your website triggered the WebSense filter here at work, I can't access it. Reason WebSense gave: "Potentially Damaging Content".

1) Does the server verify the user based on their session before returning their preferences? If not, that's not secure. You won't secure it by trying to pass the ID differently or encrypting it though. Given the client-side code would need to know the encryption algorithm, and be capable of doing it, the attacker can just work out how it's done and then they can mock the request still. 2) Web services don't always map to a specific file. Quite often the request URI is parsed and routed within a framework to some form of controller. There's not really anything to gain security-wise by hiding the file extension, except letting the user know the site is PHP-based. An attacker can work that out in various other ways though. Generally extensions are only hidden to make the URLs look cleaner, which with web services aesthetics can be important.

Varies on the server configuration. Generally shared web hosts will have a "logs" directory in the root directory you have access to. If you have a dedicated or virtual dedicated server though, then the default location for the logs varies per the OS.

How are we supposed to know that? Code does what you tell it, and without knowing what you're trying to do or what any of those functions do or return, we can't help you.

Use error_log(var_dump(ini_get('display_errors'))). That will tell you the exact type of data it is in English. I suspect it's boolean 0 and just not showing up in the logs as a result. It's not uncommon for shared hosts to prevent you changing the ini settings, which would explain why ini_set() had no impact. Was tired last night so can't believe I didn't think about this, but given you're dumping to the logs you should be able to see the errors there..? Unfortunately though as this is written by someone else, you should probably contact them for support. We don't generally provide bug fixes for scripts you've just downloaded.

Does it actually return an empty string, or is that you're passing 0 (and so treated as false) to your logging function? var_dump is the best way to determine the correct type. Are you getting the error on a shared host?