gizmola

I decided to go ahead and do a test, and this is the alternative version with getComputedStyle. function toggleResponseArea() { let el = document.getElementById("commentResponse") let responseAreaState = window.getComputedStyle(el).display; console.log(responseAreaState) if (responseAreaState == "none") { console.log("none") document.getElementById("commentResponse").style.display = 'block' } else if (responseAreaState == "block") { console.log("block") document.getElementById("commentResponse").style.display = 'none' } return false }

Here is the crux of your issue (aside from the = vs == issues). The style value from document.getElementById is unavailable until you actually use it. So in your case, your code didn't run with the if-else, because no property was ever matched. You can see the state of the styles are not initialized by adding a console.log(document.getElementById("commentResponse")) Here is a way to workaround that if you want to use it. This assumes that the style of the element is display: none as you described. Another alternative would be to set the value initially to 'none' with javascript. function toggleResponseArea() { let responseAreaState = document.getElementById("commentResponse").style.display; console.log(responseAreaState) if (responseAreaState == "none" || responseAreaState == "") { console.log("none") document.getElementById("commentResponse").style.display = 'block' } else if (responseAreaState == "block") { console.log("block") document.getElementById("commentResponse").style.display = 'none' } return false } There is an alternative javascript function: window.getComputedStyle, that you could use to get an accurate value whereas, currently you get an empty value ("")

This is a common area of confusion. Anything having to do with php and files (include/require/fopen, etc) wants file system paths. (OS Filesystem) Anything having to do with web resources (images, css, javascript) wants a url. Urls only exist in webspace. (Webspace/HTTP 2.0 Serving). As the front controller is now a popular design pattern for web apps and frameworks, you will come to find that it is frequently the case, that the only PHP script that would be under the webroot, would be the front controller script. All requests are thus, routed through the front controller, using a router. All the classes and other php scripts will be in directories that are not visible in any way from webspace. This is far superior in numerous ways, than a system that has entry points from scripts that have been mapped into webspace. I only bring this up because if you think about it for a minute, it should reinforce your understanding that PHP's functions require a filesystem path and not a url. PHP can load scripts in any directory on your file server that the PHP process has operating system level access to. Things that are not related to php code, as mentioned above, that in general are referenced in your html markup, are things in webspace. Each can be accessed via a url. Both webspace/url's and filesystems can have relative paths, so this can lead to confusion. A relative filesystem path is typically relative to the "current working directory" of the process that is running. This can easily get confusing when you are executing scripts that one or 2 levels deep in a hierarchy. For this reason, some technique which establishes the filesystem project root is helpful. That could be the document root, or as is more common these days, a variable or constant established through a bootloader or init script that references either the __FILE__ or __DIR__ magic constants. Using this technique is equivalent to, from a file system perspective, establishing something like the document root for your php code. At that point you can have simple helper functions that can concat project relative paths to it, to always have a fully qualified filesystem path. As an example, here is a simplified version of a directory path you will find using one of a number of the more popular PHP frameworks. var/ ├─ www/ │ ├─ my_website/ │ │ ├─ config/ │ │ │ ├─ init.php │ │ ├─ public/ │ │ │ ├─ css/ │ │ │ │ ├─ style.css │ │ │ ├─ images/ │ │ │ ├─ js/ │ │ │ ├─ index.php │ │ ├─ src/ │ │ │ ├─ pageA.php │ │ │ ├─ pageB.php │ │ ├─ vendor/ In this case, the webroot of the site will be mapped to the filesystem /var/www/my_website/public So the css file in markup can be referenced as: https://www.mywebsite.com/css/style.css. However, in your markup it would be completely safe and reasonable to reference it with the relative path "/css/style.css" What about file system paths for a PHP require of pageA.php? Keep in mind, that only the public directory is visible to webspace. there is no way to reach any file using a url in the src or vendor directories. Let's assume that at some point in the .../public/index.php there is code that is trying to require_once("pageA.php") You could attempt to use relative paths, based on the knowledge of where the public directory exists relative to the src directory, but this can get very convoluted once you have more complicated file system trees. It would be convenient to always use the relative path of the src script. In the case it would be simply "/src/pageA.php". A solution in index.php could be a function that always returns the path to the project directory (my_website). That would work great in index.php as a front controller, because every request goes through it, so if that variable gets initialized it can be safely used in all includes. In your case, you don't have a front controller, so this isn't as helpful. There is however, a common pattern that has been used to do this, and that is to make sure that any executing script (script that can be directly referenced in webspace) requires a config, bootstrap or setup script in the root of your project. This isn't perfect, because the filesystem path to this script will vary depending on the directory structure you have, but at worst you need a relative file system path to it. Let's assume in this example this would be .../config/init.php In init.php you have this variable defined: <?php $PROJECT_ROOT = substr(@realpath(dirname(__FILE__)),0, -1 * strlen('/config')); // The only hardwired fact here, is that the init.php script is in the /config directory. We need to strip that off the path to get back to the root. //If it was further nested from the project root, the '/config' constant would need to be changed accordingly to where it exists. //Keep in mind there would only be one of these files in the project, and typically it might also have other global configuration variables like database credentials. So long as you include the .../config/init.php script, you will be able to use the $PROJECT_ROOT, and append your relative file system paths to it to include or reference other scripts. All you need to know is the location of those scripts relative to your project (my_website). So in index.php, code like this could be used to reliably reference pageA for inclusion, simply knowing that relative to the project, it exists in the src directory. Furthermore pageA.php could reference pageB.php reliably. // In public/index.php require_once("../config/init.php"); // Sometime later, we need pageA.php require_once($PROJECT_ROOT . '/src/pageA.php'); // In pageA.php, pageA.php needs pageB.php require_once($PROJECT_ROOT . '/src/pageB.php'); Since in your case, again you don't have a front controller, you just need to make sure that any scripts that get directly executed by the web server via a url, include the "config/init.php" script in relative fashion. You probably already have a configuration script like this in your project, that everything must include, and if so, that would be a good candidate for adding the $PROJECT_ROOT to. Hope this helps. As most people are now using composer, with component libraries, and class autoloading using PSR-0 or PSR-4 standards with classes and namespaces, this already solves a lot of file inclusion problems for a project, and the more you can move your project towards an MVC pattern, the easier it will be to extend, enhance and test. If you don't understand composer, namespaces, autoloading etc., these would be excellent growth areas for you, allowing you to evolve your project towards something more sophisticated and professional.

Is "almost the same" ok? If this was meant to be a cross platform solution for encrypting/decrypting data between subsystems written in different languages, I would think that you would require "exactly the same". One thing obviously wrong with your Python is that your code snippet calls the "heylify" function, when it should have been signing = hexlify(signing) One other important thing to keep in mind is that the length of the AES key needs to match. You are using a 256 bit key in your PHP snippet, but it is not clear in your python snippet. You would need to insure that you are using a 32 byte key with your python code. If the hex version of the ciphertext is exactly the same for each function, then you have success, but if not exactly the same, then there's a mistake. The real way to test would be to take the exact same plaintext, and key, and encrypt/decrypt both in php and python. So probably you want to write your own encrypt(), decrypt() functions in both python and php. Mainly these functions will just have the code snippets you provided here, passing the plaintext and key, or the ciphertext and key for decryption.

You are asking for a guess. We need to see some code, and a reproducible example. With that said, here is some things I think would help narrow down the possibility: Check the database. Is there anything in the data for this particular tag that could break html Check your browser developer tools. Is there any strange markup? Are there javascript errors in the console relevant to this page, vs other working tag pages

The important code to look at from Barand's post: $xml = simplexml_load_string($str); foreach ($xml->xpath("//offer") as $offer) { Look at the manual page for the simplexml. Then look at the xpath function. Do you understand what it does? He is showing you a different library to load your xml file with, that has some features that the xmlreader doesn't. So you can: Convert entirely to using simplexml Keep your existing code, doing whatever it is doing, then add code that closes the xml file, and reopens it using simplexml, which will then allow you to use Barand's code

I have to agree with Requinix that PHPStorm is by far the choice of professional developers. It's an amazing editor in every way, and is the king of many other languages like Java. With that said, for web development in general, Visual Studio Code from Microsoft has really taken the web development world by storm, and with plugins is a very competitive PHP development environment. I do a lot of remote editting, and I still use Eclipse/PDT for many things, but I'm slowly making the transition to using VSC, and were it not that old habits and configurations die hard, I'd probably retire Eclipse and move to VSC 100% of the time.

Rather than a number of cron jobs, I would suggest you might want to look at the "At" command in linux. At is a lot like a cron job, however, the jobs are run once from a queue and then removed. You could have one cron job that figures out what jobs need to be queued up with At, and just track and semaphore the At jobs in your php code, using a table to track that they were queued. That allows you to keep a lot of the scheduling in your php code, possibly with some database configuration to give you flexibility.

Yes, well it looks like your header.php does a session_start() and the session has already been started. That could be because it also is trying to include the same db_inc.php. You also don't ever want to call session_start() after you have made any output, because at that point, the HTTP headers have already been sent.

In my experience this really isn't the case, again due to caching. I'm sure you know as well, that the main area of result set optimization is index coverage. One other thing to know about MySQL with InnoDB is that the data is stored as a "clustered index". In other words, the data is stored in primary key order, and whenever you read a row where it was retrieved through the use of the primary key, there is no index read cost, and you get the data for the entire row. This also perhaps helps explain the value of the result set cache, as MySQL can return data from Server memory pages, and will use a number of techniques to optimize the use of cache, rather than reading from disk. There is some overhead in parsing the queries, but it's less of a concern in MySQL than in other db's. I might not have explained this clearly, but again, in MySQL, sprocs are not pre-compiled because someone used one at some point. They get compiled for each connection, when requested. After that, the sproc will be reusable in compiled form, for the life of the connection, but as I stated previously, in a PHP application, your connections will be either frequently closed, or closed on every connection. The details of that, go into how PHP is being run, but in either case, new connections and re-compilation of sprocs will be frequent with MySQL. The more you have, the more memory will be required to store the compiled sprocs, so if you have a lot of sprocs and a lot of connections, that memory could be significant, but if this is an intranet environment where you don't have a hugh query volume or lots of concurrent requests, it's probably not reason for concern either. There is one mechanism that might be of interest in regards to the compilation of sprocs, which is to use a persistent connection: <?php $dbh = new PDO('mysql:host=localhost;dbname=test', $user, $pass, array( PDO::ATTR_PERSISTENT => true )); The PDO::ATTR_PERSISTENT => true setting will trigger, again depending on your web server configuration, a connection pool, if for example you are using php-fpm. As frequently as you can find information about it, you will also find people telling you not to use it, as it can cause issues like deadlocks, hung connections that lead to timeouts/500 errors in your application, etc, but again in an Intranet environment it might not be a problem. I have at times in my career made heavy use of sprocs, triggers and views, so I'm not predisposed not to use them, but in my substantial experience with using MySQL, it is rare that I've found they were needed. Typically, when I have used them, it was to insure some sort of programmatic locking/transaction that I wanted to be guaranteed. One example that comes to mind is an implementation of a homegrown sequence object with naming and business rules around the range boundaries of the sequence numbers. It's always good to remember things like triggers and sprocs often will cause serialization and reduce concurrency. The other thing about sprocs, is that you are only moving code around. And in the process of moving code to the db, you are adding complexity to your development environment, as you have to make your changes to the database, rather than in your frontend code, when coding/debugging. You aren't going to have less code.

We need the full code of the method where you are trying to do this. The use of a local $crop variable is odd. With that said, inside a method, that line should work fine, so there is something else missing in your question. You say they are "not the same." Where is it that you find this to be the case?

@maviyazilim: This is the best way to handle your problem. Claiming you don't understand this code, so you can't use it, is not acceptable here. Perhaps if this was in some way complicated, you might have an argument, but this is some of the most simple and basic PHP syntax that exists, and has existed in the language since it was created. This is using "Interpolation", which is one of the features that has made PHP great to work with for web development. When using double quotes, PHP will look at the contents of a string for PHP variables, and replace those variables with their values at runtime. This code is elegant, easy to read, and far superior to the alternative of concatenating a bunch of pieces together in most situations. You should try and use it whenever you can. The link is to the PHP Manual. Look for "Complex (curly) Syntax". I will explain this to you with an example. You also need to understand PHP arrays, and in particular the way that PHP arrays can have strings as a key. Simple Interpolation: <?php $testString = 'scary ghost'; echo "She saw a $testString. It was green!" . PHP_EOL; //embed newline with \n echo "She saw a $testString. It was blue!\n"; Outputs: She saw a scary ghost. It was green! She saw a scary ghost. It was blue! Again this is one of the most basic things about PHP you should know! The $testString variable gets interpolated. In the 2nd example I use "\n" for the newline instead of the PHP_EOL constant. Interpolation of array variables is also a fundamental feature of PHP: <?php $fruit = array('apple', 'banana', 'orange', 'grape'); echo "I ate one $fruit[0] for breakfast, and one $fruit[3] for lunch\n"; Outputs: I ate one apple for breakfast, and one orange for lunch Of course PHP arrays can have programmer defined string constants for keys, and this causes a parsing problem for PHP: $name = array('first' => 'George', 'last' => 'Washington'); // Syntax error echo "The first US President was $name['first'] $name['last']\n"; The problem here is that using "$name['first']" confuses PHP, when it sees the "$var['something']" and breaks the PHP string parser. So, PHP Helpfully allows you to put curly brackets around the array, telling php to resolve the value of the array, and then interpolate it as it would with any simple variable. // Interpolating an array with a string constant key $name = array('first' => 'George', 'last' => 'Washington'); // Using complex syntax echo "The first US President was {$name['first']} {$name['last']}\n"; Output: The first US President was George Washington As in Barand's example to you, this is very useful when you are trying to create html markup. This shows concatenation, which is more complicated, and harder to see minor problems you might have, vs using interpolation, where it is very clear what the markup is that you're creating, as well as the places where variables are being injected into the string. In both cases, the output is the same html: $linkData = array('url' =>'http://www.phpfreaks.com', 'name' => 'phpFreaks'); $linkConcatenate = '<a href="' . $linkData['url'] . "'>" . $linkData['name'] . '</a>' . PHP_EOL; $linkInterpolate = "<a href='{$linkData['url']}'>{$linkData['name']}</a>\n"; echo "PHP questions answered at $linkConcatenate <br>\n"; echo "PHP questions answered at $linkInterpolate <br>\n"; Output: PHP questions answered at <a href="http://www.phpfreaks.com'>phpFreaks</a> <br> PHP questions answered at <a href='http://www.phpfreaks.com'>phpFreaks</a> <br> Yet there is more: because this also works with Object variables and methods: class Person { private $name; private $age; private $title; public $summary; public function __construct($name, $title, $age) { $this->name = $name; $this->age = $age; $this->title = $title; $this->summary = $this->__tostring(); } public function __tostring() { return "Name: {$this->name}. Age: {$this->age}. Title: {$this->title}"; } public function getName() { return $this->name; } public function getAge() { return $this->age; } } $bob = new Person('Bob Smith', 'Manager', 31); $sue = new Person('Sue Jones', 'Director', 28); echo "Bob's Summary| {$bob->summary}\n"; echo "Sue's Summary| {$sue->summary}\n"; echo " <table> <tr><th>Employee</th></tr> <tr><td>$bob</td></tr> <tr><td>$sue</td></tr> </table>"; $employees[] = $bob; $employees[] = $sue; echo "\n\n\n"; foreach ($employees as $employee) { echo "{$employee->getName()} is {$employee->getAge()} years old\n"; } Outputs: Bob's Summary| Name: Bob Smith. Age: 31. Title: Manager Sue's Summary| Name: Sue Jones. Age: 28. Title: Director <table> <tr><th>Employee</th></tr> <tr><td>Name: Bob Smith. Age: 31. Title: Manager</td></tr> <tr><td>Name: Sue Jones. Age: 28. Title: Director</td></tr> </table> Bob Smith is 31 years old Sue Jones is 28 years old Interpolation is one of the best things about PHP. I hope you take the time to learn more about how it works. You can play with all the examples I provided here if you would like to experiment: https://3v4l.org/7jUPS

Route::resource is rarely what you want in the long run, as it magically routes to a lot of methods your controller may not have. With that said, start with the output of php artisan route:list What is it showing you? There are alternatives to what you are trying to do like moving the middleware to your FlightEntryController constructor. $this->middleware('auth'); // Or to except certain routes $this->middleware('auth')->except(['index']); Other standard configuration route based options differ depending on your version of Laravel, but typically involve using a route group to wrap the resource. Something like: //change routes/web.php to this Route::group(['middleware' => 'auth'], function() { Route::resource('flights', 'FlightEntryController'); });

If you don't know the specifics of how you will send email from your servers, we certainly won't. Do you run your own MTA for the domain you will be sending these emails from? If you don't, will you use a remailer system? Configurations are totally different. As Requinix helpfully isolated for you, there are configuration variables you need to set correctly. Phplist is based on phpmailer, so understanding the way variables are mapped might include referencing the phpmailer manual, although to be clear, phplist is mapping its configuration to phpmailer. Either way, you have to communicate to us how you will send outbound emails. By default, it's going to fall through to trying to use the php mail() command, which looks for a local mta on the server. Setting up an mta to actually send mail, not to mention setting it up correctly so that email actually gets delivered and not rejected outright or marked as spam is not a simple thing, and in a hosted environment, outbound email from hosted servers is often outright blocked, to prevent hosting resources from sending spam, which can get the ISP's servers and IP's on RBL lists. If you have the answers to these questions, let us know and we might be able to help you further.

There is no way to combine the queries, other than to union them, and that has essentially no significant value to you. You can write the count query in a slightly more compact manner if you like: $total_recs = $conn->query("SELECT count(*) FROM table1")->fetchColumn(); Your pagination limit variables should use bind variables: // You'll set your $limit and offset variables from your pagination calculation $res = $conn->prepare("SELECT * FROM users LIMIT ?,?"); $res->execute([$limit,$offset]); $data = $res->fetchAll();

So in a nutshell, there was some confusion or misunderstanding on your part having to do with the credentials. If there is value in this for you, and anyone else, it is this: mysql_ functions are long deprecated, and actually removed in all supported versions of php use PDO. It's a much better api than mysqli There are still mysteries to be found in this, including why you got a 2003 error while trying to connect using "ssh". Just to be clear, what was suggested wasn't clear. The suggestion was to ssh into your server, and then use the mysql command line client to attempt to connect using something like: mysql -u username -h rdbms.strato.de -p If you tried this and got a 2003 error, then there was a firewall issue either going out port 3306 or connecting to the mysql server on 3306, or perhaps even connecting from your server at all. Having a password or username rejected should have produced different errors. If these errors went away, it's very likely that they changed firewall settings to allow the connection. Using the mysql command line client uses the same underlying client libraries, so it's a good double check, not to mention a useful administration tool to have access to.

Yes, and it sounds like you have lived a varied and interesting life, despite some serious setbacks. With that said, with your background, you should be able to find remote work. I neglected to talk about my experience in the cloud. I've been interested in hosting, virtualization and "the cloud" for a long time, and have spent a lot of time learning about how to use AWS, which I employ frequently. In the last decade, Devops has become quite a career path, as it combines system administration & IT, with an understanding of SDLC and cloud services. There is substantial demand, and I suspect that it might be an area you would enjoy. You would need to learn about AWS, but there are plenty of resources to teach you about that, and you can do a good amount of learning using the AWS free tier. As for PHP, modern PHP is being done with component libraries, and typically one of the main frameworks. I consider it essentially a 2 horse race now, with people using either symfony or laravel. They are both excellent frameworks. I have more affection for symfony, and I think it has some advantages over laravel, at least in combination with an ORM. You have to gain a working understanding of PHP namespaces, standards produced by the PHP Framework Interoperability Group, composer etc. Pretty much everyone is using git, and any form of development in a team requires a working understanding of how to use git, often in conjunction with projects hosted at github. I'm sure there's more I haven't thought to add, but I often have recommended this talk from back in 2012 by Ryan Weaver, who has long been the documentation lead for the symfony project, and is the force behind https://symfonycasts.com/, which offers elearning about symfony and other related webdev topics. This point in time, was when PHP rose from the ashes to reclaim a spot at the table, as a competitive professional web development platform, and the video explains the problem PHP had, and how it was solved. Since then the PHP language has been improved and performance is the best it has ever been.

First, let me just opine that there are generally accepted reasons to create stored procedures. Those include 'performance', 'adding business logic', 'doing things that can't easily be done in a single query/ie having procedural logic', 'providing a procedural api that enforces business rules', and in the case of triggers, enforcing complex data integrity, which is often done with triggers, and can't easily or robustly done client-side. What you have to understand about MySQL, is that it doesn't work the same way that Sybase/MS-SQL Server or Oracle work. In those DB's, sprocs are cached in global server memory, so they can be shared by connections. Oracle also has heavy client connection overhead. MySQL does not work that way. Quite probably, a normal query will be faster with MySQL in many circumstances, when compared with a sproc, because you have to understand that MySQL sprocs are not available in a shared memory structure like Oracle. So performance is not one of the advantages of sprocs in MySQL. The sproc memory exists PER Connection! So that should give you pause, from a performance standpoint, because each connection will need memory allocation for sprocs, and conversely, the fact that clientA is calling a sproc, does absolutely nothing for clientB. There has been rumblings that something might be done about this architecture, but as of MySQL 8, as far as I know the per connection sproc cache is still local. So to be absolutely clear, what happens when you create a connection to MySQL, every time you use a sproc, it gets compiled (if it was not already used), and stored in memory. There is not pre-compilation performance boost you get from other databases like Oracle. Furthermore, PHP is a "shared nothing" environment. Depending on how you are running PHP, database connections will be created/destroyed frequently, or upon every execution. The fact that mysql connections are lightweight and performant is one of the reasons it has always been a good partner for PHP data persistence. This was your original concern. Most of us tried to convince you that you already are covered for those concerns by: Disallowing multiple statements in PDO Using bind variables Using InnoDB with allocation of memory to buffer pools, to maximize cache hit of result set data PHP does give you a robust and highly capable language to build your reporting tool, and your code can be safe and will be performant against mysql, and sprocs bring nothing to the table that will make that better for you. I understand that you have felt frustrated in this conversation, but this is a frequent phenomenon in the tech communities I frequent, when someone comes from a point of view that has predetermined a particular approach is the only way to do it. People immediately question whether or not, as the old adage goes, this is a "person with a hammer, who sees everything as a nail." I think this was a valuable thread that contributed to the community, and I appreciate your perseverance and patience in sticking with it, but I also hope you can see that developers who are donating their time to try and help other developers tend to get a bit irritated when they perceive that someone is telling them "just shutup and answer my question", especially when they aren't convinced that the problem to be solved has been articulated clearly. With that said, I hope you will continue to find the forum valuable to you now and in the future.

You can not change the delimiter. It is not possible because changing the delimiter is not a serverside command -- it is a clientside instruction that the mysql command line client understands. As explained and illustrated previously in this thread, you do not need to change the delimiter because that is only a problem for the mysql client, as it uses the ";" to send a query to the server. Your PDO code can include semicolons. In summary, you are wasting your time trying to run sql that changes the delimiter. As to whether or not you can run code that creates sprocs with bound parameters or values, I suspect that you can, as you certainly can bind parameters to a "CALL sproc" statement. With that said, I have never tried to do so.

Barand surprises everyone -- he is clearly a Cyborg. I am also from the generation of 300 baud dialup modems, Compuserve, AOL and the first wave of Personal computers. I have in my days programmed in Basic, Pascal & Turbo Pascal, 808x Assembler, C, C++, Paradox, DBase3/Clipper, Powerbuilder, Gupta SQL Windows, Perl with DBI/DBD, Java, Oracle PL/SQL, Bourne Shell and Bash, PHP with CakePHP, Zend framework 1, Symfony1, Silex, Symfony 2+ and Laravel and Javascript, most recently with React. Along the way, I have worked on Devops projects that involved coding with Puppet, Terraform and Ansible. I've also used various relational DB's including Sybase & Microsoft SQL Server, Oracle, MySQL/MariaDB and Postgresql, and did a good amount of work with MongoDB, and Redis. I have done a little bit of coding recently in Python and Go. I regularly work on my proficiency with css and new javascript frameworks like vue. A fun trip down memory for sure, but out of all the things I've worked on, I can remember off the top of my head, only the things I'm actively working with. I have programs I wrote years ago in c++, where just looking at the source code is like looking at hieroglyphics, and I actually wrote that code! Essentially you use it or lose it, and even though I am not as agile in moving from project to project as i once was, I try to keep learning new things, keep building code, and in essence keep myself interested and engaged in what is going on. So much has changed, just in PHP itself, all for the better, that there is a lot to pick up that's new. I also have done some mentoring of younger people, and many of them are floundering in the ocean of things a senior person knows and understands. I urge you not to worry too much about the rust you have, and just wade back into it. I have to use google and stackoverflow a lot more than I used to, but having a foundation, even if it's in your past, is a huge advantage over young people who have none of your experience. You might have forgotten things, or had things change, but those are things you can relearn or update your knowledge. The important thing to do is build and/or work on things, whatever they may be.

Wife is from Dublin -- have always enjoyed visiting. Brother in law spent a few years in Australia -- sorry we didn't visit them when they were there. Best of luck with the business idea!

I have come to the conclusion, he wants us to run his code, test it and debug it. The language barrier is also probably contributing to it. I looked at the code, which is pretty simple. It might actually work, if the database is available. Probably there is a database connection problem, and OP is just not seeing the error messages as gw1500se suggested helpfully in an earlier post, might be remedied with error_reporting and possibly turning the errors on during development.

You have described pretty much every database application that has paginated lists of data. Rarely do you see these features built with sprocs. To add briefly to requinix's comments: I believe the default mysql engine now is InnoDB. Make sure you are using the innodb engine for your tables. You want them to be InnoDB tables. InnoDB has a true data cache component, so not only will the query be cached, but the actual result set will be cached. You can configure the amount of server memory allocated to the cache. Ideally you can achieve a high percentage of cache hits in a properly resourced server, so that data is repeatedly coming from cache rather than having to be pulled from persistent storage, although with the proliferation of high performance SSD's, reading from disk is less an issue than it used to be, but is still something that you should aspire to, even if it's just extending the lifetime of your SSD's. I have nothing against sprocs, but it sounds like a lot of overkill for this project for very little gain.

One of the several advantages to using prepared queries is that you don't have to escape special characters. Since you are using mysqli_ * api: Quick example from this Mysqli guide, that is well worth reading through... # replace your php parameters in the VALUES section with '?' for each column you are inserting $sql = "INSERT INTO users (name, email, password) VALUES (?,?,?)"; # Now prepare the statement. It is ready for binding. $stmt= $conn->prepare($sql); #bind the values. The first parameter is a type for each column. 's' is for a string. 'i' is for integer. 'd' is for double/float. 'b' is for binary/blobs $stmt->bind_param("sss", $name, $email, $password); $stmt->execute(); Another thing that is beneficial is that once you bind variables, you can simply set them to new values and do another execute.

No worries, this is why the forum exists -- to help people who are working on things, and giving an honest effort, which you clearly are. Glad you are not giving up.