Leaderboard
Popular Content
Showing content with the highest reputation on 10/24/2020 in all areas
-
Does anybody else feel like the login screen could use a revamp? While it might not be the most important thing in the world, first impressions count. On large(r) screens the login form seems to get lost in the upper third. The rest of the admin looks a lot cleaner and more deliberate. A few tweaks would go a long way in making the login screen work on all device sizes. Those are two custom styles I've been adding to my sites lately, one PW-branded and one not. No markup changes needed, just CSS. This second one borrows heavily from Twill's login screen. The floating environment label has turned out to be really useful to see at a glance if one is editing on staging or live. Not sure if there's a way to make this 100% core compatible.4 points
-
ProcessWire 3.0.168 contains 16 commits relative to 3.0.167 and is focused largely on minor issue fixes and improvements, with 8 reported issues fixed and 8 improvements. This week the larger focus was on the ProcessWire modules site. I finally got some serious work done with that this week, and am building good momentum. The front-end of the modules site is being moved into the main ProcessWire site, though the back-end will remain an independent ProcessWire installation. The main ProcessWire site uses multi-instance support to boot the modules site whenever it needs to pull or update data from it. Here's a simplified example: $site = new ProcessWire("/htdocs/modules.processwire.com/"); $items = $site->pages->find("template=module, sort=-created, limit=10"); echo $items->each("<li><a href='/module/{name}/'>{title}</a></li>"); The nice thing is that I’m finding performance to be excellent here, about the same as if I weren’t booting multiple ProcessWire installations. I’m sure there’s some overhead if measured, but it sure isn’t felt. One thing I did learn is that when it comes to pagination, if you want your separately booted site to be aware of the current site’s pagination, you need to tell it the page number. Otherwise the bit of code above will always return the first 10 modules, regardless of pagination number. It seems obvious now, but it took me a minute to realize why. So if pagination is being supported, you'd add this before the $site->pages->find(...) in the example above: $site->input->setPageNum($input->pageNum); For front-end work like this, it's also a good idea to tell your booted site if you want output formatting enabled, so that page titles and such come out entity encoded, for example: $site->pages->setOutputFormatting(true); ...or if you prefer the shorter alias: $site->pages->of(true); One big difference with the new modules directory is on the management side for module authors. This part is powered by LoginRegisterPro so that now you have an account to manage all of your modules within. Further, you have the option of maintaining your module author public profile and protecting your account with PW’s two-factor authentication. That's just for starters. All of this is in the early stages of development, but if the development schedule remains as planned, I’ll be following up with more info over the coming weeks, in addition to the regular core and module updates. Have a great weekend!4 points
-
Here's a hook (add to /site/ready.php) that allows you to set a description and your own help notes for each checkbox in the Status field: // Add some extra notes to the options in the Status field of Page Edit $wire->addHookAfter('ProcessPageEdit::buildFormSettings', function(HookEvent $event) { /** @var InputfieldWrapper $form */ $form = $event->return; $status = $form->getChildByName('status'); if(!$status) return; // Add a description to the field if you like $status->description = 'You can apply various statuses to this page to control its visibility and editability.'; $options = $status->options; // Define your notes here $notes = [ 2048 => 'Peter Piper picked a peck of pickled peppers.', // Unpublished 1024 => 'How much wood would a woodchuck chuck, if a woodchuck could chuck wood?', // Hidden 4 => 'She sells sea shells by the seashore.', // Locked ]; foreach($options as $key => $value) { if(!isset($notes[$key])) continue; $options[$key] .= "[br]{$notes[$key]}[br] "; } $status->options = $options; });3 points
-
yep, it stores them as regular pageimage variations and you can remove them by hand when opening "variations" in an image inputfield. You also can remove them by calling the core method $image->removeVariations(), but this also removes other variations like the adminThumbnail and maybe variations from CKE-fields and others. Therefore there is the pim2Load('ALIAS')->removePimVariations(), so that you can remove only the pimvariations for that specific alias name. If you are in experimental mode with pim2, you have the option to load it with a second param (called $forceRecreation in the API page) that automatically refreshes this single variation. If you use a specific options array as second param with pim2Load(), you can set $forceRecreation as third param. ? $image->pim2Load('wm', true)-> ...1 point
-
Thanks for your suggestions Teppo. To keep things simple, I went with just creating /var/cpanel/php/sessions/ea-php72 on my dev server (Ubuntu via WSL2), as well as ea-php73, ea-php71, ea-php70, ea-php80 just to be future proof. I removed the wrapping <If "%{HTTP_HOST} == 'www.my-production-domain.com'">...</If> conditional as well. It works perfectly. I had to make sure to give those directories the correct ownership (www-data:www-data in my case): sudo chown -R www-data:www-data /var/cpanel1 point
-
See the API post: $image->pim2Load('wm')->removePimVariations() should do it, though you'd want to make sure that you don't leave this code in place longer than you need it (probably won't do a lot of harm, but it'd be pointless). I'm not sure if pim stores the images as regular variations, but if it does, you can also remove them by hand from the admin (edit the image and you should see variations somewhere in the GUI). I wouldn't worry too much about those old variations, though. Most likely you haven't generated so many of them that they'd take considerable space on the disk, and anyone opening them accidentally is also quite unlikely.1 point
-
@teppo and that's done it!! Thank you. Weirdly when I tested the output of $page->getUnformatted('title') earlier with an echo I got no output, but now I am. Thank you again for your help, time, expertise and all. Being the weekend too! ?1 point
-
Right — seems like it's an issue with formatting, i.e. single quote gets escaped (converted to HTML entity). Try $sanitizer->selectorValue($page->getUnformatted('title')) instead, that should work.1 point
-
To my best knowledge there's no easy way around this, except for not using the MultiPHP Manager in the first place... which might not be an option for your use case ? Some (possibly awful) ideas you could try: Perhaps you could disable overriding PHP settings via htaccess on your dev server by defining more restrictive AllowOverride option in your virtual host? AllowOverride also works on a per-directory basis, so I believe you could disable these for this particular site only, in case you're hosting multiple sites on this environment. How 'bout manually creating matching directory (/var/cpanel/php/sessions/ea-php72) on your dev server for storing sessions for this site? It sounds to me like cPanel will make these modifications automatically. If it also remembers all values somehow (in database or some other config file) and then repopulates them on first request or something, perhaps you could manage just one version and let cPanel work it's magic automatically after deployment? Not sure if that's exactly how it works, and whether that's feasible in the first place also depends on what your dev/deployment workflow looks like... ? It'd be great if the folks at cPanel provided some way to decide where specifically these rules should go, but I guess that'd be a new feature request. Based on some googling it also looks like when they introduced the automatic modification part, they broke quite a few sites in the process. Not cool ?1 point
-
Thanks for setting this up! ? Of course this won't be a problem for everyone, but personally I avoid direct downloads. Here are a few reasons: With direct downloads I can't easily validate the package to make sure it is indeed the original one in case the server has been compromised or something along those lines — which of course is something that shouldn't happen, but in this regard I have more trust in GitHub than individual hosting providers / server maintainers. GitHub (/ Git) allows me to see and track the full change history in case something doesn't work. This way it's easier to track what change caused the problem, why it was made (commit message), and (assuming that the module author is somewhat active on GitHub) file an issue or even submit a fixed version for approval. Finally, I prefer to handle updates via either Git or Composer. It would be too much work to keep track of different blogs for individual modules, let alone download the module package every now and then to see if it has changed . GitHub makes this trivial (periodic git fetch or git pull is quite enough). No pressure, but big thumbs up from here for always uploading modules to GitHub ??1 point