gizmola

@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.