Jump to content

gizmola

Administrators
  • Posts

    5,250
  • Joined

  • Last visited

  • Days Won

    78

Everything posted by gizmola

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. $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>"; }
  6. 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?
  7. 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.
  8. 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.
  9. 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.
  10. Based on this page, the Euclidean distance function requires 2 points (p1, p2) so a function to calculate it would be something like this: function EuclideanDistance($p1x, $p1y, $p2x, $p2y) { return sqrt(pow($p1x - $p2x, 2) + pow($p1y - $p2y, 2)); }
  11. I watched most of this, and the step where doctrine is installed and configured seems to be right. You might want to try deleting the vendors directory and running another composer install.
  12. From the example data, that's what it looked like to me -- group by cust_id.
  13. There are some tools that can help you: A source scanner: https://github.com/kgoedecke/unused-css-parser A site that will analyze your pages: https://unused-css.com/ Unused-css will let you analyze one site for free up to 100 pages.
  14. Yes, or the DIRECTORY_SEPARATOR constant, which is equivalent to '/'
  15. The placement and organization of apache configuration files has no standard. Application packagers have added organization and conventions over the years. The sites-available directory is a debian thing (afaik) and went along with another directory, where the idea was that you would put a configuration file for each vhost/site you were hosting. There was also another directory (sites-enabled) where you would make a symlink to any sites-enabled conf files you wanted to actually be live, and then restart apache. Again this is the convention of that particular package maintainer, and different distros (Centos/Redhat) for example don't use it. At the end of the day, it doesn't matter where you put things, so long as you understand what directories are looked at for configuration. You could use one giant httpd.conf file if you want. The important thing is to look for those include statements, grok the various directories that are included, and any files that might be in those directories, and in general just be sure you understand where they are loaded. If you have rewrite rules that you want to include for a vhost, there is nothing wrong in sticking the in the default vhost files, if those are all you are using, but keep in mind that those files were placed there with the intention that they would be examples you would use as templates for the actual vhost files people typically have, and which are named for the domains they are meant to serve up. This is also why the sites-enabled scheme was beneficial, because it doesn't matter with that scheme if you have other unused files in sites-available.
  16. There is some information about it. I agree that step one on this is to echo out $target_file, and determine if that file exists on the file system.
  17. Depending on the way the app is written you also might be able to get away with a backwards compatability shim. I don't recommend or endorse this, but in some cases, it might be an acceptable way to avoid having to change all your mysql_ calls to mysqli_ (assuming that is all you are actually going to do, rather than actually updating the SQL statement calls and rewriting your code to utilize parameters). A "Shim" is a library that retrofits old code in some way so that newer code works, so perhaps this is not technically a shim, depending on how you look at it, but the idea is that you use a library that fills in the missing library calls (mysql_) so your existing code will still work. This would work best if you at least have your mysql connections created in include files, otherwise you will have to go through changing every script that makes a connection. If you have to make changes all over the place, you are probably better off consolidating code into includes, and changing to mysqli or PDO as others have suggested. This is a quick retrofit using a mysql backwards compatibility library. There are some things you need to do in advance. 1st you must have installed a working version of composer You need PDO installed in your PHP 2nd you need to add a composer.json, assuming you don't have one. At minimum you would update your project composer.json require section { "require": { "mattbit/mysql-compat": "^1.1" } } Use composer to generate an autoloader for you. This will be created in the {project}/vendor directory. Let's suppose you have a script in your project root that gets called. You would add code similar to this to call the autoloader, and to load the compatibility library. require __DIR__ . '/vendor/autoload.php'; Mattbit\MysqlCompat\Mysql::defineGlobals(); This will add the shims for the old mysql_ code, and if all goes as planned, your existing code will work unaltered. Again, I'm not recommending this, but it if's an old site that you have no plans to update, and just want to keep it working as is, this does work, and doesn't require you to go find all your mysql_ calls and change them.
  18. One traditional way to get around this issue is to use Expect. Expect is one of the first automation languages I am aware of and is great for handling user input prompts that come from utility programs that might be used in a shell script. It's been around for a long time and there is a version for both for linux and windows. Are you using windows btw? All the system and process functions are closely tied to the OS you are using.
  19. You just need to use the Ubuntu package installers inside the shell in your ubuntu vm, which in your case is probably something like this to get both packages: sudo apt-get update && sudo apt-get install libsodium-dev; sudo pecl install -f libsodium sudo apt install php-cas You are going to need to stop/start php-fpm & apache after you installed the packages. Do checks with php -i and phpinf() and make sure that the packages are being seen by by command line php and php in apache.
  20. Functionally, it is true that you could use a string or a timestamp to store your times. You should use a timestamp. It works better from a database standpoint, since you can do queries to find timestamps <>= NOW() or some arbitrary time. Also a timestamp takes 4 bytes, whereas a varchar takes as many bytes per row as needed to store the string one for each character, so -- 'mm-dd-yyyy hh:mm:ss' 19 bytes vs. 4 per row? String comparisons are done character by character, which might not work the way you expect, whereas mysql datetime/timestamp types work exactly as you would expect. In your case you would not need to pass anything into the query -- just determine the offset interval you want and encode that into the static query.
  21. It's really important to have a scheme like the one requinix is suggesting. Let's consider it this way (without the rewriting) #home page. You can make this the default page by routing to home if there is no route parameter index.php?route=home #rewrite route /home #contact page index.php?route=contact #rewrite route /contact #faq index.php?route=faq #rewrite route /faq #faq item #3 index.php?route=faq&item=3 #rewrite route /faq/3 #acme customer store page list of items index.php?route=shop&customer=acme #rewrite route /shop/acme #individual item #14 page in acme store index.php?route=shop&customer=acme&item=14 #rewrite route /shop/acme/14
  22. This SO thread covers a lot of the probable issues with getting phpMyAdmin running and accessing it including: Did you start the MySQL server? Did you configure phpMyAdmin to access the MySQL server? What url should phpmyadmin be at?
  23. Provide an example of what you mean by that, and how you plan to use it.
  24. Here's a really good article about this issue (and other related ones you might not have though about either: https://www.danielmorell.com/guides/htaccess-seo/redirects/https-www-and-trailing-slash For example another related problem: https://www.mysite.com/foo/bar and https://www.mysite.com/foo/bar/ Will be seen as 2 different urls, so you want to effectively remove the trailing slash when you are routing a non-directory.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.