Leaderboard

I've got some core updates in progress but nothing major committed yet, so we'll save that for next week. But I wanted to briefly tell you about a module I'm working on here, which I plan to eventually put in core. I built it for some needs I've had here, but it will first be released in ProDrafts (so ProDrafts may start using its API), and in ProDevTools too, since it is also a developer tool. It's a snapshot versioning system for pages, but more of an API tool at this stage, kind of like the $pages API var, but for snapshots/versions of pages. It lets you create a snapshot of any page, including its fields and files (including core fields, ProFields, 3rd party fields, repeaters, nested repeaters, table fields with a million rows, etc.). The snapshots can be restored at any later time. Snapshots may also be restored to a different page, such as a new or existing page. In this manner, a module like ProDrafts may be able to use it to manage draft versions even better than it currently can, or at least that's the plan. Though since it's an API tool, my hope is that when/if it winds up in the core, others may be able to use it for stuff we've not thought of yet too. The module is a little different than my previous attempts (like what's in ProDrafts now) in that it does most of its work directly at the database level (and file system level, where applicable), which enables it work without needing to know much about the Fieldtype. Currently it is fully functional, but I have a few less common cases to work out before it's ready for release. Once installed, every page includes a Snapshots fieldset, which can be located in the settings tab of the page editor, or a separate tab in the page editor (configurable). When installed, every page has one, so long as the user has the appropriate permissions. There's a screenshot of what it looks like in the page editor below, but it is very simple at this stage, basically just enough for testing purposes. Every snapshot has a name that is unique on the page. You can overwrite a snapshot just by saving a snapshot with the same name on the same page. So you could for instance have a hook that creates a snapshot named "undo" right before a page is saved (in a Pages::saveReady hook), and in that way a module could add a basic undo capability to the page editor. This is just a simple example though. Thanks for reading, have a great weekend!

Is there anything else that may be the cause for the slow down? Only have 3.0.179 for tests on hand but just used exactly your code and only the initial load takes a bit longer as the webp needs to be created. Even older version (before 3.0.165) do very well with webp. Are there any errors or warnings in the logs? Anything else that shouldn't be? Any image or file modules in place?

I'm posting this as an update to an earlier post created by @Hari KT: https://processwire.com/talk/topic/4958-composer-support-for-processwire/. Though that approach still (kind of) works (as does the one detailed in https://github.com/wireframe-framework/processwire-composer-installer), thanks to @d'Hinnisdaël there's now a better alternative: the official composer/installers project ? An example repository implementing the things detailed in this post: GitHub repository: https://github.com/teppokoivula/HelloWorld Packagist entry: https://packagist.org/packages/teppokoivula/hello-world As a module author, how do I make my module installable via Composer? 1) Add a composer.json file to your module's directory. Here's an example: { "name": "vendor-name/module-name", "type": "processwire-module", "license": "MIT", "extra": { "installer-name": "ModuleName" }, "require": { "composer/installers": "~1.0" } } The composer.json file explained: "name" consists of two parts: your vendor (author) name, and the name of the package (module). These can (but don't have to) be the same as your GitHub or BitBucket user and repository names. Please note that this value should be all lowercase! That's the syntax expected by both Packagist and Composer. "type" should be "processwire-module". You may have seen "pw-module" used by other packages; that's the value used by third party installers, you don't need to worry about that now. "license" should specify the license your module is published under. See Composer help for expected syntax. It's technically fine to leave this out, but it's always a good idea to let users know how they're allowed to use your code. "installer-name" under "extra" should specify the expected directory name for your module. Usually this is the same as your module's name. If you leave this out, the package part of the "name" value will be used instead (which may be just fine, though I'd recommend always filling in this value). "require" includes Composer dependencies of your module. The key part here is "composer/installers" — without this Composer won't know that your module requires said installer, and it may not be installable at all, so be sure to add this row. 2) Submit your project to Packagist: https://packagist.org/packages/submit. You will need an account for this step. It's free and very easy to register, and you can automatically connect it with your GitHub account. Connecting with GitHub also makes it easier to auto-update package versions from GitHub repository. 3) Recommended but not absolutely necessary: add tags to your module's Git repository. It's recommended that when you push a new version of your module to GitHub or BitBucket, you also add a matching tag: if you push version 0.0.3 (or version "3", following the old school ProcessWire version number format), you should also add tag 0.0.3 (or "v0.0.3" if you want to be verbose) to GitHub/BitBucket. (This step is not strictly speaking necessary, but it does make things easier for users installing your module, and makes much easier to track which version of the module is currently installed via Composer. It requires additional step when publishing a new version of the module, but please consider doing it anyway!) 4) Also recommended but not absolutely necessary: configure Packagist to auto-update based on GitHub/BitBucket. Follow the instructions here: https://packagist.org/about#how-to-update-packages. This step ensures that once you push a new version of your module, Packagist automatically updates stored information without you logging in and hitting the "update" button manually. (This step may not be necessary if you've already allowed Packagist access to your GitHub account.) ... and that's it. Congratulations, your module is now installable via Composer! As a module user, how do install a module via Composer? Go to your site's root directory and type on the command-line "composer install vendor-name/module-name". You can look up the correct details from Packagist, or the module author may have included them in the support forum thread. Obviously this only works for those modules that have implemented Composer installer support as outlined in this tutorial. Note: if you're using a "non-standard" directory structure for ProcessWire — you've moved the root of the project outside the public web root, or something along those lines — check out the custom install paths part of the composer/installers README. The "installer-paths" setting allows you to manually specify a custom install path for the "processwire-module" package type.

ProcessWire 3.0.180 contains 20 commits containing various minor new features, issue resolutions and pull requests. While there's no single major feature to write a big blog post around, combined there are a lot of worthwhile and useful updates so this version is definitely worth updating to. More details can be found in the dev branch commit log and at ProcessWire Weekly (issue #370 covered an addition to our $files API var). Yesterday the forums were running a little slow because we had our yearly DDOS’er pay the site a visit once again (remember last time?), and from an apparently unlimited supply of IP addresses around the world this time. We shut down the forums to users that weren't logged in while the load was high. Actually, it does this automatically now. We also updated the forums from using memcached to AWS Redis, which should also help as a nice upgrade for the forums. Big thanks to @Pete and @Jan V. for setting it up and keeping everything running smoothly. I'll keep it short today because it's supposed to rain here all weekend, so I'm going to spend some time outside while I can. Thanks for reading and have a great weekend!

@wbmnfktryou are right. I totally forgot autosmush module. When turned off and webp enabled via hook it flies. Thanks mate!

I've seen translations take varying times depending on length and language. Are you letting it work for a while? I will test more with longer content and look into how DeepL handles it.

Hello! New to ProcessWire, it's been a great experience so far! I'm using a module (Import CSV) that requires me to enter the URL of images. I have uploaded a folder of all the images into a directory at path "/site/templates/img" –– however, when I try to find the image ("https://www.mysite.com/site/templates/imgs/image1.jpg"), ProcessWire returns a 404 page... I'm wondering how I can setup permission so that a folder of files can be accessed via URL and referenced in this module, as either a full-URL, or where to put the files/what to setup, so it can be read as a relative url! Thank you for any support.

No, LoginRegisterPro is not a superset of ProcessForgotPassword if that's what you are thinking. If ProcessForgotPassword is installed, then both the core and LoginRegisterPro will use it to provide a common password reset mechanism. What LRP does is provide an easy way to put registration (with a confirmation stage), login and profile management forms into your front-end pages.

We should keep reputation count IMO. As it's a good quality signal.

It shouldn't be a problem to access that image directly, that's exactly what happens with the css and js files that you add in the templates folder. It could be a permissions problem in the server, but then you wouldn't have that 404 page. May seem too obvious, but make sure that you wrote the url correctly ?

Is the module not developed further? I have the same error which was reported back in 2017: Module is not installable because not all required dependencies are currently met. PHP 7.4.14 >= 5.6MarkupPwpswpGallery PHP 5.6 is hardly supported anymore for many providers. It makes no sense (!?) to use tricks to start the installation. A question to the developer, what is the future of MarkupProcesswirePhotoswipe? Will the PHP problem be fixed upon backend installation?

I can confirm @torf's comments above, this module doesn't work in it's current state. Some images are lager than others, it won't display in a nice grid no matter what options I try. Wish I would have looked here before I wasted a couple hours trying to figure out what I was doing wrong, lol. Sure would be a nice addition to my PW toolkit if it worked.

Markup is what I do: $f = $this->wire('modules')->get("InputfieldMarkup"); $f->attr('name', 'config_intro'); $f->label = ""; $f->value = "<p>These settings will override those in the main config settings for this page.</p>"; $fieldset->append($f); I think you'll need lowercase "markup" using that approach to field configuration.

Pete's right that there probably are a lot of considerations here. You don't really want to add the watermark to the original because then it's going to be in other sizes (thumbnails, etc.) and you may not want that. You don't want to use a filename based on the original because then someone can pry and find your non-watermarked version. But then if you create a different filename, it's no longer tied to the original and will stick around if the original ever gets deleted–we might need to add a new hook to Pageimage::getVariations in order to solve that one. Actually I think all the issues are solvable, but just a little more work than it sounds like at first. One approach is to put the watermark capability in it's own module: <?php $w = $modules->get("WatermarkImage"); $w->setWatermark("mark.png"); $image = $w->watermark($page->image, "new-file.png"); // or just $w->watermark($page->image); I'm guessing something like this would return the URL to the new file, or a new Pageimage object. Another approach would be to make an autoload module that adds a new watermark() function to the Pageimage class and works the same way as the size(), width() or height() functions, returning a new Pageimage: <?php $image = $page->image->watermark("mark.png"); Still another option would be to just create a new Image fieldtype that automatically adds a watermark (configured in the field settings) to every image uploaded to it. Or, every image with the checkbox, like you mentioned. Antti's CropImage fieldtype is probably a great example to look at for how to implement a module like that. If you decide to build a new module, just let me know anything I can do to help.