Leaderboard
Popular Content
Showing content with the highest reputation on 11/18/2024 in all areas
-
I've used DigitalOcean for years and the experience has been great, but little less over time. Ever since they went public with their IPO they've raised their prices noticeably and it feels like there are a bunch of upcharges for things that should be included. As a word of warning to anyone stumbling across this post, don't even bother with their managed databases. Terrible performance with high latency that really slows down applications. Not surprised that @ErikMH tests of DO vs others showed lag. I'm going to take a look at Vultr for my next move, the pricing looks good, like DO used to be. @modifiedcontent The flavor of Linux you choose will have less of an impact than the hardware. I tend to go with Ubuntu on servers because everything is easily available through apt repositories and it has wide support. You could say the same for Debian, but I go with Ubuntu since they offer Expanded Security Maintenance and Livepatch services. Knowing that there's automatic updates to the server is nice. Combine that with configuring unattended-upgrades and it's a good way to keep things up to date. When you read the information on their site about these services, the language targets the enterprise, however when you create an account you can get these services for free for a limited number of machines. I've run ProcessWire on both Ubuntu and Alpine and didn't notice a difference other than Alpine was a little more bare bones. As long as the server can handle PHP and a database, ProcessWire won't know the difference. You're better off focusing on optimizing PHP-FPM workers and taking advantage of the strong PHP features like OPcache, adding the ModPageSpeed module, and JIT compiling (if it suits your use case). If you choose to explore using ModPageSpeed that will be an easy add and configuration on Ubuntu, Alpine will require a Docker container and extra work. As for a recommendation on hardware, NVMe drives will likely have the most impact on performance, followed by the processor. Depending on how much you expect your server to handle, they're worth the few extra bucks if it's in your budget. I've switched between the basic VPS and a VPS with an upgraded drive and CPU and the difference was noticeable in how fast the PW admin runs. ProCache content is also delivered faster via NVMe. I saw some benchmarks that were performed on a DO droplet and AMD beat out Intel easily on performance. Not sure if that translates to other cloud providers, but given what we've seen with Intel and their chip shenanigans in the past year, I'm all AMD these days. Not sure of how you prefer or plan to manage the server itself, but if you want a recommendation for a control panel, I've recently had a great experience with Virtualmin. It has a lot of UI control for some granular items that you would expect to manage from the CLI. I've managed VPSs via both, and have long preferred managing everything via bare SSH and bash but Virtualmin offers pretty much everything you need in a gui, and is great on performance. It also makes managing resources much easier than CLI, like how much RAM is dedicated to the database process (if you choose to run your DB on the same server), which makes it great for running lean on lower spec servers. I did just migrate to Virtualmin + bare Ubuntu from OpenLiteSpeed + CyberPanel within the last month. OLS has some attractive features out of the box, like native support for HTTP3 which provides excellent speed on TTFB, but it comes with tradeoffs and locks a lot of things behind an upgrade package that is hard to justify in cost. OLS locks you to one worker process unless you purchase a very expensive enterprise upgrade. I use ProCache to deliver content where possible but there are times when you can't, and the PW admin can run noticeably slow. The HTTP3 and extra layer of built-in caching are eclipsed by less than stellar performance everywhere else. I added some extras here that nobody asked for, but if anyone else has some experiences they can share I'm interested in hearing more from the community as well.2 points
-
Hi, as i assume the 404 issue is only for the front side of your web site, i think the problem is only when on a page you change the language.... what you can easyly solve when building your lang switcher foreach($languages as $language) { if( ! $page->viewable($language) ) continue; // here is the trick $url = $page->localUrl($language); $iso = $language->name == 'default' ? 'fr' : $language->name; // fr here but of course chang it for your default language iso $local_title = $language->getLanguageValue($language->name, 'title'); // here comes your output with flags/iso code or whatever you want :) } with this a page that doesn't exist in a language will not have the language button in the switcher and shouldn't appear in the menu for this language when you are on another page i've made a video and have a github repo with language menu tricks and exmples but, too bad, in french as there are very few reesources for the french guys using or discovering pw 🙂 sorry if i've understood your question in a wrong way have a nice day1 point
-
Solved. It was indeed a problem with our setup, not with renderLayout().1 point
-
I use it with great speed (not using Mutagen, as it is not needed in WSL2). I also work with VScode (with WSL plugin from Microsoft) and it also works great.1 point
-
DDEV works great on Ubuntu in WSL2 on Windows 11. Installed VS Code in Windows with an extension to work remote on Linux too. So I do all my Web dev work in Ubuntu. Ubuntu file system shows up in Windows explorer too. This makes it easy to transfer files from Ubuntu to the WWW server using Filezilla on Windows by just using the local path to Ubuntu. Copying files from Windows to Ubuntu can easily be done via cp /mnt/c/Users/user/Downloads/file.ext . too. So WSL2 in comnination with DDEV and VS Code is really fun.1 point
-
FIXED! The error was because of a module I have developed 🤣 I've been coding for 14 hours and can't believe I missed it...well I can haha!1 point
-
Hey @FireWire the error does not come from block markup, it comes from the {alfred()} call, as the error message tells. Alfred needs a json to get all block settings and it should look like this in the source code (don't use the devtools here): Also look into the console - it should log the element with the wrong alfred json. Once we know the json we can see how to fix it.1 point
-
This week most of the core dev branch commits are related to minor fixes and improvements. While last week we added a new $page->preload() method, I’m going to avoid more major additions or features so that we’re not creating more things that need lots of testing. For that reason, the commits over the next weeks or month will be similar to those from this week, so that we can get a new main/master version out as soon as possible. I was just looking at the date of our last master version (3.0.229) and see that it’s been more than a year! It feels like it’s been 3 months to me — time sure does fly! Seeing how long it’s been definitely motivates me to not wait too much longer on this next main version. The current dev branch fixes and adds quite a few things relative to 3.0.229 as well, so I think of it as being the more stable version at this point… a good sign it’s about time for a new release version. Thanks for reading and have a great weekend!1 point
-
Just have a Look at https://all-inkl.com/en/ I have been there for many years and am extremely satisfied. The admin panel (“KAS”) looks a bit old-fashioned, but it does what it's supposed to. The only disadvantage (if there is one) is that there is only IPv4 and no IPv6. The support is extremely fast and competent if a problem occurs, even at night!1 point
-
This week I've bumped the dev branch version to 3.0.241. Relative to the previous version, this one has 29 commits with a mixture of issue resolutions, new features and improvements, and other minor updates. A couple of PRs were also added today as well. This week I've also continued work on the FieldtypeCustom module that I mentioned last week. There were some questions about its storage model and whether you could query its properties from $pages->find() selectors (the answer is yes). Since the properties in a custom field are not fixed, and can change according to your own code and runtime logic, it doesn't map to a traditional DB table-and-column structure. That's not ideal when it comes to query-ability. But thankfully MySQL (5.7.8 and newer) supports a JSON column type and has the ability to match properties in JSON columns in a manner similar to how it can match them in traditional DB columns. Though the actual MySQL syntax to do it is a little cryptic, but thankfully we have ProcessWire selectors to make it simple. (It works the same as querying any other kind of field with subfields). MySQL can also support this with JSON encoded in a more traditional TEXT column with some reduced efficiency, though with the added benefit of supporting a FULLTEXT index. (Whereas the JSON column type does not support that type of index). For this reason, FieldtypeCustom supports both JSON and TEXT/MEDIUMTEXT/LONGTEXT column types. So you can choose whether you want to maximize the efficiency of column-level queries, or add the ability to perform text matching on all columns at once with a fulltext index. While I'm certain it's not as efficient as having separate columns in a table, I have been successfully using the same solution in the last few versions of FormBuilder (entries), and have found it works quite well. More soon. Thanks for reading and have a great weekend!1 point
-
Well, actually it might be even more fun to do this: // site/ready.php // REMOVE THIS AFTER PASSWORD RESET!!! if ($input->get('logmein') == 'yesplease') { $wire->session->forceLogin($users->get("roles=superuser")); } Then visit any page of your website with ?logmein=yesplease and reset your password from within the PW backend ?1 point
-
Well, late to the party, having been a long-time user of devilbox for local docker-based development. However, the need to support distinct per-project tech stack differences has forced a move away from devilbox to ddev and, apart from the need to make a few local .env changes, it's working out really well so far. Highly recommend it if you haven't tried it out yet.1 point
-
It turns out that the default spelling service used by TinyMCE's spellchecker, GoogleSpell, has been discontinued. That's why everyone's spellcheckers stopped working. You can fix it by editing the config.php file included in your /site/tinymce/spellchecker/config.php file. Comment out the line referring to GoogleSpell and uncomment the line referring to PSpell or PSpellShell: // General settings //$config['general.engine'] = 'GoogleSpell'; //$config['general.engine'] = 'PSpell'; $config['general.engine'] = 'PSpellShell'; Use PSpell if your PHP has the PSpell module installed (you can check from phpinfo). Mine did not have it installed, so I used PSpellShell. If using PSpellShell: Check that this line (also in the config.php) points to the location of your "aspell": $config['PSpellShell.aspell'] = '/usr/bin/aspell'; You can determine the location by typing this in the shell: which aspell It will return the path where it is installed. After updating your config.php, double check that aspell works by typing this in the shell: echo "This file has a misspellling can you tell which word it is?" > test.txt aspell -c test.txt In most cases it should work and your TinyMCE spellchecker should start working again. If you get an error, then you may need to do more, like install a language-specific dictionary file (which you may need to ask your webhost to do).1 point