gizmola

Did you mean XAMPP? I'm sure a competent and experienced PHP developer could figure out whatever issue.

You should be able to use the unique constraint in the validator. return Validator::make($data, [ 'fname' => ['required', 'string', 'max:255', 'alpha'], 'username' => ['required', 'string', 'max:255', 'alpha_num', 'unique:User,email'], etc... What this does in Laravel, is that at validation time, Laravel will query the table to test for a row that exists with the same email that the user is trying to provide for this new registration. With that said, it is never a bad idea to enforce your desired database rules in the database, as Barand advised. Assuming this is mysql, you would do this for the email column of the user table, would be to create a unique index on the email column. Given that the system will be looking up users by the email column (as the username) there should be an index on that column anyways, but in this case the index should be unique. With mysql KEY and indexes are two ways of accomplishing the exact same thing.

I am getting to this question late, and I see that people have been diligently working on it, but I do want to interject that the environment is very important here. Are you testing something locally, or even running a local app? Hopefully you are aware that the default behavior for php sessions is to set a cookie. Hopefully you are also aware that cookies are the responsibility of the client/browser to accept and once accepted, to return to the server in the HTTP header of every subsequent HTTP request. However, cookies also are relevant to a domain (and in some cases) to a subdomain. For security reasons, domains must have at least one dot in them, or browsers should not set the cookie. Because there is so much confusion regarding the use of localhost as an alias, and how it may or may not work as a domain, I never utilize it in development. I will use the .test TLD as it (along with a few others) has been designated as a TLD that will never be allowed. You are then free to odd domains and subdomains as you like, which you can put into your /etc/hosts file. I tend to use a project name, so I might set something like this up for project foo: // /etc/hosts file 127.0.0.1 localhost 255.255.255.255 broadcasthost ::1 localhost 127.0.0.1 foo.test www.foo.test You can of course have as many of these aliases as you want added to each line. There are also tools people commonly use like dnsmasq to manage a home DNS setup and can even be used on your workstation, but that's far more complication than I want to bring up. In summary, again without full context here, this could be environmental, depending on where the server is running (and if this is a local/intranet server) .

Well, yes, because array_keys will provide you all the keys in the array at the first dimension, which is probably not what you wanted. If you want access to the key in the array you can use: foreach($tokenArr as $key => $val) { } Example: $fruits = array('a' => 'apple', 'b' => 'banana', 'o' => 'orange'); foreach ($fruits as $key => $val) { echo "The $key is one $val \n"; } Output is: The a is one apple The b is one banana The o is one orange

So you want something like this: foreach ($tokenArr as $val) { //... current code // bottom of foreach loop if ($errMess !== '') { break; } }

@requinix Are you using intelephense? For me I don't get his injection in VSCode, as mouseover pops up a window that shows me the information for the function call or method.

Not sure why you would want to disable the hinting feature, which can be quite helpful in understanding what the parameters are for. However the instructions to do so are here: https://stackoverflow.com/questions/41743888/how-to-disable-parameter-name-hints-in-phpstorm

Right, well things in "web space" ie. relative to the document root, should always be referenced relatively to the document root "/" which is equivalent in webspace to the document root. This is because client browsers can only see what you make available to them in web space via url's. What this means is that things like css and javascript, or images will exist in web space. Document Root relative (web space) Assume you have a header file you want to reference in your html (even if rendered by php) at: /var/www/your_project/images/header.jpg Assume that your documentRoot for your vhost is /var/www/your_project Then your header.jpg file should be referenced relative to the document root: <img src="/images/header.jpg"> The same goes for any css or js files, or any other assets you want available via a direct url. NOTE: that you should always include the beginning "/" equivalent to "document root". This also makes sure that your code is always portable and not hard coded to a specific file system structure. File System Paths PHP commands like require_once/include/fopen etc. work with files on the file system. In other words "web space" is not relevant to PHP. PHP works with files, so it must know where the files exist. With that said, it is typical, that the way to make sure that you don't need to hard wire paths all over the place is to utilize one of the PHP magic constants, and then create a relative path to include files. The best way to do this, is to establish a base variable in a known location, and then to include that file in any script that needs to use it. This can be problematic, depending on the way you have structured your project, but the general idea is to establish this basic variable using the __DIR__ magic constant. Here is a pretty good blog post covering the functions available to implement these techniques: https://www.gavsblog.com/blog/move-up-directory-levels-relative-to-the-current-file-in-php So let's assume the path is: /var/www/your_project/config In this directory you create a script named path.php <?php $baseDir = realpath(__DIR__ . '/..'); The important thing to understand is that $baseDir will be /var/www/your_project It does not matter the location of the file that includes the path.php script, $basedir will be the filesystem path. So the only thing that is important to build off the $baseDir is to include it relative to the script that needs it. At that point you can include all other paths, so long as you know them relative to your_project. So let's say that you have a bunch of scripts in a directory named "utility" one named file.php. The real path of this would be: /var/www/your_project/utility/file.php Assume that I have a script that needs to include a function defined as "function myFile($path)". We'll also assume that you have some files stored outside the webroot that you want to deliver via PHP. One in particular will be at the actual real path of: /var/www/your_project/files/pdf/info.php Assum you have an index.php file that is in a project subdirectory: /var/www/your_project/admin/index.php <?php // your_project/admin/index.php // this gets the $basePath variable require_once('../config/path.php'); // Now we need access to utility/file.php require_once($basePath . '/utility/file.php'); $result = myFile($basePath . '/files/pdf/info.pdf'); What this all does is insure that you never have to configure or hard code paths into variables or within your scripts using relative paths where you have to. For the most part, the major frameworks use techniques like these, along with front controllers to insure that you never have to hard code a specific directory path structure into your application.

You are free to display the date however you choose. I want to go one step further with this, and explain that a date/datetime is relative to the locale setting for the server. There really is only one right option in my opinion and that is for the server to utilize UTC/GMT, so when a value gets stored it is assumed to be UTC. Most likely your hosting company has configured the mysql server to use UTC as its locale/timezone but you should probably check. What should you display to an end user? What they should see is relative to THEIR locale. Now you may very well want to hardcode this into your application if all your users are in one place (let's say they are in New York), which means that when you get date value from the database, you then need to convert it to the date/date time for the locale you want to present it to. The PHP datetime class has methods that do all of this for you nicely, and there are also some great PHP libraries out there that will do all sorts of fancy date to "some string" manipulations for you, depending on what you want. One I'm pretty familiar with, and is widely used is Carbon. At minimum you want to take a look at the PHP Datetime class and look at how to create and use datetime objects.

With modern PHP sites, you don't want your php class and source files to be in the webroot. For the most part modern websites use a "front controller" pattern where bootstrap, config and routing is done through one script (index.php). There are many reasons for this, but even if you don't have a project that uses a front controller, you still want to move any config and include directories outside of the web root for security reasons. It also makes finding the path to those scripts simpler, but I won't go into the techniques to do that. This is all (and should be hopefully) facilitated by setting up a composer.json file for each of your projects. You can set one up for code you already having by running "composer init" in the project directory, and answering a few questions (most you will just answer no) so that it generates the composer.json file for you. You can then issue other commands or hand edit the composer.json file as per your project. For all these reaons, and as many people also use composer to generate the autoloader, you put your classes under project_name/src. Hopefully you understand PHP namespaces. You can namespace inside the src directory if you want, or not. Typically this is just a decision of having a subdirectory with some name for your company/organization etc. but you can also just forgo that and creates directories for individual types of components. So for a simple symfony project you might find in project_name/src Controller/ Twig/ Doctrine/ Repository/ Kernel.php Form/ Entity/ For any classes or function libraries you write, you should put those under the src directory, either in their own directory or (as in the case of this example, for the Kernel.php script) just at the root. The organization in there is up to you. By default, initializing a composer.json file in the project directory, will configure the autoloader to load anything inside the src/ directory so that it can be referred to via the App namespace. This is via a composer.json setting like this: "autoload": { "psr-4": { "App\\": "src/" } }, Another reason for doing this, is that when using composer, component libraries are placed in a vendor directory, but beyond that there might be tests and other artifacts. If your site uses docker, even if it is just for development you want a place for project files and directories to go that is not in web space. So the defacto standard is to have a project/public directory, which is where files that should be in webspace go. Then you map your webroot to that. There are different ways to run and configure PHP today, but the important thing is that the process that needs access to the php files be able to read them. This might be apache, but it also might be a different user, if you are using php-fpm or perhaps not even using apache as the web server, as you might with nginx. This structure has been formalized and I found this helpful repo which documents the structure and the purpose of each directory. So when developing websites this is what you typically will want to use, or will see with a framework skeleton: project_name/ ├── config ├── public (web root)/ │ ├── js │ └── css ├── bin ├── docs ├── src/ (your classes here) ├── tests └── vendor (composer will create) So essentially, things in webspace go in the public directory. Anything else stays out of webspace. That should be all files that are required/included. If you have any command line utility scripts put them in bin. For deployment on linux, often there's a default mapping of /var/www for apache, and what you can then do for any project is to move/copy/git checkout the project to /var/www/project_name. You remove the default setup and for each site, you have a vhost that sets the documentRoot to be /var/www/project_name/public for each project. This standard structure works very well from local development to eventual production deployment.

Your question is not clear. Are you looking for a hosting company, or trying to do local development. Xampp has been updated to the latest PHP version. It does not use MySQL at all, but rather MariaDB. It appears that both are up to date.

What I am saying is that this might be a data problem not a code problem. It is designed to show you events in the future. If the date of the events is not in the future, those rows will not be returned. That is not an error or a bug, that is working as expected.

Css has background-size where 'cover' or possibly 'auto' should do what you want, although it will honor the original aspect ratio, which will result in some cropping if the aspect ratio differs. Usually people don't use square pictures.

Based on your github, I would agree that is the location of where things may or may not be working. <h2 class="headline headline--small-plus t-center">Upcoming Events</h2> <?php $today = date('Ymd'); $homepageEvents = new WP_Query(array( 'posts_per_page' => 2, 'post_type' => 'event', 'meta_key' => 'event_date', 'orderby' => 'meta_value_num', 'order' => 'ASC', 'meta_query' => array( array( 'key' => 'event_date', 'compare' => '>=', 'value' => $today, 'type' => 'numeric' ) ) )); while($homepageEvents->have_posts()) { So notice what is actually happening in this code. There is a comparison being done '>=' to event_date meta data. So, what this indicates, is that even if you have rows in the table, and there is a meta key by that name, the values must be in the future, or there will be no results returned. Assuming you copied all this code from some source, the data still must qualify, or the query can return an empty set, which is not an error, and would explain a blank page, since the while loop will not be entered since $homepageEvents->have_posts() will return false.

Try catch blocks should only be used for situations where exceptions are expected, and from which you can recover and proceed.

The first thing we need to know is what workstation/operating system you are using. Web Development is non-trivial. People misunderstand this because they see that HTML is easy, and then CSS and a little bit of javascript, and everything works. They get a simple PHP script up, and think "wow this is easy". Then something doesn't work the way they expected, and they can't debug or figure it out, and get completely lost, because they don't have any foundation or fundamental understanding of how the web actually works. We see it here weekly, I would guess. There are many different ways to proceed with development, as well as many different deployment platforms, and architectures that are used. So there's no easy answer on exactly what pre-requisites or plugins might be helpful to you. To add to the Web Development with PHP iceberg (and to 2nd my friends who already have replied): You need to understand a bit of Linux ssh (how to make an ssh key pair) You want to make a github account (free) You want to learn how to configure your github account with your ssh pub key I actually use Vscode for PHP development (whereas many of the experienced devs here use PHPStorm, which is the de facto industry standard IDE for PHP development). Vscode comes with html/javascript/css support built in. It also has some built in support for PHP, but it's not recommended. Instead people install the Intelephense plugin. The important thing is to look at the readme and carefully follow the instructions on disabling the php plugin that comes with Vscode. You can pay a relatively small fee to license Intelephense, and unlock some of it's more advanced features, but I wouldn't rush out to buy the license immediately, although you should keep it in mind. The one benefit of Vscode is the many plugins available, and Python support is easy enough to add.

What is System A? Oracle provides a number of Sample schemas you can use, and are often referenced by people who write about Oracle databases as in the case of the "Mentors" site that was originally based on Tom Kyte's long running "Ask Tom" Q&A series. Oracle Mentors (Ask Tom) site Oracle Sample Schemas

So... why are you using Kali Linux? It's a distro designed for pen testing. Why are you using Xampp? It's an install kit that was built for people trying to put a LAMP stack on windows, where it is (for many reasons) rarely deployed in production. Neither thing makes much sense to me, but if we just skip over those questions, Kali is based on Debian. Debian has apt. You can install the lamp stack directly using apt. "still not working" is not helpful for people. What specifically is not working? Is xdebug available (verify via phpinfo() How are you trying to configure xdebug? Where/how is the [xdebug] section being loaded, and what are the contents of that section? When you install php components from packages, these things tend to be setup for you, and changing configurations is also more sensible. Xampp is almost never used for production, which only complicates things, assuming that you are using Kali as a development workstation, for code you ultimately plan to deploy to a production environment running on linux.

That sounds really bad. 12 Copies of the same script with the same code? No, the way is not to replicate that insanity. Have one copy and require_once() that file everywhere else it is needed.

What you are asking for makes no sense. Guessing what you meant to say, is that the "charges" should be added to the withdrawal amount prior to the balance check, so that withdrawal will not be allowed. This seems like a very simple change to the logic of the withdrawal check. Since you provided no code, there is nothing more that anyone can do for you at this time.

Hi Barry, I think there's a problem with this solution: 2 and 128 are in check with each other.

It's unclear to me how navigation to the spanish/german versions work, but if there are links you can add rel="canonical" to all the links and that should fix things. With that said, this issue is covered in their localization documentation: https://developers.google.com/search/docs/specialty/international/localized-versions If you have a sitemap file, then follow the instructions for adding entries for each language. I'm guessing you don't have a sitemap, so an alternative is to add this type of block to the header of each page. This is very doable for you because you only have 6 pages. (2 pages x 3 languages). This is for example only, copied right out of the google documentation and modified slightly to be closer to what you described, but otherwise what from what I linked for you above: <head> <title>Widgets, Inc</title> <link rel="alternate" hreflang="en" href="https://example.com/index.html" /> <link rel="alternate" hreflang="de" href="https://example.com/de/index.html" /> <link rel="alternate" hreflang="es" href="https://example.com/es/index.html" /> <link rel="alternate" hreflang="x-default" href="https://www.example.com/" /> </head> So keep in mind that something similar to this section would go into the header of all the 3 index.html files. You will have a different section for the 3 tour.html files, that points to your 3 variations. Language Codes come from ISO-639-1. Country Code come from ISO 3166-1 alpha-2 Since it sounds like this might be a country specific business, you might want your hreflang codes to be: en-GB - English - Great Britain de-DE German - Germany es-ES Spanish - Spain

My first experience with OOP was ages ago, but the general idea of what objects are stayed with me, and made Oop much easier for me to understand. Certainly with PHP you are used to working with PHP's complex data structure: the array. I'm guessing you are comfortable with the idea that an array exists in program memory, and the data in the array can be manipulated. When using database api's they typically have methods that return an array with the data from the database query filled in. You are also familiar with functions. You have written functions to do various things, and are familiar with calling functions that take parameters and can return a result. An object is simply a combination of the two: the data structure which includes some combination of data types, and functions you have defined which are typically pre-wired to be able to work with the variables you set up in the class. A class is just the definition of the variables and the functions (typically called methods) that are designed to work with the class variables. A class definition is simply the blueprint for creating an object that has this binding of data and functions. Once you think about it in that way, I think it helps to demystify Oop. An object is just some data + functions (methods). It's a data structure that combines both together. The functions aren't actually copied in every object -- they exist in the code segment of the program/runtime environment, and objects basically just have a table that references the function code, but as an abstraction, you can just think of the object as being a complex variable type with functions bound into it. When dealing with functions, you have to contend with the ways variables can be passed to a function, namely pass by reference vs pass by value. With Objects, they are always passed by reference, so changing an object variable or executing a method that alters object variables will always change the object. Compare this to a function you write, where you pass in an array, change the array inside the function. For example: <?php $a = ['red', 'green']; function addBlue($a) { $a[] = 'blue'; return $a; } $b = addBlue($a); var_dump($b); var_dump($a); You should know that $a is passed by Value here, so when the function completes, the original $a array is unchanged. array(3) { [0]=> string(3) "red" [1]=> string(5) "green" [2]=> string(4) "blue" } array(2) { [0]=> string(3) "red" [1]=> string(5) "green" } In order to actually change the original $a array, you would need to declare that function addBlue's $a parameter is passed by reference: function addBlue(&$a) {...} With objects, you don't need to do this, as all objects are assumed to be passed by reference. I won't complicate this with a discussion of static variable or methods, as they add some wrinkles, but just purely as a user of a database api, this binding of variables/methods into one thing offers a lot of utility, since you don't have to keep track of all the different variables you require or produce. In general, because the objects already contain associated variables, there are less things to keep track of, and the functions designed to work with an object of that class are already a part of it. You aren't constantly having to figure out which function(s) you need to call and passing the variables that have the data you need into them. Your code tends to be simpler, and easier to maintain, even as the complexity of the application increases. Level one of Oop is just getting comfortable using classes and objects that other people provided. You don't need any sophisticated preparation or study of oop design patterns to use all the classes that are baked into libraries and extensions.

You have 2 <head> sections. You can not do that. You can't re-define a new <head> section after you have already defined it.

Good advice from both mac_gyver and Random8. Perhaps you are not clear on this, but once I understand the location of sxdisp.php I can just send data to it directly. As made clear, your password is disclosed in the javascript code. You have essentially no security. If you want something simple and static you can easily implement HTTP "realm" security, which is built into the browser and entails creating a simple password file. Usually people name it .htpasswd You would have the protected scripts in a subdirectory and add a .htaccess file for the directory along with a .htpasswd. There are many different how-to and tutorials on doing this. I just glanced over it, but here is one that covers the basics: https://www.lcn.com/support/articles/how-to-password-protect-a-folder-on-your-website-with-htaccess/