Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 11/28/2024 in all areas

  1. Awesome! What about RockMPP (RockMultiPurposePicker) or RockPickAnything? Or just RockPicker.
    2 points
  2. Actually the name of this module is totally wrong, because you can not only use it to pick colours, you can also use it for example to pick layout positions - here as an example in a RockPageBuilder block: The code to achieve this: $picker->setColors('site_overlayposition', [ 'top-left' => [ '<svg ...></svg>', 'Oben Links', ], ... ]);
    2 points
  3. Hello @benbyf, yes I include the wire folder in my repo. I am no Git expert but looked how .gitignore files for other CMS are recommended here in this popular collection on GitHub: https://github.com/github/gitignore Most other CMS like WordPress, TYPO3, Joomla!, Kirby etc. recommend to add Git in the root folder and track the core folders. For WordPress now it is recommended to optionally ignore the core folders, but at the time I was looking that wasn't the case. Here are my pros and cons for adding Git in the root folder: Pros One repo for the complete website You can clone the complete website with one command Sometimes there are important files in the root, like f.e. Service Workers or Composer packages You know which version of the CMS is used You can use new functions of the CMS without keeping track of the CMS version somewhere else If someone modifies or hacks your wire folder, you could see the differences Cons More commits Larger repo But ProcessWire gets a master version only once or twice a year, so the cons are for me not noticeable. Of course as I said I am no Git expert and everybody is free to use Git how they want. 😀 Regards, Andreas
    2 points
  4. Hi all (again)! I'm continuing to create buttons and have created a Github repo for all of the images. I've since added another after updating the initial post above. The repo will always have the latest preview, and new buttons. As mentioned above, the latest push contains cleanup and consistency for existing buttons as well as several new ones. Download from or fork the Builder Buttons Github repository Enjoy!
    1 point
  5. Hi @Velox111, Welcome to the forums! Sorry about this. Thanks for reporting. The issue looks like the class loader is not passing options and it needs to. I know where to look but please send over just in case. Thanks.
    1 point
  6. Deprecation warnings say, that it potentially may not be ready for 8.4.2 or 8.4.3 or any other further version. But in my understanding, it is ready for PHP 8.4.0 and 8.4.1. 🙂 If the deprecation warnings bother you, you can disable showing only those messages with a call of PHPs set_error_handler(): /** OWN ERROR HANDLER FOR DEPRECATION NOTES ************************************/ function myLocalDevDeprecationErrorHandler($errno, $errstr, $errfile, $errline) { return true; // true | false = suppress further processing } // preceed the callback function name with the PW namespace, // and define the error types that should passed to the function set_error_handler('ProcessWire\myLocalDevDeprecationErrorHandler', E_DEPRECATED); /** OWN ERROR HANDLER FOR DEPRECATION NOTES ************************************/ I often use this directly in site/config-dev.php, when I want to collect them, but only show them collected at the end of pages in dev local. /** OWN ERROR HANDLER FOR DEPRECATION NOTES ************************************/ function myLocalDevDeprecationErrorHandler($errno, $errstr, $errfile, $errline) { // CHECK / CREATE COLLECTION CONTAINER if (!isset($GLOBALS['DEPRECATION_WARNINGS_BAG'])) { $GLOBALS['DEPRECATION_WARNINGS_BAG'] = []; } if (!is_array($GLOBALS['DEPRECATION_WARNINGS_BAG'])) { $GLOBALS['DEPRECATION_WARNINGS_BAG'] = []; } // DO NOT SHOW THIS KNOWN THIRD PARTY ONES : $hideThisOnes = [ //'FileCompiler', 'Duplicator', 'ProcessCustomUploadNames', ]; foreach($hideThisOnes as $item) { if (preg_match("/{$item}/", $errfile)) return true; } // ADD IT TO THE COLLECTION $GLOBALS['DEPRECATION_WARNINGS_BAG'][] = [$errfile, $errline, $errstr]; return true; // true | false = suppress further processing } // preceed the callback function name with the PW namespace, // and define the error types that should passed to the function set_error_handler('ProcessWire\myLocalDevDeprecationErrorHandler', E_DEPRECATED); /** OWN ERROR HANDLER FOR DEPRECATION NOTES ************************************/
    1 point
  7. Thanks @Robin S, this hook did the trick 🙌
    1 point
  8. https://github.com/processwire/processwire-issues/issues/2000
    1 point
  9. I use Git in the project root as well, and only put things in .gitignore I really don't want to have in that repo. Best case scenario is that I have the full project, besides database dumps, in my repo. # .gitignore .ddev/ site/assets/backups/ site/assets/cache/ site/assets/logs/ site/assets/ProCache-* site/assets/pwpc/ site/assets/sessions/ site/config-dev.php Database dumps are a thing of its own. Managed projects are backed up quite often, long time projects with not that many updates will be backed up once every 3 months. From un-Managed projects I keep only the latest version I worked on - most of the time the release day or when something was updated.
    1 point
  10. To do this I think you'll have to hook the rendering of the repeater item, which is a fieldset: $wire->addHookBefore('InputfieldFieldset(name^=repeater_item)::render', function(HookEvent $event) { $inputfield = $event->object; $inputfield->label = $event->wire()->sanitizer->unentities($inputfield->label); });
    1 point
  11. Hey @bernhard, I usually use a setup where a production website and a staging website are on the same file system. I love the filesOnDemand feature because it saves a lot of disk space for the local development system and also for the staging system, but it is also very slow on sites with a lot of assets. I think it would be great to be able to specify a local path instead of a URL to a website (or in addition). Ideally, if a local path is specified, then if a file or variation (for images) is not present, filesOnDemand would first search via the specified alternate path to see if the assets are present and deliver them (without downloading or copying) directly. The assets folder of the staging system would therefore only grow when a user creates new pages or makes changes to existing ones, but not when content that exists in the production system (on the same file system) is to be accessed. I assume that filesOnDemand has so far been developed primarily for downloading assets that are only available remotely. But perhaps it could also cover this application purpose - or a new feature with a different name? Cheers, Flo
    1 point
  12. Have a look at Contabo, I am very satisfied and they are cheap.
    1 point
  13. Hi All I've managed to upgrade to 010, all was working great, however when accessing the payment providers within the shop settings I get an ArgumentCountError. Is that something I've missed? I've reverted back to 009 and can now access the payment providers. If you need the full call stack please let me know and I can send that over. Kind regards
    1 point
  14. You could use the Pages::saved hook to format a page's name. You can find a example of code here :
    1 point
  15. After a previous request for Webp support (6 years ago, times flies…) that Horst and Ryan kindly introduced in PW 3.0.132, I'm back with another request for a new image file format, AVIF, which has landed in almost all browsers. I'm actually surprised no one here in the PW community has been asking for AVIF support in ProcessWire as it seems to be provide much more consistent gains in compression and greater relative quality over Webp, and of course over good old JPEG. My experience using it definitely confirms this. I've been using Cloudinary to serve AVIF images to the browsers that support it, but of course I'd rather not use a third-party service, and use it natively in ProcessWire. Imagemagick supports AVIF if I'm not mistaken. Anyone else is interested?
    1 point
×
×
  • Create New...