Ade

You ought to proof-read it. It contains quite a number of errors in grammar and punctuation.

I can't do that. The PHP that creates the log is not really editable by me because that's how it has been set up. The data that it contains is not solely for the purpose of banning. Besides, there's no DB. @ ElanMan. Thanks for your example. I'll try that.

Yes, it's one entry per line, but it comprises the date of entry, the IP, and the referrer, logged by PHP elsewhere. I just want to check and match the IPs from it.

What's the difference? I thought that strings were the plain text contents of arrays, like array('red','blue','green').

I can't get the "get_file_contents" function to work for me. Probably something fairly basic but I haven't used this function before. Example code below: <?php // check IP against ban list //$banlist = array('12.34.56.789'); <-- this works when uncommented $banlist = file_get_contents('/logs/ip-log.txt'); $ip = $_SERVER['REMOTE_ADDR']; foreach($banlist as $banned) if (strpos($ip, $banned) !== false) { die('Your IP address is on our ban list.'); } ?> Writing the array directly results in a match, but calling the file as a string does not, and I can't work out why. By the way: this is intended to be used because the usual .htaccess approach is not practical in this case. I would normally opt for that.

A few more suggestions for you. PHP Solutions by David Powers. It's an easily usable and practical book. Then try PHP Object-orientated Solutions by the same author. I haven't read that yet, but it was recommended to me, so I intend to. I like O'Reilly's PHP Cookbook for dipping in and grabbing solutions as I get more accustomed to it and I know (or find out) what I need to get the examples to work for me. For a more educational approach, O'Reilly's Learn PHP and MySQL is worth reading, although it's perhaps a little bit too academic in style (ie. a bit boring!). Wicked Cool PHP is probably worth having as well, later on: it's not the most thorough book, but it has some examples that I found useful.

This is not related to your query, but I could not help noticing it. You might run into problems sooner or later if you wrap block-level elements inside inline elements. Even if all appears well, it's still very poor mark up and does no good for accessibility (just listen to LIs and headings all mixed up). If you are doing it primarily for the sake of expanding the anchors, I suggest that you wrap those anchors inside the headings, use divisions instead of list items, and expand the links with jQuery (try biggerlink), a la progressive enhancement. Anchors are inline elements.

Yes, it did come across as a bit offensive. I didn't just jump into PHP without first reading books, website tutorials, and parts of the manual. But what immediately makes perfect sense to some will be a difficult concept for others. My knowledge of it has been slowly getting there over the past year, on and off when I have time for it. My specialisms are IA and UX rather than server-side. No worries, though.

@ Rallport Please elaborate on what your last comment is supposed to mean.

Oh. Did not know that... I hate PHP!

@ Jay How would I get all the post variables into an array? I haven't done that before.

Hmmmm.... OK. Tell me a bit more about this index error!

@ Nathan That looks good. Thanks. I'll try it when I can. @ webdesigner93 Well, we can agree to differ about what constitutes bloat but I definitely don't want to write out 15 isset statements per your example if I can loop through all data in one function instead and avoid too much repetition. But thanks for your input anyway: it is always appreciated.

Thanks for the reply, but I'm not going to run a function across 15 post variables separately. That's exactly the kind of code bloat that I want to avoid if at all possible. That's the point of my question, basically: anything that streamlines the process is welcome.

If I wanted to run a particular function or other bit of code, such as stripslashes used here, on all data coming in from a form before I proceed to check individual variables in the usual way, would this be a good way of doing it? function get($key, $source=$_POST) ( $item = $source[$key]; return stripslashes($item); } Is this code correct? Safe? Reliable? Or not. I have not had a chance to test it yet.

The obvious answer, and generally good advice with security, is to try to break it yourself. Your code looks OK at a glance, but I'm not a PHP expert. And however rare anything is, it is still worth covering: security flaws should be closed, just as small minorities of users should be catered for....

@ tonychang: Replace echo '<p>Your mail was successfully sent.</p>'; with: header('location: filepath of success page');

The strong and em tags are intended to reflect how the emphasised text would sound when read aloud. Text between b and i tags is not explicitly intended to be read differently: they provide visual emphasis for text that should be highlighted to visual users while not necessarily being read or heard differently. An example of that is the italic styling that is applied to titles of works, like a book title or the caption for an image of a painting. It is also used for certain technical terms, foreign idioms, taxonomic names, etc. and it can be used to highlight key words in an article to attract the reader's attention. These are more than solely presentational because they have a function that goes beyond style. The HTML 5 spec explains this in sections 4.6.15 and 4.6.16, and even though we are not yet using HTML 5 all the time, this part of the spec is worth noting. It shows why we still have b and i and why we still use them. Both types of tags carry semantic meaning and both types are valid, but for different purposes. If text needs visual emphasis but aural emphasis is not appropriate, you can use b or i; if text should have aural emphasis, use strong or em and style it to suit if a corresponding visual emphasis is needed as well (which it usually is). The semantic usage is the primary differentiator here. Just don't assume that using one type of tag over the other (or none) will help users of screen readers: it doesn't necessarily do so with every reader or with standard settings. Some developers cite the separation of presentation from structure as a reason to use span tags to create bold or italic text. But spans are semantically meaningless. Using a span to style text purely for appearance is perfectly acceptable and recommended, but using it to make bold and italicised text for my examples would be inappropriate. Turn CSS off and the visual meaning is lost. That would be little better than placing heading text in p tags.

I need to turn a div into a clickable link with jQuery, but without the usual method of fetching an href value from a pre-existing anchor element. I'm used to using that method with the following code: $(document).ready(function() { $("a.hidden").addClass("hide"); //hide link $("#div").addClass("click"); // style div $("#div").click(function () { window.location=$(this).find("a.hidden").attr("href"); return false; }); }); Now, in this instance, I have no suitable anchor to provide the necessary URL, so how can I change that code so that the relevant URL is in some way included in the JS? I assumed that this would be easy, but a web search found nothing.

I have seen the previous version of Lokash Dhokar's Lightbox - wasn't aware of version 2 - but it doesn't meet one of the requirements in the title: jQuery. Standalone would be fine, too, but this one requires Prototype and Scriptaculous, which is heavy overkill. The second suggestion, however, looks very well developed and seems to fulfil all of my requirements. Thanks for that one.

Yes, you'd think that they would respond to the Esc key, but so many don't. Responding to arrow keys (for multiple images) is even harder to find. Yes, it's obviously true that JS isn't fully accessible in all circumstances. I would pretty much refuse to use it to deliver any content that is not also available without JS (my pet peeve is JS form manipulation that fails to degrade gracefully, for example), but it doesn't harm accessibility to enhance the display of images, as long as it can cater for any and all users who can see the images and would normally access them in another way, be that clicking a link or tabbing around the page. Lastly, it can be described as necessary if the client wants it, which is the case here, so I have to reconcile their needs with my principles.

It looks like there's a gap in the jQuery "market", then... This is an important issue, too, so I can't entirely believe that no-one has ever bothered to address it.

As the sub-title suggests, I'm looking for a jQuery lightbox plugin that caters for users who cannot use a mouse and rely on keyboard input to navigate and control on screen behaviours. The lightboxes that I have tried will launch when an image anchor is tabbed to and activated by keyboard, but they all leave the user up a dead end with no way of navigating through images or closing the lightbox frame. I can't believe how often developers forget about users with limitations.

This seems to be fully sorted now. I added a header to set the content type to utf-8 (by default, the e-mails were being encoded in 8891-1) and that has preserved all special characters correctly. A simple solution, after all!

Ben, Kieran - not quite solved. I looked briefly at the various mb functions but they are not well explained in the PHP manual (like the rest of its content). As I have a lot of work on, I may have to leave this unresolved and outsource it at a later date.