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.