Adam

The error you're seeing is only a notice, telling you that $_POST['auction_id'] does not exist. You should always ensure you check variables/array keys exist, in situations where there's a chance they might not, with isset or empty - depending on what value you're expecting.

I would strongly advise against validating the form using JS - unless of course you replicate the validation within the PHP too. The reason for this is that JavaScript is a client-side scripting language, where the user can easily disable or even modify the code to bypass the validation. You can't trust it, basically.

That's called binding events. You would pre-define the code so that when the click event is triggered on Link#1, you bind the event to Link#2: <script type="text/javascript"> window.onload = function() { var link1 = document.getElementById('link1'); // Bind the onclick event to link1 link1.onclick = function() { var link2 = document.getElementById('link2'); // Bind the onclick event to link2 link2.onclick = function() { alert('Hello'); return false; } return false; } } </script> <a id="link1" href="#link1">Link 1</a> <a id="link2" href="#link2">Link 2</a> I'm using function expressions here (the unnamed functions) as you're unlikely to re-use the code. If you did you might want to consider adding the code to a separate, named/declared function, and setting the onclick event to just call that: link1.onclick = nameOfFunctionHere; Also I added the return false statements so that the normal default action of the link is ignored. You might want to remove those though..?

This topic has been moved to PHP Coding Help. http://www.phpfreaks.com/forums/index.php?topic=333886.0

*bangs snooker cue on floor* .. well said guys. Crock of sh*t this law.. and as Neil said, it's probably going to just get forgotten about in no time. I'm just glad the large percentage of my wage deducted every month is going to a good cause...

If you sign-up for Google's web master tools you can set a custom crawl rate within Site Configuration > Settings. I'm not sure through a robots.txt file though..

That's.. a little odd. Okay let's narrow it down further; query the SQL directly on the database server: select distinct club_town from clubs WHERE club_county = 'Greater Manchester'

No, Google has absolutely no direct access to your database. Why would it want to? The data in there would be a jumbled up mess in the eyes of Google, even they would never be able to meaningfully index it -- never mind somehow guess the corresponding web-page to link it to. That leads to why semantic mark-up is so crucial in SEO. Yellow Pages will use a single page, but pass in dynamic URL parameters to tell the code behind it what content to retrieve from the database and display on the page. This means that each entry will have it's own URL, but still point to the same file. I imagine they also take it a step further, and use the Apache "mod_rewrite" module (or equivalent for Windows) to create rewrite rules so that they can structure the URIs how they please. So for example, you may request: yellowpages.com/pizza/sheffield/pizza-hut Which then the rewrite rules internally re-format into: yellowpages.com/index.php?category=pizza&location=sheffield&brand=pizza-hut The code within "index.php" would then handle retrieving and displaying the output, based upon the parameters passed in. I highly doubt Yellow Pages is this simple however, or even written in PHP, but hopefully you get the picture.

Try running the PHP scripts directly, so that you can narrow the problem down to the PHP or JS.

Nope. MySQL uses table-level locking during an insert, to prevent issues like that. Even if they both fired at the very same millisecond, only one insert would be performed at a time whilst the other waited. Afterwards you can use the mysql_insert_id function to retrieve the ID that was created.

So you want to create a new, blank incident as soon as they click create? The problem I can foresee there is that the user may leave the page, have clicked create by accident, etc. You'll end up with blank records that sooner or later you're going to have to purge. Of course, the severity of that depends upon the size of the organisation this is for, or whatever you plan to do with it. Anyway it's perfectly possible to do what you want, but you will need to insert the blank row (which means you'll need to allow null values for every column) to guarantee the user gets the incident number you display.

The auto-incremented ID is only generated as you actually insert the row, and so no two users could end up with the same ID. Edit Just be clear, you don't need to actually query the table to find the current highest ID. MySQL will automatically generate and insert the number as you insert the row. You don't even need to include it within the columns you list in the insert statement.

In your HTML-only code, you're calling the JavaScript through the href attribute of the anchor. In the PHP code you've added an actual URL within the href and moved the JavaScript call to the onclick attribute - which is actually a step in the right direction. You haven't explained very clearly what does happen, so I'm going to guess that the onclick is called, but as the default behaviour of the anchor is taken straight-after, the JavaScript doesn't effectively play the audio..? If so.. Obviously you can only have one or the other, and I'm not too sure what the purpose of that link is unless you have a non-JS based player (flash?) that you're linking to. Either way to play the audio without redirecting the user, you need to return false from the function you call. This tells the browser not to take the default action of the target element... function play_multi_sound(s) { [...] return false; } In addition to this you would need to tell the anchor's onclick attribute to return the result back to the anchor, which you would do like: Without this extra return statement the false result of the function would be lost. I'll leave it there for now, but you should really separate your JS logic from your HTML (i.e. stop calling JS functions from within HTML onclick attributes). I know they might not teach that on sites like W3Schools, but it's bad practise to mix up the layers like that and W3Schools is sh*t. It's also quite difficult to explain how to do that in certain situations without seeing how these links are being generated (the PHP behind it kind of thing).

document.getElementById() returns the DOM object for the element, not the value. You need to use the .value property to get the value, which in your code can be done like: var val = document.getElementById('profilelink').value;

JavaScript is perfectly capable of setting cookies. It's a little more complicated as you don't have setcookie, but there's JS equivalents out there.

I'm sure most of you will have heard about the new EU privacy law, set to come into effect on the 25th May. The law will require users to give consent to websites for storing cookies on their computer. What will happen with tracking software? Surely not every other page you visit you'll have pop-ups requesting to create some cookies? It's going to be a usability nightmare, or the end of accurate cookie-based tracking. I also love it how in the UK we've got the "Department for Culture, Media and Sport" in-charge of producing the guidelines, who apparently are leading the way in Europe and are quoted saying: "The advertising market is good at circumventing technology-specific laws." So the EU has collectively created this law, only for each country to find ways around it? What's the point? Who thought this was a good idea?

I mentioned about that in my first post ^^

That code IS hidden by default. As for multiple collapsible tables, that will require more work. You have a starting point now though, so have a bash and see how you can expand it. Think about re-usable code, and how you might store the individual states and link them to each table.

I forgot to mention in my last post; applying the display:none to the tbody will prevent users with JS disabled from ever seeing the table. If it's state is hidden by default, then you should use JavaScript to hide it by default, instead of CSS. That means when a user with JS disabled comes along, it's never hidden. A cookie would be more appropriate for this, since there's no PHP involved anyway. Taking into account what I said before, within the footer of your document (just before the closing body tag) add some code similar to this: <script type="text/javascript"> <!-- var tblBody = document.getElementById('myTbody'); if (!document.cookie.match(/hide_table/) || document.cookie.match(/hide_table=1/)) { tblBody.style.display = 'none'; } --> </script> That will check if the "hide_table" cookie is not set (so default being to hide it), or if it has been set to hide it; then if ture set the display to none. When you toggle the display you need to update that cookie with 1 (when you hide it) or 0 (to show it). Then on the next page the state will have been preserved.

JavaScript breaks the validation because the parser tries to interpret the code as HTML, when obviously it's not. All that's needed to get around this problem is CDATA tags: <script type="text/javascript"> // <![CDATA[ ... // ]]> </script>

I think the display:none should be applied to the tbody, not the table?

Using empty will implicitly perform an isset check, as well as checking for an empty string.

... Only in Wales.

You should always at least experiment and try things for yourself before requesting help. It's part of the learning process...