gizmola

There isn't really a "php database". PHP can talk to many different types of databases through client libraries. So... I can not guarantee this is going to work, but it's worth looking into. The primary goal here is to keep you within PHP which you know, which should make writing the code you need within your comfort zone. You need an MQTT Broker that your ESP32 device will be publishing to. This needs to be some sort of network connected device that can run your MQTT broker, as well as your SQL database + storage for your data. You will also be running an MQTT client job that will be subscribed to the broker and will take data and add it to the SQL database in (near) realtime Here is an async server package called Swole that is added to PHP via an extension. You would need to use PECL to add it to your PHP installation which will live on the aforementioned server With Swole you run a php based MQTT broker/server. Here's simple code that shows how you would do it: https://www.swoole.co.uk/docs/modules/swoole-mqtt-server You write a client who subscribes to your MQTT Topic for the data you are charting, and transforms that data. Again there is a php library for this, and there may be others if you do some googling, packagist searches etc: https://github.com/php-mqtt/client Your client will receive the data and add it to your SQL database each time a relevant message is received with data you want to store Now theoretically, you can cut out this client piece by adding code to your Swole based MQTT broker. As messages are published to the topic, you should be able to process the data and add it directly to the the sql database, so like anything there are multiple different ways to do this with strengths and weaknesses for each. If the server code can do it directly, clearly that's simpler and better.

Another way of doing this that uses some array functions would be: $countries = array_intersect_key($countries, array_fill_keys(array('US','CA'),0));

Highly unlikely. Performance tuning isn't something that is typically fixed with a couple lines of code, and typically requires various forms of expert level profiling and sysadmin/devops skills.

Yes, well we would need to actually see your code if you want help.

Good luck with your studies.

I missed the subtlety in your question. Barand has a good solution.

Here is a simple example, turning the date strings into DateTimes and then using format to output the date. You will need to read the manual page Strider64 provided to reference all the different ways you can specify output. There are also a number of predefined constants you can use. <?php $dates = array('2005-05-21', '2006-11-01', '2006-11-02', '2020-09-28', '2020-09-29', '2020-09-30', '2020-10-01'); foreach ($dates as $date) { $dt = DateTime::createFromFormat('Y-m-d', $date); echo $dt->format('r'); echo PHP_EOL; echo $dt->format('\i\t \i\s \t\h\e jS \d\a\y.'); echo PHP_EOL; echo $dt->format(DateTimeInterface::ATOM); echo PHP_EOL; echo PHP_EOL; } Your dates all need to be valid, or you may get some odd results. It is possible to check as to whether or not a date was invalid, which is documented on the manual page for Datetime::createFromFormat(), if that is a possibility you need to handle.

So you have 2 items you can work on. The first was brought up by benanamen, which is really a syntax issue. You are not referencing arrays correctly: // Use this if (isset($_POST['itemName']) { // Not this if (isset($_POST{'itemName'}) { That is not the source of your current problem however. Your current problem is that whatever javascript you have that you assume is making your form valid, is not valid, so your text field is not being passed when the form is posted. Another good debugging tool is to use something like chrome dev tools, and look at the network tab when you submit the form. You can then see the contents of the post variables as they are sent when you submit the form. In conclusion, right now your problem is your html/javascript code and has nothing to do with PHP. The code is working as you intended, as $_POST['itemName'] is not set/does not exist.

Add a debugging statement at the top of your script of var_dump($_POST) and verify your assumptions.

I will try and come back and take a look at your code, but I wanted to say that using PDO is great. I would say that the staff is universally in favor of using PDO, so no worries about learning mysqli.

Transactions are another one. I don't really disagree with what you wrote, and in fact I linked to information that agrees with you. The problem with anything concrete is that we don't know if jodunno is using PDO or MySqli.

Actually, I think that Barand just made a small mistake, which is certainly very unusual for him The unique constraint should be: UNIQUE KEY `unq_page_link` (`user_id`, `page_link`), That will enforce uniqueness on a user/link basis, which is what I assume you are going for. This is a better solution in that you are using the db to enforce your integrity rule rather than relying on the front end code to do it for you. With that said, code around database queries needs to be written in a way that you catch and deal with database errors appropriately. Typically that is done with a try..catch block. I can't give you specifics without knowing in advance what db api you are using (mysqli vs pdo) . Here's an example out of the "(The only proper) PDO tutorial" which is highly recommended reading for anyone learning the PDO api: try { $pdo->prepare("INSERT INTO users VALUES (NULL,?,?,?,?)")->execute($data); } catch (PDOException $e) { $existingkey = "Integrity constraint violation: 1062 Duplicate entry"; if (strpos($e->getMessage(), $existingkey) !== FALSE) { // Take some action if there is a key constraint violation, i.e. duplicate name } else { throw $e; } } Assuming you are using PDO this could be adjusted to fit your problem as it is essentially the same issue you would face in dealing with the unique constraint violation to prevent a user from adding the same link multiple times. If you are using mysqli, then you should certainly read this. A general discussion of php error handling strategies is good to read. The important thing to note about this, is that you don't want to generalize error handling to try .. catch blocks around all your queries. This is a specific issue, having to do with something you expect to happen frequently. Lots of other database exceptions can happen, and you want to have a generalized exception handling solution for those.

The html generated along with the css you used, would allow people to help you diagnose what is or isn't working. Also, you would still need tables, or alternatively convert to flexbox or css grid

Please provide an example of the array you are expecting to generate.

Let's look at your method: public function countVehicles (){ $this->db->query("SELECT COUNT(id) FROM vehicles WHERE id = :id"); // Where is the :id parameter? You do not pass it into the method nor do you pass it to the query $counter = $this->db->rowCount(); // This, should it work, will always return 1. Not what you want! return $counter; } You do not want to do a rowcount on that query, because it will always be 1. Select count(id) is going to always return one row. Even if there is 1 row counted or a million, or zero. The reason the query was suggested is that it will always have a value. With that said, you would need to fetch the row to access the value, not count the number of rows in the result set. Personally, in order to have a simple column name to use, I will alias the result of a count() query like the one suggested. Here is how I would do it: "SELECT COUNT(*) as count_of FROM vehicles" Then if you have fetched this result into a variable in some way, you can expect to access the value via something like $row['count_of']. With that said, your query by id, assuming that id is the primary key of the vehicles table, will always count at most one row, because the primary key must be unique. There are compound keys that could complicate this, but I don't see anything you are doing that suggests you have a table with a compound key. Are you just trying to get this to work, so that you can do what you *really* want to do? I'm going to assume you actually want the count of all vehicles as you did initially. If things were working as they should, your original code should have worked. Something is not working in your database model/class. Unfortunately, I can render no further aid, because I would need to know more about what "MVC" you are using. MVC is a design pattern, not an implementation, and has been implemented in various ways by nearly every popular PHP framework, with a few exceptions. What framework are you using, or is this something you have built yourself from scratch? What is the source of the database class?

One other option available to you would be to use HTML 5 local storage. This allows you to have the client save its data locally. Since you would be well served to update your html from 4.01 to 5 anyways, it would be a great time to experiment with LocalStorage. The javascript API is incredibly simple: localStorage.setItem('myCat', 'Tom'); const cat = localStorage.getItem('myCat'); localStorage.removeItem('myCat'); localStorage.clear(); //Clear all items Ajax is the answer. When you have a cascading group of interconnected dropdowns, you want to convert your code to make ajax calls. On the serverside it's pretty easy -- you just concentrate on the data. So let's take zipcode to city/state as an example. User is prompted for a zipcode, and you then lookup the city/state for that zipcode in your database and return those. The client parses the city/state and updates those values in the user's form. Lots of things have changed in the javascript world since you first implemented your app. You want to move to the modern way of doing ajax calls, which is to use Fetch with promises. The two go hand in hand, in that fetch was designed to use promises. About this, I will just say that the hard part of ajax is what happens when there are errors. People often concentrate on the "happy path" where everything works, and ignore the issues with the asynchronous web. Fetch and promises help you write a more robust app with simpler code. Here's a nice tutorial link, although there are many available if you need more help learning them. For example, if video tutorials work for you, you can find many on youtube by searching for "javascript fetch". One important fundamental is to return all your data from your php scripts in json format. That makes it easier to integrate the results into your clientside code.

There's a few different ideas in play. In the olden days, if you wanted to maintain a channel of communication between a (web) client and your server you could use polling. This was essentially some javascript running in the client on a timer that would make a request to your server every so often. The problem with this is that as the number of users goes up, so does the number of requests purely to poll the server for new messages. The next evolutionary step was Long Polling. The idea with Long Polling was, that the client would open an ajax connection to the server (with HTTP these are TCP socket connections) and hold it open listening for a response. The server only responds with data if there is a notification. At that point the client closes the connection and immediately opens a new one. This was a good work around for systems where notifications are desired but are relatively infrequent. With PHP it also has some significant overhead in traditional Apache/Mod_php environments, as a child process will be forked/allocated to each running PHP script. This can tie up a lot of children with large allocations of memory, simply waiting on open ajax connections. The next innovation was Websockets. The idea of websockets was to create a specification that does not work within HTTP, but instead is intentionally designed for standalone persistent client/server communication. This has become a well adopted technology at this point, as libraries and servers exist in javascript and all serverside languages. The big advantage of websockets was that it was client agnostic in that you could build a serverside solution that will work for any type of client you might have. So if your serverside app is basically a REST api used by mobile clients, you will probably choose websockets. There are also numerous PaaS vendors out there like Pusher, who offload the serverside overhead of Websocket communication and operate as proxies for websocket communications. Your client code can talk to Pusher who manages the socket connection to the clients, and you then write a serverside script that connects to Pusher and handles messages and sends responses to clients as needed. Even if you run your own Websocket server, you will implement a similar architecture. The latest innovation is the Web Push Protocol built right into various web browsers. This was meant to address the lack of OS level notifications that exist in the mobile OS's which mobile app's can use to subscribe a user to serverside information. Websites have long desired a way to re-engage or update users without their having to visit the site again. Email has been the traditional method for that, but now browsers are allowing subscription opt-ins for a website, which you can use to send notifications to users. Of course the main issue is that these notifications are specific to a browser AND the user must have the browser open to receive them. With that said, sites have rushed to implement the technology, and as in the case of Websockets, scores of PaaS vendors have emerged to act as middlemen in implementing proxies. There is an awful lot of setup and configuration involved with Web Push implementation. A great way to understand and perhaps implement your own web push notifications would be to use a component library like web-push-php which has documentation and references you can use to learn what you will need.

You don't need the value of oak to increment it within the database. "UPDATE users SET oak = oak + 1" With MySQL you do need to be careful with this type of update, if the original value of the oak column is NULL. See this article on the problem. Make sure that an uninitialized row is 0. The obvious problem that jumps out is that this query will update ALL rows in the users table. I think this is probably one of the things Barand noticed. One would expect that you would be updating the row for a particular user. If this is just for development purposes right now, then one would expect something like: "UPDATE users SET oak = oak + 1 WHERE id = 1" This assumes the users table has a primary key column named id, perhaps with auto_increment, and as a user logs into the system this page would use a session variable to set the specific user row to update.

You already have what? php artisan serve starts up the development server on a port. You are accessing the port. When you say it "doesn't work" you would need to be a lot more specific about what you already have installed and configured.

To run a web application you require a webserver. To run a web application with php you also require some support for php integrated into the webserver. There are a number of different webservers, the two most popular being apache and nginx. There are a number of different ways of integrating php with the webserver. With Apache you can choose to use mod_php which is an apache module that integrates php or you can use apache with php-fpm (fastcgi process manager). With Nginx, your option is to use php-fpm. Eventually people typically also will need a database or data persistence server like mongodb, and often will have a caching server like Redis. On your local machine you can install the webserver and everything else you will need and run those. There are popular installation and configuration setups like WAMP and MAMP that have been around for a long time, and many people use. I have mixed feelings about these. The problem is that they install all these things on your workstation, some of which you might not want or need, and then they are running typically even when you don't need them because you aren't developing. They also have to be upgraded and managed as time goes on. In recent years there was a move by most developers and teams to using virtualization. With virtualization, you can run a virtualized server on your workstation and interact with that server in the same way you might interact with a hosted server. The great thing about virtualization is that you can start an environment when you want it and stop/pause it when you don't. It's also isolated from your workstation. This has many advantage including the ability to develop on the the same platform you will deploy to, as most servers are running some sort of linux, with the vast majority being either RHEL/Centos or Debian/Debian based distributions. Installing a virtualization manager like Virtualbox or Vmware facilitates the use of a provisioning manager like Vagrant. With Vagrant you can use vagrant "boxes" which will download and start up a full virtualized server environment with all the server processes you might want or need. This is how lots of people were doing development even a few years ago, and there are many people who probably still use Vagrant. More recently many developers have moved to Docker. Docker supports "containers" which are small environments that can run anything from a full server, to a single process. I won't go into all the details, but with Docker you can start up the things you need (for example apache/mod_php in one container, mysql in a 2nd container) and allow you to run your application locally while also allowing you the same iterative development process you might use with the php server. To understand all of this, you also have to understand a fair amount about networking, dns, linux distros, package managers and shell scripting, as well as the support and configuration of a webserver. If you want to proceed, then I'd recommend learning about Docker. There are some projects that have pre-built docker environments you can look at. https://laradock.io/ is a popular one that is focused on laravel projects, but can be used for other php projects. I've also heard good things about https://lando.dev/ although I haven't had a chance to experiment with it, and then there is the massive but generic LAMP http://devilbox.org/ Any of these will help you get a jump start on using Docker as an alternative to installing everything locally. At the end of the day, going to localhost:8000 vs localhost is not a sufficient reason to spend all the time going down the rabbit hole of all this stuff as you are still learning the basics of web development and php coding.

$query = 'SELECT * FROM convoy_part WHERE user_convoy= :I'; $start = $bdd->prepare($query); $start->execute(array(':I' => $_GET['id'])); $rows = $start->fetchAll(PDO::FETCH_ASSOC); foreach ($rows as $row) { // Zählung der Datensätze echo "<pre>"; print_r($row); echo "</pre>"; }

php artisan serve starts the php development server. How do you plan to deploy/run the application if you are not going to use the php development server?

Spam identification and refusal is based on scoring of criteria. The higher your spam score, the more likely a particular hosting company receiving your email might decide to classify it as spam, or even refuse it outright. Since you have no access to godaddy's mail servers, you will not even know if your mail is refused because you are not sending it directly. GoDaddy is sending the mail for you. Here's things that will cause your spammy score to increase, depending on the policies and software of the destination mail service you are using: mail came from a server without a valid reverse DNS listing No SPF entry for sending mail server Spoofing of from address Lack of DKIM configuration Lack of DMARC entries Content of subject line Content of message contains spammy things So the basic things you want take care of are the "non-content" settings. If you want to send email from a gmail account, then there is a way to do that, which is to use IMAP to transfer the mail to your gmail account, and let gmail send it on your behalf. You can not send email by using phpmailer to make an smtp connection to godaddy's servers and have them send an email that says it has come from user@gmail.com. That is the definition of spoofing and will be seen as spammy. Let's assume that you aren't going to do that, and instead you will have your own domain for the purposes of sending these emails. You want to hit all the things above: valid SPF entry created as a DNS txt entry valid DKIM (requires both support from godaddy AND a DKIM DNS txt entry for your domain valid DMARC (requires working SPF & DKIM), also a DNS txt entry GoDaddy should also have a valid reverse DNS entry in place for all their mail servers. So in conclusion, you need support from GoDaddy for DKIM (and DMARC is built upon that) but you could reverse engineer what you need for SPF without goDaddy doing anything special. DKIM is complicated, but supported by many large ISP's. Google for example makes it easy for you to setup DKIM using their online tools to generate the keys and corresponding DNS entries you need, which can be done by anyone with GSuite service. If you can't get GoDaddy to work, a Google GSuite account might be an alternative worth looking at, and then you'd configure your mta to utilize the gmail infrastructure rather than godaddy's mail servers.

To elaborate a bit, talk to your clientside developer and ask her for some test output. If she is not already outputting the collected data in json, then you want to ask her to modify that. She will need to change the app eventually to send output to the domain/url of the production server anyway. Ideally the url to send data would be configurable in the client so that you can have multiple server side environments (dev, test, prod). Development is the one you are currently working on now. Test would be for automated testing, and prod is of course production.

The way that the client/mobile app and the serverside routines will work, need to implement some sort of standard. My suggestion would be that you utilize json. So the webapp should send it's data to the web app in json format. In PHP it is then simply a function call (json_decode) in order to convert the data into either php objects or a php array.