gizmola

You don't need that package (php8.2-xml). XML support is already installed by default in the base 8.2 image.

Did you try to remove those lines and if so, since they were redundant and problematic, what result did you have? You could also provide the Dockerfile you are using, which would allow others to recreate your experience.

Install via apt should take care of installation of the extension, so I don't think you need these: && docker-php-ext-install php8.2-xml \ && docker-php-ext-enable php8.2-xml

Can you put your code in a code block in the future? Reading/looking at double spaced code without proper indentation or color syntax highlighting wastes everyone's time and effort and greatly decreases the final results. Notice @Moorcam helpful reply to you where he put an offending line into a proper block where the issue is easy to identify.

Most people use Cloudflare for the proxy and edge caching. DNS registration is a commodity. There are plenty of other registrars like Cheapdomains you could look at purely for DNS registration. You can always make a free Cloudflare account and explore their offerings. They provide a lot of useful features in their free account.

It does sound like mac_gyver had the solution. I'm going to assume that your solution was something like: "SELECT * FROM descriptions WHERE `item` IN ('rolls', 'baguettes', 'croissant')". You should have an index on the 'item' column as well, if you don't. I'm a stickler for data consistency, and perhaps this was just an arbitrary example you created, but if you are going to use plurals (rolls, baguettes) then all of these should be pluralized, and you shouldn't have singulars like 'croissant' or 'donut'. My main comment, is that there is no benefit to using LIKE unless you are using wildcards. LIKE works fine when you actually need it as in: WHERE name LIKE "sm%" finding "Smith", "Smith Jr." and "Smeely", etc. If however, you attempt to find a substring as in: WHERE address LIKE "%main$" This defeats the ability of the database to use indexing. The queries will work, but assuming this is the primary criteria, will need to tablescan the entire table looking for addresses that have 'main' somewhere in them. If the dataset is relatively small, these types of "% ... %" or "% ..." queries are acceptable, but if the dataset is large, you may find you are having significant issues.

This is typically where a pub-sub solution helps. As you mentioned, the old school ways of hacking ajax to do this involved polling. Websockets were introduced to provide a better solution, but have the downsides of being an entirely different protocol, requiring a websocket server. Some people get somewhat around this by utilizing a websocket PAAS, at least for me, the best known of which is Pusher. When I last utilized it, the economics were very reasonable, and for a site with known relatively low traffic there's a free tier. There are alternatives, but if you really need bi-directional communication, websockets are the best solution. If however, this is simply a "push" requirement to "publish" to the "subscribers" then there is now a standard feature you can use known as "server sent events (SSE)". Support for this is very good at this juncture as you can see here: https://caniuse.com/eventsource SSE sounds tailor made to solve your problem here, as your updates can be pushed out to all your clients. Here's the MDN page for the feature. I know of a few php libraries that that have all the serverside plumbing taken care of: https://github.com/hhxsv5/php-sse https://github.com/clue/php-sse-react I will caution that there is no free lunch. SSE's are better than (long) polled ajax, but they still require a dedicated socket connection per client. Anything like this requires significantly more resources, but if it is an essential feature of your application, SSE could be tailor made for what you want, although you should also evaluate using Pusher as an alternative.

I don't know that there is a best book. MySQL has been around for a long time, and due to its origin as an open source database with a GPL license, as well as it's relatively unique pluggable engine, it has been extended and forked. Oracle acquired MySQL and at that point, the original MySQL developer forked the code and created MariaDB. Percona also has a fork. So there are now a variety of flavors of "MySQL" with different features and versioning. Whatever book or resource you might get, you want to be sure it is relatively recent and contains information based on the most recent MySQL releases. If your focus is administration, there is a lot of general use content in that book. A book that is more focused on administration like this one might be better. To be clear, I have no experience with any of these books. If you have used a Udemy account, and you are patient, you can routinely license courses for under $10 US. That might be a cheaper way to get similar training. You might consider starting with youtube and looking for other online resources, and combine that with use of the official MySQL docker instance to experiment and learn.

The code Psycho provided is a fairly standard way of solving this problem. Notice how he made use of the empty() function. Empty works well here, because it will return false if it receives an empty array, and true for anything else.

Certainly you are pushing the limits on a workstation with a processor that was released 12+ years ago. With that said, my guess is that you might have limited memory available? Rather than trying to use Kubernetes, you should try this image: https://github.com/deviantony/docker-elk It comes with a docker-compose.yaml file, so you basically just "docker compose up". They indicate that you need 1.5gb available, which is not an unusually large amount of memory, considering you are running 3 orchestrated containers. If your workstation is highly constrained on memory, then virtualization of any kind is probably going to be somewhat slow and potentially not very enjoyable. With that said, I did an awful lot of work in vm's using vmware workstation, virtualbox, vagrants etc, on machines back in the i5/i7 era.

I don't see an issue, based on what you've shown. The only other thing I can think is that the file /home/cycles/opcache-gui/opcache_blacklist.txt has permissions that don't allow it to be read by the php-fpm process user. Just to be clear, this simple test script is in a webpage and not just a script run from CLI php, correct? Opcache is basically useless for php cli because the php process that includes the cache is disposed of each time. I'd be interested to know what you currently have in your opcache_blacklist.txt file, and I'd like to have you also add a call to https://www.php.net/manual/en/function.opcache-get-status.php.

When you are using opcache gui, does the "Ignored files" tab appear? What if anything is in that tab? For entire directories you most certainly need a glob like this: /home/cycles/public_html/wp-admin/* With that said, it appears you are trying to make the blacklist file setting in an .htaccess? The blacklist file is an INI SYSTEM parameter which means it can only be set in the php.ini or httpd.conf. A page with phpinfo(); would help you verify the settings.

I would agree unless there is some objective you have in mind that javascript would facilitate that a plain html link would not. However, since you are on the topic, one often neglected aspect of links is the rel attribute. Of particular interest are "nofollow", "ugc" and "canonical". There's some solid information about these on this page. Let me just say that they are very important to search engines and SEO. I'll start with "canonical". You might want to refer to this google page on the issue, and possible solutions. Let's say that you have a site where you have a shoe product, and the main way to get to that product page is to use the direct product url: <a href="/product/75">Rockport Men's Wingtip shoe</a> Let's also assume that you have categories and search in your site. You might have a category page for "shoes" like /category/shoes And when you can get to the same detail shoe page with a direct product link as in <a href="/category/shoes/75">Rockport Men's Wingtip shoe</a> The search engine crawls your site and unless you took steps to stop it, will crawl the categories pages and find your wingtips shoe page, and finding it in the /product catalog page using /product/75 page which is exactly the same content. Search engines can thus downgrade your resulting score, on the basis of the duplicate content. One way to fix this is to make sure that the product page link uses the rel="canonical" attribute. <a href="/product/75" rel="canonical">Rockport Men's Wingtip shoe</a>

Yes well that is often both a system administration/devops problem and potentially something you outsource (log analysis). There are an incredible number of SAAS companies that offer log processing and analysis products. This general area of interest is often referred to as "telemetry", which can cover things like error/exception analysis. Is your company using any of these products or services? There are tools/platforms like Grafana, Splunk or New Relic you should investigate, just as a starting point. Grafana is a service built upon open source components, so I'd suggest you start by making a free Grafana cloud account and explore the product through their demos, sandboxes and tutorials page. Often these product provide a platform to develop reporting, dashboards and analysis. If your company is not doing that, it is a great opportunity for you to lead them to that solution. There are also options to self host you can explore as in for example the ELK stack ( Elasticsearch, Logstash, and Kibana).

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.