Over a decade of involvement with phpFreaks, I have answered something like ten thousand questions, moderated thousands more, written a number of tutorials and spent days of my life providing system administration help. I've also personally donated a few hundred dollars over the years to help keep the site running. I'm just one of many volunteers who have done as much or more.
Many people don't understand that the people who make this place run are all volunteers who do what we do for the love of the PHP language, web development and open source ecosystem, and this is a way we can give back in our own small way.
With that said, for the first time in my many years here, I have a personal request.
My son plays Ice Hockey at our local rink in Burbank California. There aren't many rinks in this area, and Pickwick is one of the older rinks, having been built in the 1950's.
We love the sport, and the rink, but it has seen better days. The compression system doesn't work very well, the boards need repairs, and the facilities in general are not in great shape.
Kraft has a Hockeyville contest that is providing money to community hockey rinks for maintenance and upgrades, and Pickwick is a finalist. We are now looking to advance to the semi finals.
If this community has helped you, I'm asking that you simply go to this site and vote for our rink "Pickwick". You do have to register (Facebook makes it easy) or you can text. You have to be a US resident to do this.
You can call, text or use the website, and can vote up to 50x via each method.
If you've ever felt an interest in thanking me, or the folks who keep the site humming, here's a way you can do so that will only cost a few minutes of your time and nothing more.
You literally have to do this TODAY Tuesday April 13th EST. Voting is open as we speak!
Hopefully your system has that occur in a shared class, function or included file where you can make the change and have it seen throughout the scripts.
You might already have surmised that sessions depend on cookies, and this is really a mechanism of how cookies work and the built in protections.
You can do some investigation in advance of trying this, by looking at your cookies and seeing what the specific cookie(s) are that are being pushed from your server to determine if this might be the problem or not.
Great. Also just a tip, Print and echo are the same function. Most people use echo, because it's shorter.
Printf came over from the 'C' language and uses formatting placeholders and parameters. There are some cases when you want to control things like the exact format of a number where printf can be attractive, although there are often a number of different ways to accomplish the same thing in php, and for the most part it's personal preference.
MySQL is an odd database because it has pluggable engines that can work entirely differently. MyISAM is the base engine and of course InnoDB was a pluggable engine that became very popular.
Just about all DB's have some form of caching for queries. In the case of MyISAM this extends to the parsing of the queries themselves but not the actual data. With the buffer_pool in innodb -- the actual data retrieved is cached. So, in terms of what you were asking, when you do a LIKE '%...' query, the table will have to be scanned starting at row 1 and continuing to the last row in order to return a result. With Innodb and a large enough buffer pool, essentially the data will already be in memory and the tablescan process will be much faster than it would be reading the data from disk.
Unfortunately, with shared hosting, you are not in control of those parameters as you're sharing a mysql server your hosting company provides, either on your server or some secondary server they host.
In the shared host scenario, I would advise you to implement Barand's suggestion.
There are other reasons to utilize innodb besides the ones mentioned. I highly recommend you stay with it.
You could use Barand's suggestion -- have a denormalized search table, where you simply replicate the values into a small myisam table for the benefit of the search. The coding and interruption required would be minimal. You'd simply need to write the replication script and schedule it in cron.
To your original question one of the benefits of innodb is that it has a true data cache. It's called the "buffer pool". If you have sufficient resources on your server, you could increase the size of the buffer pool to insure that data is coming from cache. It is often possible with a small fairly stable database like the one you describe where you are almost entirely "READ/SELECT" based, to have a pool where the data and indexes for the entire table will be in the buffer pool.
At that point a SELECT '%...' will be far less disruptive than normally because it will be coming from memory. An 8-10k row table is tiny in the database world.
You would have to invest some time trying to figure out the size of your overall database and the tables in particular, and you'd need to understand your overall memory usage to determine if you could allocate more RAM to mysql that you currently do.
The innodb_buffer_pool_size and innodb_buffer_pool_instances are the only params you really need to understand and possibly change. Whatever you do, these are good params to understand. Although it might be a stretch if you are a novice sysadmin, the free tool, innotop is fantastic for making it easy to monitor the effectiveness of your caching and figuring out your cache hit ratio. I would think based on your description that you should be aiming for close to 100% cache hit with your innodb tables.
I don't want to sound like a wet blanket, especially since this isn't actually addressing your question, but at this point we really have to insist that EVERYONE needs to convert their mysql_ code to either mysqli_ or PDO/Mysql. The entire mysql_ library is deprecated and will be removed entirely from php in the near future.
There is no point in us helping you debug code that is already obsolete when you write it. You should be using either mysqli or PDO, and with bind variables it is a game changer in terms of escaping (you don't need to) and the elimination of SQL injection exploits.
Also FWIW, I don't see anyplace where you are doing a SQL INSERT or implementing a form, so I'm not sure what you mean by "nothing added".
As an alternative, let me suggest investigating a few vagrants. Pretty much any lamp or nginx based distro of your choosing could be located, or there are some pre-packaged vagrants you could try, that popped up in google:
Vagrant is a great way to develop without having to mess with your host OS. The only issue I have had in the past is that sometimes composer can be hinkey under virtual box, but I'd still recommend looking into it.
People advised you that all you really needed to do was provide a string that contained a comma separated list ("email1, email2").
What you should have done:
// send one email to both recipient and sender.
mail($email_to . ',' . $email_from, $email_subject, $email_message, $headers);
Of course the best way to do this would probably be to send yourself a bcc: copy instead.
I also don't know if you understand this or not, but this form is basically an open door allowing anyone to spam anyone else using your site as the spam delivery mechanism. Writing a bot to take a database of people would be trivial. This is just an open invitation to getting yourself exploited for spam delivery, but something tells me your email may already be seen as spam only you just haven't figured that out yet. Sending email programmatically from a server requires quite a bit of knowledge about DNS, MTA's, SPF, DKIM and other things you probably aren't aware of.
You might also look at breaking up a lot of the logic sections into functions, named appropriately to represent the specific purpose they fulfill. That way if you decide to move things around or add or remove sections, it will be much easier for someone to understand the code and make changes.