gizmola

Are you familiar with database design and normalization? Do you have a schema diagram or structure of the tables? The main thing I can glean from your question is that you probably have a truck table, and that this is either some information where there is a 1-1 relationship between that information and a truck OR it is information that is related to a truck that is good for a period of time (ie. it could be current information with an end date, such that there would be a historic record of this information, but you also want to be able to locate and provide the current data for a particular truck, ignoring information that is now essentially expired. Really in order to design or alter a database schema appropriately, the requirements need to be clear and well understood to make the proper enhancements.

It is a great idea to read the PHP Manual page on session handling. There are many things you can configure about them, but to elaborate on kicken's answer here are a few things about Sessions that might help you understand them better. A session has to be started with session_start() prior to you doing anything else that might cause browser output from the server to the client. I'll explain why in a second. A session is entirely a server-side concept. Changes that happen to the $_SESSION variable can only been accessible to your client when a request (GET/POST, etc) is made. By default, a session has associated serialized data in it that mirrors the contents of the $_SESSION superglobal variable. So in your serverside php script, whatever changes are made to $_SESSION are immediately also saved/serialized, allowing you to restore them into the memory for another PHP script. So the obvious question is: how does PHP figure out whether a session is associated with a particular client/browser. This is done via a session id. The typical way the id is passed to PHP is via a cookie. Keep in mind that the way browsers handle cookies is that, for a domain, if a browser has a cookie for that domain, it will pass all the contents of the cookie data to the server for every request. Also keep in mind, that the server can set cookies by including in a response header, the cookie data. This explains why session_start() must occur before any output is sent. session_start() determines if there is already a session that exists by reading the cookie data and seeing if it can find a matching session id, OR it will create a new session, assign a unique session id, and add the http header to set the cookie. As soon as a response is sent, the client/browser will set the cookie, so that in requests that follow, PHP scripts can read the stored session data into the $_SESSION variable for use in your scripts. Hope this helps with your understanding.

Yes there is, it's called the "global even scheduler". Given the inherent limitations of a scheduler that runs within the rdbms, I haven't found it to be a highly used feature. It also has to be turned on by a user with root level access, I believe. You create events using a CREATE EVENT statement. They can be scheduled to run once, or to be recurring at a certain interval.

The 2 languages have their own ecosystems. Either one is a good choice for web development. For fortune 500/corporate systems who tend to prefer support contracts and microsoft based infrastructure, there tends to be a wider use of .NET/c#. As PHP is Free Open Source software (FOSS), it has a wider adoption in the SAS/startup space, paired with one of the open source rdbms (postgresql/mysql) or Document databases, whereas, typically you see .NET run on microsoft server infrastructure and MS Sql server. It also has a healthy amount of competition from Nodejs/MEAN stack. One unusual feature of the PHP development space is the variety and high quality of MVC frameworks, with the two primary competitors of Symfony and Laravel that are both supported by large active developer communities. It really depends on what type of system you are trying to develop, and the target market or customer for the system. Coming from c# you should be able to pick up PHP quickly, but you want to get familiar with composer and either of the 2 frameworks I mentioned, if you really want to get a feel for what professional developers do with the language and platform. One other thing to note, is that as PHP is typically deployed on linux servers, now more and more in containers, you really want a good working knowledge of Linux, and this is something that .NET developers sometimes don't have.

Try using chrome dev tools and looking at any errors being generated. You are asking us to guess, and that's not the way to figure a problem like this out.

I removed the apikeys from your message. Keep in mind this is a public forum, spidered by google. Even if those are development keys, you don't want to publish them to the world.

How are we supposed to help you when you haven't provided any information at all about the chat server/system you installed?

I haven't seen a lot of your code, but the other thing that jumps out is that having functions where you are passing 4-5 parameters indicates that you probably have blocks of code that are trying to do too many things, and are not discrete enough. I certainly could look back at code I wrote in the past and admit I did the same thing on many occasions. This leads to the type of problems you are concerned about: large code base, concerns over side effects if you make a change, cascading throughout the code, lack of DRYness etc. This tends to happen when you build everything from scratch, as your code evolves into a thing "that works for what I have" rather than something designed from the outset to be clean and maintainable, and unit testable. While you can't go back and change large swaths of the system now, you certainly can improve it incrementally by writing smaller more discrete functions for anything new or currently undergoing modification, and refactoring whenever possible. Sometimes a small improvement can be game changing in terms of system quality and maintainability. Write functions that do one thing, and always return a result of the same type. Most functions should have a handful of parameters. If there are more than a few essential parameters, look at ways to break the function into smaller more discrete functions/pieces that you can use to assemble your results Obviously having functions with 1000's of lines of code is hard to work with. Most editors have ways to open multiple windows and add bookmarks in your code, when you have to move from one to another. Some of the fancier IDE's also let you jump back and forth in your code, by creating linkages from the files where classes and functions were defined that the editor can then use to open the appropriate file when needed, akin to clicking on a hyperlink. PHPStorm has that type of function, and can really help when navigating a large codebase.

We don't have enough of your code to look at but to be clear -- when passing by value, you can update the array inside the function. You can echo out values, make assignments etc. and everything will look fine. Any of those changes will be discarded once the function exits, however, as inside the function you are working with a copy of the original variable as it was when the function was invoked. If this is not the issue, then we need to see some actual code, to help further, as anything at this point is simply an educated guess.

Defining a function with optional parameters is done the way you did it. <?php function foo($bar, $fruit=null, $candy=null) { echo "bar: $bar" . PHP_EOL; echo "fruit: $fruit" . PHP_EOL; echo "candy: $candy" . PHP_EOL; } foo('one bar'); foo('one bar', 'apple'); foo('one bar', null, 'snickers'); With basic functions, all parameters are passed by value, not pass by reference. $error = array('message' => ''); function testparams($msg, $error) { $error['message'] = $msg; } testparams('BAD SYSTEM', $error); // Original error array was not changed, because it was copied internal to the function echo "Error: {$error['message']}" . PHP_EOL; To get around this, you can tell PHP that the $error array should be passed by reference, and change the original array variable. $error = array('message' => ''); function testparams($msg, &$error) { $error['message'] = $msg; } testparams('BAD SYSTEM', $error); echo "Error: {$error['message']}" . PHP_EOL; // Result is Error: BAD SYSTEM

Think of it this way: Array1 (I'll call 'titles') is the destination array. It is static as defined, and you will update it based on the contents of Array2 (which I'll call 'images'). You do not need nested foreach statements here, only a foreach through the images array. // Get the person_id $person_id = $titles['person_id']; //Loop through images $index = 1; foreach ($images as $image) { $titles[$index]['person_id'] = $person_id; $titles[$index]['name'] = $image['name']; $index++; } This code is susceptible to issues with the structures you provided. Here is some testable code: $titles = array( 'person_id' => 3, 1 => Array ( 'title' => 'qwerqwer', 'medium' => 'dfsadfasda' ), 2 => Array ( 'title' => 'sadfasdfad', 'medium' => 'Asdfsadf' ), 3 => Array ( 'title' => 'asdfsadf', 'medium' => 'Sadfsedf' ), 'submit' => 'Submit' ); $images = array( 'image1' => Array ( 'name' => '_DSC0080.jpg', 'type' => 'image/jpeg', 'tmp_name' => '/Applications/XAMPP/xamppfiles/temp/phpxY22EN', 'error' => 0, 'size' => 1784656 ), 'image2' => Array ( 'name' => '_DSC0030.jpg', 'type' => 'image/jpeg', 'tmp_name' => '/Applications/XAMPP/xamppfiles/temp/phpy2Wq43', 'error' => 0, 'size' => 1724811 ), 'image3' => Array ( 'name' => '_DSC0001.jpg', 'type' => 'image/jpeg', 'tmp_name' => '/Applications/XAMPP/xamppfiles/temp/phpZSBkAp', 'error' => 0, 'size' => 2278345 ) ); // Get the person_id $person_id = $titles['person_id']; //Loop through images $index = 1; foreach ($images as $image) { $titles[$index]['person_id'] = $person_id; $titles[$index]['name'] = $image['name']; $index++; } var_dump($titles); The result: array(5) { ["person_id"]=> int(3) [1]=> array(4) { ["title"]=> string(8) "qwerqwer" ["medium"]=> string(10) "dfsadfasda" ["person_id"]=> int(3) ["name"]=> string(12) "_DSC0080.jpg" } [2]=> array(4) { ["title"]=> string(10) "sadfasdfad" ["medium"]=> string(8) "Asdfsadf" ["person_id"]=> int(3) ["name"]=> string(12) "_DSC0030.jpg" } [3]=> array(4) { ["title"]=> string(8) "asdfsadf" ["medium"]=> string(8) "Sadfsedf" ["person_id"]=> int(3) ["name"]=> string(12) "_DSC0001.jpg" } ["submit"]=> string(6) "Submit" }

Alternatives to doing xampp is to use either virtualization and vagrant, or use Docker. Most development teams have moved to Docker, since many sites are now using Containers to deploy their infrastructure. Docker containers are like mini servers that run something for you, so you would have for example, an apache container, a mysql container and a php container. It is also very easy to add other containers to the mix, like a redis container, or a reverse proxy with traefik or nginx. Docker makes managing the internal networking for this very simple. The containers can all be started/stopped with a single Docker-compose. Since this is all running on your workstation/laptop/whatever it has the same advantages for iterative development/testing/debugging as doing xamp or mamp for the most part, as well as advantages you xamp doesn't have, like starting up multiple containers of a type to test out load balanced/clustered systems, or quickly testing a different version of php to see what breaks. There are a few different projects that have configurable/pre created packages aimed at PHP developers and make it easy to switch in/out different pieces (mysql vs postresql for example). These attempt to make the use of docker similar to an xamp or mamp install. In all cases you do have to start with installation of docker itself, but after that these packages can be a convenient way of getting started without learning much about docker. Here are a couple to look at: http://devilbox.org/ https://laradock.io/ Laradock was created for use with Laravel framework apps, but also works great for other framework based projects or any LAMP/WAMP/MAMP based project. Personally, I use Docker now, whereas in the past I used Vagrant files. One last thing to note is that php has a built in server for a while now. As I am frequently working with the Symfony framework, the symfony project makes it very easy and convenient to develop your apps, although this does assume that you would have a local mysql or mysql in a docker running. Details for installation and use are here: https://symfony.com/doc/current/setup/symfony_server.html

The basic features of PHP Oop are one thing. Do you feel comfortable with those things? In particular: What is a class vs an object What are class properties What is the difference between the property visibilities (public, protected, private) What are static properties What are class methods, and what visibilities can you use How do constructors work What other magic methods are useful What is inheritance What is an interface What are static methods? What syntax can you use to call a static method What are traits Once you are clear on the syntax and mechanics of php OOP, then you can read more about the way OOP is typically used. These OOP design patterns provide a way to design your code so as to get maximum value and avoid many pitfalls that exist when people first start out with OOP. Here are some resources that might help: Dependency injection articles by Fabien Potencier, founder of the Symfony framework. This is important to understand, as DI is the foundation of the most popular PHP frameworks: Symfony and Laravel, as well as any number of other projects and component libraries. http://fabien.potencier.org/what-is-dependency-injection.html Design Patterns in PHP https://phptherightway.com/pages/Design-Patterns.html More design patterns in PHP https://refactoring.guru/design-patterns/php

It does seem that in your mind you build things up to be a mountain, when they aren't. I don't see using some sort of version control as an option. It's just the overhead of doing any sort of professional coding. I honestly don't see how you continue to develop without it (or some other sort of version control). I don't understand every nuance of git. I have spent time going over some of the fine points, reading about the internals, and practicing, but for what I need on a daily basis it comes down to a handful of commands. Things you need to do at the start. -Your development and production systems need git installed -You need to initialize your code base to git. (From project directory root...) git init -You may have to create a .gitignore file to indicate which directories/files not to add to version control -You have to add all the files (stage them) git add -You have to commit your staged files. git commit -m "commit message" -You have to create your github repo, and push your files to it. git remote add origin git@github.com:username/new_repo git push -u origin master -At this point you'll have all your files in your private repository, in the master branch. Just about everything you need to do here is described for you in github. Daily development: -Decide what you are working on -Create a "topic" branch git checkout -b some_new_fix -Now you are in branch some_new_fix -change files however you please. Add files, modify files, delete files. Test until you are happy. -Want to review the things you will be changing? git diff -Add files git add -commit the changes git commit -m "Some fixes like..." -push this new branch to your remote (github) git push -u origin some_new_fix -merge changes git checkout master git merge some_new_fix -Push the master branch git push Your production system should be based on the master branch from your repository. You would use github as the source by cloning your repo as the production structure. Pulling any new code into the production master branch is now: git pull That is the basic flow of doing things, with just about all the commands verbatim. You could make a test repository, play with these commands, push to github, clone the project to a new workstation or subdirectory, etc, and the entire process of doing this and getting comfortable with git would probably take you an hour or 2.

Perhaps it isn't clear, but with version control, and at this point, the world has standardized on git (for relatively good reasons in my opinion) there is no danger in changing "tested code." This assumes that you have a development/test deployment and a production deployment. If you only have "production" -- well, it goes without saying that the second you have any actual users, you are in big trouble. So, I will make the assumption you have a dev/test system, and again, there is no question that you can change anything you want with git, and test things, and you can do these tests with impunity, and without endangering anything in production. Learn git. Bitbucket and Github are origin repositories where you can keep a master copy of your code in the cloud. They are both used by lots of companies, and both offer private repos for no cost. There are limits to the numbers of people and repos you can have, but in your case either one will be fine. I have accounts and use both frequently, but my recommendation to you would be to use Github. Make an account to begin with, and there are a gazillion tutorials, including interactive ones that will teach you the basics.

Not understanding -- sure that is an issue for many people. I will grant you that there is a learning curve, and for many people the big picture is difficult. With that said, most of these projects had great documentation, and tutorials and demo projects to help people learn them. Writing everything from scratch was a mistake, because your site should have implemented MVC to give it a sane and maintainable structure, and you also clearly wrote lots of code that doesn't have a set of robust unit tests, so your site is inherently more buggy and less stable than it would have been if you had used a framework. You also reinvented the wheel, big time, rather than concentrating on the important things, as in your business logic ,and the functionality of your site. To rationalize this decision as a "challenge" when that challenge did not even include learning the basics of PHP OOP -- is It is what it is, but the path to becoming a better developer is being able to admit you made a mistake. Most project teams include a post mortem for this exact reason -- to reflect on the process, evaluate what worked and what didn't and hopefully improve.

Pretty full article on using the various Geometry and Geospatial features of MySQL and it includes manual references. Using the Postgis extension with Postgres. It's also worth looking at MongoDB which has pretty much had a GeoJSON type since it's initial release, as well as indexing to support it.

This is not the problem you seem to think it is. Really the only really insurmountable problems that can't be fixed with media queries, would be if you are styling predominately through the use of inline style statements echo'd in your php code, or if you have the entire site layout in multiple nested html tables, as was the case for many a site in the olden days. Something as trivial as a margin/padding etc. is not a problem at all. You do a media query and simply change the things that are not mobile friendly. For example: @media only screen and (min-width: 320px) and (max-width: 480px) { .logo img { width: 60px; } .company-name { margin: 0; padding: 0; font-family: Helvetica,Arial,sans-serif; font-size: 25px; } .company-pictures { display: none; } } Simple examples of common things you might do for mobile (use a smaller or different image for a logo, redefine a style class you apply to certain elements, completely hide a block that is nice to have but not essential for mobile users). For the record, 8 years ago there were a lot of things available that you could have used to build your site with. MVC frameworks like Zend Framework (2006), CakePHP (2005) and CodeIgniter (2006). Symfony 1 was released in 2007. Symfony2 was released in 2011. Not long after that, composer was released. Laravel was released in June of 2011. I have made efforts to make you aware of some of these projects in the past. Fear of breaking things you manually tested should not be an excuse not to change code, either permanently or experimentally. Is your code in a git repo? Have you pushed this to a private repo under github or bitbucket? If not, why not? If so--- Here's what you do: Make a branch (git checkout -b css-test Change as much or as little code as you want to experiment Commit your changes (Optionally) push your branch to your repo [while in branch] git push -u origin css-test If it goes to hell, no big deal, you made a branch and you can delete it if you want. If things work out, you merge your branch to master.

Adding onto Barand's reply, here's the technique to ingest the original integer and turn it into an array of digits. function mul(int $int) { return array_product(str_split($int)); } echo mul(12345); // 120

I think the point you are making, is that there is no holistic cross language debugging tool, but then again that is the nature of web development. There are a lot of different languages and ways you can connect things, which require different debugging tools. In recent years most of my projects have been done with either Symfony or Laravel, and they both offer a debugging toolbar that tries to bridge the gap somewhat, but at the end of the day, I find there are a number of different tools and techniques you need for debugging. The same is probably true of any networked system, where there are a variety of services that are connected in a non-trivial way. From a front end standpoint, the more complicated the javascript, the more you need to use the developer tools. More often than not, I'm looking at the network tab and looking at the request/response data. I'm typically only using the javascript debugger when I have something specific that I know is broken in a particular way. If I'm not sure exactly where thing are going wrong, then I'll step through the code by placing a breakpoint at an early/well known point. At the end of the day, once code is running in the browser, it is no longer something you can debug from the serverside.

PHP is a very different language from the one you learned many years ago. Any code you might have written is entirely obsolete, and probably you are running a PHP version that long ago was end of life. Candidly, PHP wasn't looking pretty viable, but in the last decade it has been steadily improved to once again be one of the best languages for web development. It has an excellent dependency manager: Composer. This enabled the creation of a truly impressive array of component libraries, many of which have great code coverage and unit tests, insuring quality and stability. It has two state of the art Dependency Injection frameworks: Symfony and Laravel, and there are others that are capable. There are several ORM's for relational database development supporting both the Data Mapper pattern or Active Record. The language has been enhanced to support many of the constructs and type of coding available in other languages, and performance has been improved in a variety of ways, so that large commercial websites are comfortable using it. It's once again a great time to be a PHP developer, but it's also a time to update your application and your knowledge. I would highly recommend learning either Symfony 5.2 or Laravel, by porting your application to them. In the process you will update your skills and at the same time, have a website that is clean, secure, maintainable and with your code concentrated on functionality rather than the basic MVC code most websites utilize.

Javascript debugging is done in the browser using the built-in developer tools. People typically use chrome. The exception would be if you have a node application or javascript front end application built on vue or react etc. but in that case you are going to have the front end code separate from the back end code, and be implementing a REST api or something similar on your backend, which is basically what you would want to do for any ajax calls. If you have lots of mixed PHP/HTML scripts you can still debug those with the PHP debugger, but it's really not a great way to develop clean maintainable code. Most pro developers use PHPStorm. It's not free obviously, but it's the premier solution. It has so many options it can actually be pretty daunting, but it also provides the best navigation through a complicated code base of any IDE. As for free options, I have also used phpeclipse, which is built on top of eclipse. It's not terrible, as Zend for a time had a commercial product based on it, but Zend no longer exists as a company. Lately I'm using Visual Studio Code, but I haven't made a lot of efforts to get it setup for PHP. It's really where a lot of the web development community has migrated, and the support and velocity of enhancements is very high.

It looks to me like you have some sort of sync issue with your environment, because there is no reference to a key of 'title' in the script you posted. There could be all sorts of reasons depending on how you are testing or revising your code. This could also be because you have a cached version of your code. Did you try to restart your apache/php? If that doesn't fix the issue, I'm not sure what to tell you, as the code you provided does not include 'title', but does include 'titel' in a number of places. If you changed the spelling of 'title' to 'titel' recently that would also suggest a caching issue. If you are interested in where this type of caching might exist in a development environment, reference OPCache. OPCache is a performance enhancement that caches source code in memory to vastly improve runtime production. It might be installed in your xampp. In a development scenario, it is probably advisable to disable it just to remove the possibility it might interfere with your development cycle. Again this is just an educated guess based on what you provided.

You also have to realize that there are no longer any versions of PHP that will work with unaltered 10 year old code. You most likely will need to update your system to work with a current supported version of PHP.

We can't guess what your code looks like.