Leaderboard

the only user data you should store in a session variable upon login should be the user id, to identify WHO the logged in user is. this will either be set or it won't be. you should query on each page request to get any other user data, such as a username, permissions, or role. this is so that any changes made to this other user data takes effect on the very next page request. this will allow you to promote or demote a user without requiring them to logout and back in for the change to take effect. do you really want a situation where you have demoted or banned a user and they can still access a page because their session data says they can? i recommend that you simplify the logic and separate the login test from the user role test. also, to test if a variable is in a set of values, define an array of the permitted values and use in_array() to perform the test. using these suggestions, the logic would become - $page_roles = ['Member','Secretary']; // roles permitted for the current page $user_role = 'Guest'; // default value for a non-logged in user // is there a logged in user if(isset($_SESSION['user_id'])) { // query here to get any other user data, such as the user role, and store it in a regular variable // fake a value $user_role = 'Member'; // $user_role = 'Secretary'; // $user_role = 'Other'; } // logic to determine if the current user can access something on this page if(in_array($user_role,$page_roles)) { // access permitted echo 'permitted'; } // logic to determine if the current user cannot access something on this page if(!in_array($user_role,$page_roles)) { // access denied echo 'denied'; }

If you are wanting to know which keyword(s) is/are found, there is one flaw in your logic - it exits the function on the first keyword found. What if there are two or more keywords that are found? Instead of returning true on the first keyword found, I'd suggest adding the found keywords to an array. Then return the array. Also, I would assume you would want to do a case insensitive search. E.g. if you have "spamword1", you would want a match on something like "SpAmWoRd1". If so, you would want to use stripos() Give a look at this: $uri = $_SERVER['REQUEST_URI']; $spam_keywords = [ 'spamword1', 'spamword2', 'spamword3' // WILL BE A LOT MORE HERE ]; function checkKeywords($uri, $keywords) { $foundKeywords = array(); //Create array to hold found keywords foreach ($keywords as $keyword) { //Iterate over list of keywords if (stripos($uri, $keyword) !== false) { //Check if keyword is in $uri $foundKeywords[] = $keyword; //Add found keyword to array } } //Return found keywords return $foundKeywords; } //Check for keywords $foundKeywords = checkKeywords($uri, $spam_keywords); //Check if results are not empty if (!empty($foundKeywords)) { //Keywords were found - display them echo "<p>The following Keywords were found:" . implode(', ', $foundKeywords) . "</p>"; } else { //No keywords found echo "keywords not found"; }

I get that you're saving yourself some effort, but when you tell people "I asked a question somewhere else, go see what it was and try to answer" it's typically going to be taken as an insult. But I'll answer anyway because it doesn't look very good. According to what I'm seeing in the Docker Hub page, there is no simple upgrade path once the PHP version is no longer supported. Normal Docker practices would allow it, but this image isn't set up to follow normal Docker practices. So you'll have to go into the container itself and update it manually - like if it was an actual computer running Alpine Linux and you needed to upgrade it. You can look around for instructions on how to do that. Which means you should reconsider how this all works. For example, you could convert your existing installation to the "Static image" one that's described in the docs... though you'll have to reverse-engineer some of that process in order to preserve the details of your existing setup. But once that process is done and you've converted to a static deployment, future upgrades seem like they would be as simple as updating image versions in your docker-compose. (And you would then do all updates that way - not from within WP itself.)

yq probably won't work since the lines are commented out, which more or less leaves you with the standard find-and-replace tactics using sed. Like sed -i '/#cluster.name: MyCluster/s/#//g' filename.yaml

CodeIgniter 4 is leaps and bounds better than 3 - it was re-written from scratch to make use of modern development patterns. That being said, as gizmola mentioned it was still pretty bare-bones last time I used it, whereas Laravel is fully featured. Some may say too fully featured, but it's optimized very well and has a large and active ecosystem. For instance, if you don't want to pay for Pusher they just released Reverb, which is a Laravel-specific websocket package that isn't the easiest thing to set up, but once you do it's quite good. It has a robust queue system that allows the developer to do a lot of work asynchronously right out of the box. The learning curve is steep, but most frameworks have that problem. Just know going in that there is a lot of magic to Laravel, so making sure you're comfortable reading source code is important (although the docs are better than most, IMO). I've not used Symfony specifically but - again as gizmola says - Laravel is built heavily on Symfony components. Best bet is to try building something smallish in all three and see which sings to you. Personally, even recognizing that Laravel has plenty of warts I prefer to work in it (though that may be Stockholm Syndrome as I've been working with it almost exclusively for about 6 years now).

As an aside, you should evaluate re-building with Symfony. Laravel and Symfony are by far the best PHP frameworks at this point, and have many similarities. Both frameworks are Dependency Injection frameworks, so you want to spend some time getting comfortable with what DI is, and how you would utilize that pattern with the code you write. It also allows you to make use of things like autowiring and lazy loading (intelligently loading of classes when needed rather than kitchen sink loading of classes you might never use in a request) which will be handled by the framework for you, so long as you understand it. Codeigniter is a fine, but very old and basic framework that is bare and simple in complexity. Depending on the features of the app you may have had to write your own code to implement features that either of these frameworks may have provided support for. They are also built upon component libraries so there is a bit of mixing and matching you'll see, as for example some Laravel developers prefer Symfony's twig templating system, and will integrate that instead of Laravel's Blade. I personally prefer the Doctrine ORM for working with relational database code, as it's designed around the "Data Mapper" pattern, rather than Active Record, which is what Laravel Eloquent uses. In either case, CI doesn't come with an ORM so that is new territory. You don't have to convert to the use of an ORM, but in most cases you will want to. Scalability is achieved through architecture. No monolithic framework is scalable. With that said you have to make decisions as to how you will achieve scalability. As both Symfony and Laravel have been used to develop high traffic consumer sites and applications that are architected to support high transaction rates and the features you listed, there is ample support for implementing scalable architecture. On the flip side, experience in these areas is harder to come by, and entire books have been written. These days scalability of required infrastructure typically involves the expertise of DevOps engineers who along with developers are creating deployment infrastructure and features that allow for this scalability. For example, one of the first issues one can hit (outside of an uncached database that has too much data and too many queries hitting it) is having enough frontend application servers to handle the request load. So you need frontend application code that was designed to be 1 - of - N, and that was not designed or configured with a monolithic configuration. The simplest example of this is the question of session. Using PHP sessions, the session files will by default be written to disk. When user requests exceed the capacity of a single server what do you do? Let's say you add a second server now. This requires some form of load balancing or reverse proxying. How do you handle sessions then? There are a variety of approaches you can take architecturally. The code will likely be the same, but configuration may need to be different to allow for scalability. As for security, both Symfony and Laravel have been built with security in mind, and have features that encourage and support it. With that said, one can always go around best practices or features that enable additional security. If however, you work with what the frameworks provide you have a solid foundation. Chat: Can be done different ways, but HTTP is inherently not designed for long running persistent socket connections. Websockets is the leading alternative to support this, but it requires separate infrastructure. For that reason, Platform as a service PAAS companies like Pusher exist to support this. You could also self host something like a Mercure server (see https://mercure.rocks/) or you could use a company like Pusher (https://pusher.com/websockets/). Both Symfony and Laravel have community support options (component libraries) that make working with these websocket wrapper platforms, and have been used by many companies. There is also Twilio which provides both text messaging and general messaging api's that can be used as well as telephony features like masked calling. I feel like I'm getting far afield here, but I've worked on several projects for a consumer service company that made extensive use of Twilio, although that company was profitable and well funded, so the inherent costs were the subject of contract negotiations and not a concern at the time. Pusher and hosted Mercure both have free development tiers and in my opinion are reasonably priced when you consider the costs you would incur to self host this additional infrastructure, so that is what I would recommend. This should also tell you a lot about the possibility and the need for architectural planning and building to it. Again I can only say that Symfony and Laravel have been used to create services and the backend for applications that serve large numbers of simultaneous users, while offering asynchronous processing of messaging, email etc. Yes, although Symfony has a release process that offers LTS. See https://symfony.com/doc/current/contributing/community/releases.html With Laravel the window is 12 months (24 for security releases) so to be completely supported, you are looking at a fairly constant cycle of at very least minor version upgrades. See https://laravelversions.com/en My last comment on Laravel: What many people like about Laravel is that it has facades. Initially facades are attractive to new developers because they are "magical" and appear to make things simple. They are a foundation for Laravel and probably one of the reasons it gained rapid popularity. Essentially, what laravel facades do is add glue that makes any class look like its public methods are static, when in fact, this is an illusion and glue code that is part of Laravel. You can read more about Facades here: https://laravel.com/docs/11.x/facades As I mentioned earlier, Laravel and Symfony are both Dependency Injection frameworks, so Facades are something different, as they plainly discuss in their documentation. In practical use, facades and associated "helper" functions are ways to just use services that are built into Laravel. So it encourages one not to use Dependency Injection, which makes the code less maintainable, and also harder to write tests for because you can't mock the parameters. If you read the facades page you'll notice that their answer for this is that facades have a built-in method to get around this issue, so you basically have to write a test that works around the way you would have written the test if you just used the DI pattern and a constructor parameter in the first place. So in their documentation they have this example where a Route handler (also a facade being used here, but nevermind that) is in the first example, returrning a Response object using the json() method, and then an example using this global "helper" function "response()->json". use Illuminate\Support\Facades\Response; Route::get('/users', function () { return Response::json([ // ... ]); }); Route::get('/users', function () { return response()->json([ // ... ]); }); So whipping something out fast, I guess might appeal to someone, because they don't need to understand the details of how this all works, although of course, every feature like this comes with a runtime cost. But the longer term question that has to be asked is: when you can write standard DI code, and just not use facades or helpers, and that makes understanding code easier, and writing tests easier, why not do that instead. Since Symfony doesn't have facades, it is not something you ever would concern yourself with, although you can just use Laravel and inject the parameters. The reality is that if you go with Laravel, you will be encouraged through the documentation to make use of facades and or helper functions, and you should know that going into the project.

Thanks for letting us know.