Jacques1

The second argument of render() is supposed to be an associative array so that you can access the variables by name: $twig->render('people.twig', ['test' => 'foo', 'people' => $result]); <p>{{ test }}</p> <ul> {% for person in people %} <li>{{ person.person_id }} {{ person.first_name }}</li> {% endfor %} </ul>

After 6 years, it's about time you meet Bobby Tables. And what's the matter with all those variables? Why can you not use $_POST directly? <?php // create and execute a prepared statement to prevent SQL injection attacks $registerStmt = $dbh->prepare(' UPDATE register SET fname = :fname, lname = :lname, -- ... WHERE id = :user_id '); $registerStmt->execute([ 'fname' => $_POST['fname'], 'lname' => $_POST['lname'], // ..., 'id' => $get_id, ]);

libssl is a system library from OpenSSL. Do a system-wide search for “libssl.so*” to check if there's any version present. If it isn't, install the libssl package.

Your code doesn't make any sense, and this is clearly JavaScript, not PHP. The display value can be obtained through simple division and the ceiling function: <script> var resultTests = [1, 14, 50, 51, 60, 100, 101, 105, 150, 151, 153, 200]; for (result of resultTests) { var display = Math.ceil(result / 50); console.log(result + " -> " + display); } </script>

First off: Why do you have those two tables? Unless you've omitted fields, they're structurally identical and should be a single table. As to your question: The union of the two tables will use the column names of the first table. So it behaves as if everything was stored in TABLE1 and can be used as a subselect for a MAX() query.

There's a SOAP extension. If you want somebody to write the code for you, I can move your thread to the hire-a-programmer section. Otherwise you'll have to learn the basics yourself and come back with a specific question.

How about using explicit indexes so that the names are in fact different? <input type="checkbox" name="checkTester[0]" value="Option 1"> <input type="checkbox" name="checkTester[1]" value="Option 2"> <input type="checkbox" name="checkTester[2]" value="Option 3"> The resulting PHP array won't be as “pretty”, because unchecked boxes will lead to index gaps. But that should be entirely irrelevant and can easily be fixed with array_values() if necessary.

Sure, but without concrete information, I don't think this thread will go anywhere.

You escape every variable within the template for its specific context. This usually means HTML-escaping with htmlspecialchars(), but not always. Some contexts require additional measures (e. g. the href attribute of an anchor due to the risk of JavaScript injection through javascript: and data: URLs), some contexts are inherently unsafe (like the content of a script element). Trying to skip the escaping for “safe” values is a bad idea. First off, escaping is not only about security. It's about making sure that the value won't interfere with the context. For example, the hard-coded name “O'Reilly” may be perfectly secure, but it will still blow up your application if you insert that name straight into a single-quoted SQL string. Secondly, trying to assess the risk of every single value is far too error-prone and expensive. Not only would you have to be a perfect programmer who never makes a wrong decision; you'd also have to re-evaluate the entire application on every change, because a value which used to be “safe” may now be unsafe. A far more realistic approach is to escape everything. Look at the context, choose the right escaping strategy, and then escape the value – regardless of where it happens to come from.

No, I will not download your .zip files, and, no, I will not write the code for you. Post the relevant code here, ask a coherent question and show your attempts at solving the problem. Then we can help you. Otherwise I'm not interested.

json_decode() does not force you to use objects. Pass true to the second parameter, and you get plain old associative arrays.

You're trying to call $this->prepare() within your SPOP object (whatever that may be), but it doesn't have a prepare() method. I'm sure you actually meant something like this: $this->db->prepare(...) ^^^^ or whatever the attribute with the PDO instance is called

How about an associative array?

By using your SQL queries instead of the file operations. Long pollling doesn't care if you're working with text files or an SQL database. The concept is always the same.

Do you have the cURL extension installed? There should be a package called something like "php-curl". Is the path "/usr/lib/php/20151012/" correct? Is that where your PHP 7 extensions reside?

There are plenty of professional CMS (Drupal, Joomla, WordPress, ...) which should offer similar features. Or look for open-source projects (e. g. on GitHub). In any case, I wouldn't buy random scripts from codecanyon, because a lot of the authors have no idea what they're doing.

Try setting the limit with ini_set() within the offending script. The global settings can be overriden in local ini files, .htaccess files and at runtime.

268435456 bytes are 256 MiB, not 128 MiB and not 2048 MiB. So you're obviously looking at the wrong configuration. And, yes, the webserver usually has to be restarted after configuration changes.

The code is ancient and so full of security vulnerabilities (SQL injection, cross-site scripting, ...) that it's effectively malware. I strongly recommend you take the application offline immediately and not run it anywhere except on your own PC until you have a basic understanding of PHP. Don't wait until your server actually gets attacked.

What is “LONG POOL”? If you're talking about long polling, google it, analyze the examples and then come back with a proper question. This isn't a forum where you just sit back and let others do the work.

Yes, but I'd enable it anyway and also set the character encoding: Twig environment options

Why can anyone view the templates? If you're storing them inside the document root, don't. The templates aren't meant for the end user, so there's no reason to publish them. Ideally, there shouldn't be any security issues, just like it shouldn't be a problem to publish the entire source code (without the configuration) on GitHub. But maybe there's still a piece of information somewhere which you don't want the whole world to see. Technically, you can use any extension you want, it doesn't matter. I wouldn't necessarily use ".html", because that makes it look like the file is static HTML. But ".twig" or ".tpl" are fine. I tend to use ".twig", because it's a pre-registered extension for Twig in PhpStorm.

As I already told you a month ago, SQL is not Excel. If you design your tables like spreadsheets, you'll end up with complete nonsense. You're not storing the items as rows, you're storing them as columns within a row. A row-based schema looks like this: table: items parent_id | item_id | value ----------+---------+------- 1 | 1 | true 1 | 2 | false 1 | 3 | false 2 | 1 | false 2 | 2 | true 2 | 3 | false See the difference? When you give your tables and columns meaningful names, I'm sure it will be even more obvious. To summarize: SQL isn't Excel, it's based on the relational database model and follows specific rules (look up “normalization”) Storing multiple values in a single column is wrong; keeping a long list of numbered columns is also wrong

You're way, way off. As I already told you in your previous thread, your database layout with those weird numbered columns is fundamentally flawed. You cannot build a sane application on top of this database. As you see, you cannot even select a simple value without an arcane hack and help from others. How are you going to deal with more complex tasks? And what's with the “T” value? If this is supposed to be a boolean, use the actual BOOLEAN type. Fix the database. If you don't know how, create a thread in the database section.

Technicall yes, but in practice I wouldn't recommend it. I think it's perfectly fine to omit the charset parameter if you explicitly define the default_charset instead. This is unambiguous (always assuming PHP >= 5.6). But when you rely entirely on defaults with no explicit settings anywhere, this is confusing and risky. There's always a chance that the defaults have been overriden somewhere else, be it by the package maintainers or a confused coworker/customer. An explicit setting makes sure you get what you expect. Besides that, I would always define a wrapper function for HTML-escaping and not call htmlspecialchars() directly. So the number of parameters isn't really an issue, anyway. If you have a configuration file, you could simply define your own default character set and use it in the wrapper: function html_escape($raw_value) { return htmlspecialchars($raw_value, ENT_QUOTES | ENT_SUBSTITUTE, get_config('my_default_charset')); } Personally, I'd go with that, simply because I want my application to be “self-contained” and not depend on specific ini settings.