gizmola

It appears that writing PHP event handlers is simple and works well, and people have been using fullcalendar with PHP for some years now without issue. It's a fairly standard approach to wiring together js UI with PHP backend. Hopefully it's clear that you send and receive data in json format.

But what is the 1st task, and how is it connected to this? My kneejerk reaction is that there are FOSS IDS tools like OSSEC you should look into. Even if you continue to go forward, an asynchronous approach is going to be better. When your site is inevitably accessed by bots/spiders, the overhead of spawnng a php process for every request is likely one that you will regret.

What is the application or problem you are trying to solve? This has all the hallmarks of an X/Y problem. What I can deduce: Some event occurs and some action is taken A 2nd action should be taken some time later (60 seconds in your case) However you don't want action 2 to occur in some circumstances for reasons undisclosed You've used the phrase: From your description, every request is immediately handled. Without knowing the purpose of this 2nd action, it's difficult to provide advice, but the obvious problem is that you want the 2nd action to be aware of the first action. Rather than a dumb process blocking for 60 seconds, it appears you want a process that will be created with a future event datetiime (1 minute in the future) If before it completes, a new event #1 comes in, you modify the expiration datetime and set it to 1 minute from the event Another possible low tech way of handling this would be to have process 2 implement a semaphore/lock file that is checked for when process 2 is run. Shared memory and IPC semaphores can be helpful for something like this. With that said, anytime you utilize a mechanism that relies on a single server architecture the scheme is inherently non scalable. This is where things like queues or databases typically come into play. Using some in memory server like redis is often a better platform.

That wasn't the point of the example code, and ... it's meaningless example code. The point was to clarify how ticks function. Without enclosing the code in a block, the results will probably not be what is expected. Hope this has helped you. If you are doing something interesting with this, it would be great to get a follow up.

For your first question, make the tables relationally correct to 3rd normal form. The opposite of normalization is de-normalization, and you have no reason to create anything that is de-normalized. So a list is a collection of songs, that can also have associated "categories" or "tags" from the sound of it. It does seem like you misunderstood the question I posed. It's understood that lists are entites with 1 -< Many songs. The question is the relationship from a list to an event. Can an event have mulitple playlists? If so, then the relationship between an Event and a Playlist is Many >----< Many. You would probably want a way to order those playlists in the many to many. I don't know if you understand how to handle a logical many to many relationship between 2 entities, so I'll just tell you the answer: You create a table that relates to each. Often people will use the names of the related entites for the table name: event playlist So you create a table named event_playlist. In many cases it is convenient to give that table its own auto_increment key, but you can also just use the combined foreign keys by making the relationship "Dependent". Dependent relationships become part of that table's primary key. So one way of doing this is to create this table. event_playlist -------------- id (primary key auto increment) event_id (fk from id of event table) playlist_id (fk from id of playlist table) start_time datetime From the database design standpoint, when you have relationships between tables, with mysql you need to add "declarative referential integrity" statements that enforce the relationships. You also need to use (assuming mysql) an engine that supports them, which is typically InnoDB. You can define the relationships in the table create statements, but typically it is better to add the constraint separately using "alter table". Here's examples out of the MySQL manual. Database design has to match requirements, and there are many questions you should ask, including what is the purpose of this database, that will have to be maintained, and what are the functions an application needs to have. Here's one small example: Can playlists be changed over time, and if they are, how does that effect the use of the playlist within the application? If the answer is, that a playlist, once it was part of an event, is meant to be a historic record, then you need to add some sophistication to the database in regards to changes to a playlist. I'd call this "playlist versioning". There's no way to know if you need to design in playlist versioning or not, but these are the sorts of questions that need to be answered before you complete design of the database and start coding.

If you have specific refactoring questions or want some advice, consider making new threads. The community here is full of experienced professional developers who are generous with their time and knowledge.

I'm going to jump in here, and clarify some things about (twitter) bootstrap. It doesn't do anything secretively. It's css with a sprinkling of jquery (at least in the old days) in places where there was no good way of adding functionality without a bit of js. Much of that is non-essential, or has a workaround. As jquery fell out of favor, this became a knock on Bootstrap, and at this point they have decoupled and removed the jquery dependency. It was also designed to make it simple for people to make a responsive website with it's "mobile first" philosophy, and to take advantage of flexbox and css grid without knowing how to do that, at a time when techniques for that were not well understood by many developers or established. It made it easy for novices to implement a lot of sophisticated css techniques without understanding them, and It certainly influenced and set the stage for many other css frameworks that have emerged since then like tailwind. When you look at it with an understanding of all those underlying concepts and the techniques you would use if you were creating all your css from scratch, it makes a lot more sense, although at that point, most UI developers wouldn't use it. It's still a great foundation for getting decent looking UI together when you are more focused on serverside development. If you are already in the practice of using scss/sass then it's even better, but many people never got to that level of proficiency, so it did lead to a proliferation of vanilla looking "bootstrap" websites for a time. I would rather see someone learn to use bootstrap effectively to build a responsive website (which btw, shouldn't all sites be responsive now?) rather than flounder or skip that entirely. I do think there is a misunderstanding amongst many people, both in how you should apply it, and how it should be used. I think a lot of people who don't know how to build components like modals, navbars and accordians thought of bootstrap as a quick way to get one of these UI elements working, using cut/paste from the documentation, and without going beyond that. It's sort of a catch-22 that you really have to understand css layout, and the things that go into responsiveness in order to see how best to use bootstrap, and a lot of novice developers struggle to get those fundamentals, and see the whole framework as magic.

Personally, I would have used an MVC framework so that I'd have separation of routing from Models/DAOs and Views/Templates/Markup. I'd most likely have some "services" and would be making use of quality component libraries whenever possible. Everything I create would be implemented in a way consistent with Dependency Injection, which would allow for use of a Dependency Injection Container. I prefer Symfony, so if it's my choice that is what I'd start with, which is going to dictate basic structure, and have a front controller pattern implementation. What you've done could be broken up into pieces and ported into an MVC framework, which would also help you see where you have reinvented the wheel, and you might also find that that framework has capabilities that could be handle some things you are doing in a more robust or elegant fashion. I also tend to make use of PHP Oop and if you do have classes stuffed inside your one giant script, then that's a dubious practice. While there is no fast rule on this, given PHP's page scope you are clearly having to load lots of unused code for every page request, but I don't want to overstate what currently even at 1500 lines of code, is not by any means overly large.

mac_gyver as usual provided you with a clear answer. HTTP protocol is request/response. Without some other streaming protocol, once a client has received a response, the tcp connection(s) required to get all the assets for the page, and the building of that page are close and the rendering of the page and any interactivity is entirely client side. New requests can be initiated, or you can have some javascript (ajax) that makes requests using javascript that can then be used to update the page without having an entirely new HTTP request (GET/POST/PUT/DELETE). There are ways to have a client poll ajax calls, or alternatively to use websocket protocol. You often see websockets used to provide more real time functionality. Regardless, for every Request sent to the server, checking for authorization of the client must be done. In other words, it should not matter if someone has their browser open to your site, as a logged in user who has now had their account deleted/suspended etc. All that matters is that the deletion/suspension/logout is enforced on the CURRENT HTTP request.

Great answer from Barand to your specific question. As for your initial question, start with your entities, and the relationships between them. You mentioned: A DJ Organizations Events Playlists I'm unclear if this means that an event could have multiple playlists, or just one. Implied entities are: artist album song/track So you want to start with the entities and determine which attributes they require. Every entity will become a table, and every table needs a primary key, which unless you have expertise and a strong reason not to, should be auto incremented unsigned "integer" types. You want to use the smallest reasonable type. Some "lookup" tables, you will know in advance will never have more than a handful of rows. Use a tinyint type. Use the smallest type you can get away with. Organizations is a good example here, where you can use a (with mysql for example) a smallint, which unsigned means you could have up to 64k rows in it. With little chance of ever having anything close to that number of orgs, stay with the 2 byte primary key instead of making everything an integer or worse yet a bigint. Once you have the entities ready, then relate them together, by determining the type of relationship needed (one to one, one to many, many to many) and at that point add foreign keys and add ables as needed. There are many ERD design tools that can help with the design process.

@Strider64 my friend, lose the closing PHP tags -- as per https://www.php-fig.org/per/coding-style/. These days I'd recommend that you use mkcert for local development, and not have a configuration variable to get around the use of https only cookie settings. It's just inviting a mistake to be made. I don't know if you've started to make use of docker, but DDEV is a really nice wrapper for setting up docker based PHP development environments, and it integrates mkcert, so you don't even have to invest any time in figuring out mkcert yourself, as they've integrated that into DDEV. It's also a cli tool, which I like.

Usually we would not allow promotion like yours, but in this case it's on topic, and also a helpful example, as the forum utilizes the very techniques your article covers.

If the link has a "rel" attribute equal to "nofollow" that tells search engines that they should not follow the link. So yes, that will effect SEO. This article explains "nofollow" and other values for the "rel" attribute that are important for SEO. In summary, "nofollow" tells search engines to ignore the link.

Which is a bad fix. What you did was make your site dramatically less secure, by allowing people to create cookies without going through https:// which is a really bad idea. Is this an issue that only comes up in development, perhaps because you don't have a local cert installed? When you have a problem you really have to do a better job of describing the environment under which you had a problem. 99% of the time, if you had working code and it stops working, there is an explanation for that having to do with some environmental change. One tip: on your register/login script, as with any other pure PHP scripts, you should remove the ending PHP tag. I believe that someone else explained to you on another thread, that using session variables to handle bad login attempts and lockouts is another really bad idea. People wanting to brute force won't accept a session cookie, so all that logic will have no effect on those people or their automated brute force scripting. You have to log bad attempts using some sort of persistence (typically a table related to your user table) which include the datetime/timestamp and the IP address. You can then lock out an account for a period of time, as well as locking out IP addresses that might be trying a range of different email/password combinations. You want to prevent both.

C++ OOP is more complicated, so you should not be having issues picking up PHP OOP. For example, PHP OOP doesn't have templates/ operator overloading or multiple inheritance. The best examples of how to apply OOP are those you find in some of the better known component libraries, and in particular those associated with Symfony and Laravel. For everyday use, you want to learn about the Design Patterns described in the Gang of Four book. You don't have to buy this book to learn about these OOP design patterns but many people do, and it's a common text book from my understanding. There are similar books specific to PHP, but I can't personally vouch for any of them. One of the most important OOP design patterns is the Dependency Injection pattern (sometimes called "Inversion of Control"). There are a number of well regarded frameworks that fundamentally are Dependency Injection frameworks. Spring (for Java) was one of the first I was aware of, and for PHP Symfony and Laravel are both DI frameworks, as are any number of other frameworks, given the advantages of the pattern. You want to read about Dependency Injection. There's an article here, that talks about DI and has some examples: https://php-di.org/doc/understanding-di.html Coming from C++, you should already have a good handle on inheritance, methods, constructors, variable scoping, static variables and methods, etc. You want to learn about PHP Interfaces and more recent PHP additions like traits. For free video material, there are any number of tutorials and free courses that cover PHP OOP. I have frequently recommended this channel, and many experienced PHP developers seem to agree with me, that he does a good job covering the syntax and providing examples.