Jacques1

The date() function operates on Unix timestamps. Passing 66 to it means 1970-1-1 00:00:66 UTC. How this is displayed depends on the time zone. If you want an interval like 66 seconds, you need to actually create an interval and format that.

Well, you're obviously trying to access the script without a location parameter in the URL, and the script cannot handle that. You have much bigger issues, though. PHP 5.4 is long dead and doesn't even receive security updates. And the self-made encryption scheme in your code is horribly broken.

This is the script. All you have to do now is establish a database connection (the code is on the page I've pointed you to) and insert your XML stuff. That's 5 minutes of work at most. If this is too much for you, I wonder what you expected. A magical load_iptv_channel() function? There is no big “puzzle” to be solved. This is about common sense and a bit of Google fu.

If you've literally copied and pasted his code, you need to get rid of the semicolon. C'mon, this problem should be solvable with a bit of common sense.

The mysql_* functions are stonedead, and the last PHP version which still supports them is currently being phased out. There are big warnings in the PHP manual. Use PDO, make the channel title the primary key of the table and do an update whenever a title already exists $channelStmt = $databaseConnection->prepare(' INSERT INTO channels (title, url) VALUES (:title, :url) ON DUPLICATE KEY UPDATE url = VALUES(url) '); $channelStmt->execute([ 'title' => $channel->title, 'url' => $channel->url, ]);

No, no, no. Those are HTTP headers which may or may not be present in the HTTP responses of your IPTV provider. They tell you whether the XML file has been changed. If it hasn't, the script can stop immediately and doesn't have to touch the channels at all. Open the developer tools of your browser to inspect the response headers. When in doubt, use Google. This is all well-documented standard web stuff.

You can set the period to anything you want: 30 minutes, 15 minutes, 5 minutes. If the server provides a Last-Modified or ETag header, you can have a very short period, because the script won't be doing anything as long as the XML file hasn't been updated. Alternatively, the channel script could probe the URL: If the resource is down, the database is updated. However, this may not be reliable, because servers don't always send a hard 404 code for invalid URLs. Personally, I'd go with periodical scans at a reasonably high frequency so that the chance of you accessing the URL just between a change and the next update is insignificant.

“OR” is a reserved word in SQL, representing the logical “OR” operation. It's theoretically possible to use it anyway if you always(!) put it in quotes, but this is very bad style and a bad habit you need to get rid of. Don't use reserved words as identifiers, and don't clutter your queries with backticks. Whether those cryptic aliases even make sense is also questionable, because they don't exactly improve readability. If typing a few characters annoys you so much, use a proper IDE with SQL autocompletion.

What's the matter with those random subselects? Just do a union of two queries: SELECT 'customer_' || ca.key AS key, ca.data, ca.date_added FROM customer_activity AS ca UNION SELECT 'affiliate_' || aa.key, aa.data, aa.date_added FROM affiliate_activity AS aa ORDER BY date_added DESC LIMIT 0, 5 ;

Grinding through the entire XML file whenever you want to watch a channel doesn't make much sense. Surely they don't change the URLs every few minutes. A more realistic approach is to periodically scan the XML file and keep the channel URLs in a local database (MySQL, SQLite, ...). Then the channel script can simply look up the current URL and perform a redirect. This is a few lines of code and two SQL queries, which should be doable for anybody with basic technical competence.

Don't make it so complicated. $level = 1; $experiencePoints = 3 * $level ** 3;

The data can be approximated with a polynomial function, e. g. f(x) = 3x^3 with f(x) being the experience points required for level x.

Your question has been answered at least three times now. You've chosen to ignore the replies, so it's pointless to continue. I won't stop you. No doubt about that. Like I said, you're living in a bubble.

What's the whole point of the numeric “channel ID”? Just use the channel name. Sure, the percent encoding in the URL won't be very pretty, but I don't think prettiness is the issue here. If you absolutely must have numeric IDs, you'll have no choice but to create a database of channels.

You don't get it. I've just told you that your application allows anybody to upload and execute malicious PHP code, and you're worried about passwords. But even then you don't even try to implement what we've told you. Have you never heard of hashing? Sessions? Anything? No, you do not. Since your application has XSS vulnerabilities all over the place, anybody can get the password simply by injecting a script which reads that password: No, it does not. If you think I'm stupid, read the code. It takes the input and writes it to the settings script. It doesn't even mention the “letmein” parameter. I'm really starting to think that you're a hopeless case. A program which blows up when somebody enters the name “O'Neill” and which gives any random user direct access to the underlying system is not “getting the job done”. It's fundamentally broken. It violates even the most basic requirements. It's effectively malware. Forget about learning PHP. You need to understand what software even is, what it's supposed to do, what it mustn't do.

You are in fact putting the plaintext password into the client-side code: params['letmein'] = '<?php echo $dg_SecurityWord; ?>'; So anybody who manages to steal the admin session gets the password for free. But even without this trivial vulnerability, there are countless of ways how the password might be obtained: Through an SQL injection vulnerability; MySQL can import the content of files Through another script which accepts arbitrary file references and loads those files Through a misconfiguration; the only thing which makes the webserver execute .php files rather than serve them as plaintext is a single parameter, and this can break Through a timing attack; a simple character-by-character string comparison leaks information about the reference string through subtle time differences: The longer the common prefix of the two strings, the longer the comparison takes … But as it turns out, the password is not even necessary. Anybody can POST data to your save script, and you'll happily write this data to the configuration script. It's even possible to inject arbitrary PHP code. I repeat: Anybody can upload and execute arbitrary PHP code on your server. This is the worse case scenario. Trying to fix this will only reveal more vulnerabilities and defects. The core problem is that you really don't know how to program. Sure, you can produce code which seemingly “works”, but you don't understand fundamental concepts like validation, robustness, defense in depth. You've been programming in a strange bubble where appearently neither you nor anybody else cared about the quality of your work. I realize this is brutal feedback. But you have to understand that you're essentially a novice programmer starting from zero. You haven't learned much except for a few bits and pieces of syntax.

mysqli was introduced 13(!) years ago, so it's not like they add a new feature every week. If you want your code to last many decades without ever being touched, web development isn't really the right industry. The best you can probably do right now is use PDO. It's a universal database interface which covers all mainstream SQL systems, so it won't go away anytime soon.

Common sense and logical thinking have nothing to do with PHP. I'd say those are basic intellectual skills which every human should have.

This is going to make your security worse, not better, because generating entirely dynamic queries is a nontrivial task which has failed many times even in big projects. My advice is: Just don't. If you find mysqli too cumbersome, switch to PDO.

This will make all your errors go away: rm -rf /

I appreciate that you're willing to take suggestions, but let's be realistic: This is not about adding a bit of security here and there (whatever that means). It's about (re)learning fundamental aspects of programming, because the whole code is written in a very naive manner. Which is somewhat odd after 25 years of experience. I also don't see how this is useful. It's a big GUI which wants my credentials and write access to my server, and essentially all I get is a broken reinvention of prepared statements. Why not use real prepared statements then? Personally, I would write this off as an exercise. Learn PHP, do your own private projects and then publish code. This is how we've all started.

The library has no security concept whatsoever and is bordering on malware, because it systematically produces SQL injection vulnerabilities. I'm not going to assume that you've done this on purpose, but this definitely isn't ready for production. I strongly recommend you don't use this forum for marketing.

Like I said, none of us is using Vagrant.

What error? Be specific. Randomly deleting code which you don't even understand is not a good idea. If there are problems, ask the person who maintains the shop to fix them.

Hosting multiple sites means adding a few lines to the Apache configuration. It doesn't involve any deep changes in the environment. So instead of spending your time on clone initialization, just make a backup of the Apache configuration. Or even better: Put it under version control.