.josh

So a couple of things. Firstly, sure, there are more "elegant" ways of writing this if "make the shortest amount of code possible" is what you consider "elegant". However, I would argue what is more readable and flexible for yourself and other non/semi-coders in the future would be to have a lookup table of hours, Something along the lines of this (I think I got the hours of operation right, based on your condition): function checkTime() { // array of 7 elements, one for each day of the week var hoursOfOperation = [ // array of 24 elements, one for each hour of the day. // 0 value means closed, 1 value means open [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0], // sunday - closed all day! [0,0,0,0,0,0,0,0,0,1,1,1,1,1,1,1,1,1,0,0,0,0,0,0], // monday - open 9a to 5p [0,0,0,0,0,0,0,0,0,1,1,1,1,1,1,1,1,1,0,0,0,0,0,0], // tuesday - open 9a to 5p [0,0,0,0,0,0,0,0,0,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0], // wednesday - open 9a to 1p [0,0,0,0,0,0,0,0,0,1,1,1,1,1,1,1,1,1,0,0,0,0,0,0], // thursday - open 9a to 5p [0,0,0,0,0,0,0,0,0,1,1,1,1,1,1,1,1,1,0,0,0,0,0,0], // friday - open 9a to 5p [0,0,0,0,0,0,0,0,0,0,1,1,1,1,0,0,0,0,0,0,0,0,0,0] // saturday - open 10a to 1p ]; var now = new Date(); var messageDiv = document.getElementById('messageDiv'); var dayOfWeek = now.getDay(); var hour = now.getHours(); var status = hoursOfOperation[dayOfWeek][hour] ? 'open' : 'closed'; messageDiv.innerHTML='We are '+status+'!'; messageDiv.className=status; } // end checkTime See, now you can easily update a table for any hour of any day without messing with conditions. Secondly, I should point out to you that since javascript is client-side, the date/time is generated by the user's system clock locally set on their computer. Meaning, what their browser says the date/time is may not accurately reflect your actual hours of operation. Consider someone in Colorado visiting your page, vs. someone in China.. completely different timezone. So, if you want to (more) accurately reflect your actual hours of operation, you will need to include some conversion to your timezone. But even then, this is no guarantee it will be 100%, because visitors can (and often do, particularly kiddies trying to get around time/date based software restrictions ) change their time settings easy enough. Or alter your javascript. So if you really truly want the most accuracy out of all this, you should move this stuff server-side. But there is a snag to that, which is the constant check for current open/close status. Which brings me to my last point: I don't know what your actual site looks like, but is it really necessary to use setInterval to constantly check and update this? Things like setInterval come with a performance penalty, and I have a sneaking suspicion just showing an updated status on every page load will likely be just fine..

yeah well I have a feeling that's not what he really wants.

You need to restructure your code to use AJAX. Read up on how to submit an AJAX POST request and receive a response to update a div or w/e on the same page. There are a billion tutorials out there for it. Come back with specific questions about it if you get stuck.

Literally the only thing I have ever seen popup when I try to close my tab/browser or otherwise navigate from the page that I only _marginally_ consider "okay" (read: barely tolerable) is a warning about losing unsaved changes to something.

At face value, this should work for you: preg_match('~^\d+/\d+$~',$subject,$match); if ($match) { // matched, do something } but i have a sneaking suspicion you aren't telling us the whole story/requirements.

You can try adding something like this. I've seen it more or less work as a bandaid for some: $(document.ready(function() { $('.product-small .show-details').hide(); }); I don't really have an explanation why it happens though.

Here is a basic example for what you want to do, that will work for the link example you provided: <script> $(document).ready(function(){ $('a').each(function() { var onclick = $(this).attr('onclick')||''; var qs = location.search.replace('?',''); var url=onclick.match(/window\.open\('([^']+)/); if (url&&url[0]) { newUrl = url[0] + ((url[0].indexOf('?')==-1) ? '?' : '&') + qs; $(this).attr('onclick',onclick.replace(url[0],newUrl)); } var href = $(this).attr('href')||''; if (href) { href += ((href.indexOf('?')==-1) ? '?' : '&') + qs; $(this).attr('href',href); } }); }); </script> However, this is generally bad practice, as it can easily break. The better thing to do would be to move all of the onclick code to a callback function and then attach the callback function with a click event handler. That way, you can use a variable instead of hardcoded value and then update the variable instead of trying to scrape onclick like this. sidenote: your trackOutboundLink() function will never fire because of that return false; before it.

If you are absolutely, positively, 100% sure you will not ever need to actually do any queries to return data sets based off stuff within there, then it shouldn't be an issue

Just a random thought.. I don't know full context so this may or may not be something you can do, but I assume if it's a list of numbers you will split at the comma and loop anyways.. why not just simplify to ^[0-9,]+$

To directly answer your question, with regex you can use a negative character class to match anything that is not a quote. You didn't actually post your regex code, so a simple example matching relevant part: preg_match('~<span id="[^"]*">~',$content,$match); However, I agree with kicken about using a DOM parser. Depending on what exactly you are looking to grab, you can sometimes get away with parsing html with regex, but in general, regex alone cannot be used to fully and reliably parse html. Regular expressions (regex) parses regular language types (hence the name), meaning, there is an identifiable pattern to the context. HTML is a context free language, which means it is not regular. In order to reliably parse html, you need a combination of regex, loops, conditions, tokens, etc. basically, all the things that make up a DOM parser, which is exactly why we have DOM parsers.

regex engine ignores does not capture groups in zero-width assertions (e.g. your positive lookahead), so there is no performance difference between using (?:[pattern]) vs. ([pattern]) unless you want to count the unmeasurably small amount of time it takes to read (and ignore) a single colon char.

Quick glance at the doc link you provided, I would say you just need to set the name config property to document.title Example using step #3 in doc: $("button").click(function(){ $("#table2excel").table2excel({ // exclude CSS class exclude: ".noExl", name: document.title }); });

At face value the code above looks okay. If it's working without the 3rd field, my first guess is you don't have a column named "kont" in your database table (e.g. it doesn't exist, not spelled the same, etc.) or maybe it's not the right field type (e.g. you made it a date or int type and it's supposed to be text, or maybe you set it to be a certain length e.g. varchar(10) but attempting to put a 20 char value into it). Do you have error reporting turned on? Are you getting an error(s)?

What can I say, some people are just more.. adventurous.. than others.

You know how like if a question was something like "write some code to output 1 to 100" and you just put echo "1 to 100"; It's totally not what they really wanted, but technically not wrong. So maybe they say "wow, thanks for wasting our time.." or maybe they say "wow! this dude has a sense of humor, we'll hire him!". I've gotten answers like that from job candidates, and it has indeed influenced me giving them the thumbs up. For example if I could tell from their other answers that they know their shit, then I'm down for seeing answers like this. But if I can tell from their other answers they don't know wtf they are doing.. I'll probably think they really thought that's what the ask was, and I'd facepalm. As someone who is part of the hiring process for devs, I've seen candidates go both ways. Anyways, TL;DR: It wasn't meant to be a serious answer, and I prefaced it as such!