Marvin Scharle

Can you please check the access rights via FTP? If the PHP script has crashed, it might be not accessible for everyone but your user.

You can pass any FilenameArray to AIOM starting on version 3.2. I know, this solution is not optimal but it is our solves the given problem of artamteex.

Hi Soma, I totally agree with you. Currently, It is possible to use absolute paths using the $config->scripts and $config->styles arrays (see: https://github.com/conclurer/ProcessWire-AIOM-All-In-One-Minify/issues/20). We are planning to change the behavior of AIOM in AIOM 4. Thanks in advance! Marvin

Hello artamteex, Yes, AIOM assumes that the CSS files are inside the templates folder. Take a look in the manual: "By default, only files can be included, which are in ProcessWire template folder. If you wish to add files outside that folder, you have to activate the backend "Allow Directory Traversal" option. Then you can jump back in the path."

As you can see, we've updated AIOM to version 3.2. In this version we shift from the current CSS compressor to YUI, which should solve multiple CSS-related bugs. Can you please verify if the bug is still present in AIOM 3.2? An empty CSS file sounds for me like a problem with your CSS code...

Hey evanmcd, it's back online - sorry for the problem.

We'll add a option in the module's settings page in the next update.

Hello everybody, our next module is an performant manipulator for Pageimages. It is called GIM. GIM is basically a wrapper for the PHP library Gregwar's image class, which performs many image manipulations. The wrapper is written in a way that is compatible with Horst's PageImageManipulator's (PIM) syntax. How does it work? GIM extends ProcessWire's Pageimage objects. You can load every image with the method gim(), perform some operations and save the image with the save() method: $image = $page->image->gim()->grayscale()->save(); The save() method returns another Pageimage object, so you can use it with other native ProcessWire methods and hooks. Methods GIM includes a lot of methods for image manipulations. You can find them in more detail on our module page. You can crop, resize, flip and rotate the image in several ways You can apply filters like sepia to the image You can add texts and shapes to the image You can merge multiple images in multiple ways Compatibility with Horst's PageImageManipulator (PIM) You can just use GIM instead of PIM by replacing pim with gim: $image1 = $page->image->pimLoad('prefix') ->setOptions(array('outputFormat'=>'jpg')) ->brightness(-10) ->contrast(15) ->grayscale() ->width(600) ->pimSave(); // uses PageImageManipulator $image2 = $page->image->gimLoad('prefix') ->setOptions(array('outputFormat'=>'jpg')) ->brightness(-10) ->contrast(15) ->grayscale() ->width(600) ->gimSave(); // uses GIM GIM includes every method from PIM, so it just works. Also GIM and PIM share the same variation naming scheme, so when you start using GIM, the transition is seamless and does not need to recreate every image. Having the same naming schemes means, that GIM and PIM can also work side-by-side. For a full list of compatibility and migration notes, please check out our module page. Performance The reason why we created GIM is that we were looking for a more performant PHP image library for converting lots of images at once. After using Gregwar's image class for a few images, we thought that this library should find its way into ProcessWire. After testing GIM on a few sites, this is what we found out: GIM handles already manipulated images around 40% faster GIM is able to heavily manipulate at least 15 large images (> 2000px) in one request (more weren't tested yet) GIM is slightly faster than PIM for single image operations I hope this is a great addition to the ProcessWire module ecosystem and you can enjoy it. Thanks in advance, Marvin P.S.: Horst, I hope you don't see this as offense. PIM is a great module!

Hello everybody, a few weeks have been passed since the last update. As you maybe remember, we introduced LdapSignIn, a module which allows you to sign in via an LDAP server account. Since you guys reported that there are many features missing to call it a "solution for Active Directory". Well, during the last weeks, we've thrown the module away, restructured and rebuilt it from the ground up. So we can now truely say: yes, this is a real solution for this porpuse. First of all, we've split the LdapSignIn module into 3 different modules WireAD handles the connection between ProcessWire and the Active Directory. It delivers a straight-forward API for authentication and accessing objects in the Active Directory. So your modules can access it as well. LoginAD extends the ProcessWire login process, so users from the Active Directory can log in. LoginSingleSignOnAD enables Single Sing On for ProcessWire using an Active Directory. Second, the modules also include a set of realy nice features: User and Group Migration You can define rules to map Active Directory user and group attributes into ProcessWire user and roles fields. Groups in Groups WireAD is able to detect groups in groups. So if user A is member of group B and group B is member of group C, user A is migrated as member of both group B and C. TLS and SSL WireAD handles connections via SSL or TLS to your domain controllers Load Balancing You can specify more than one domain controller to load balance between them Auto-detect Base DN or manually specify it Unique User and Role Objects Users and groups are migrated using their Active Directory GUID, so they are mapped as unique objects in ProcessWire Third, I created a demo video to show you some of these features: So what do you think? Please leave a comment below. Greetings from Germany Marvin

Hello everybody, We've just updated AIOM to Version 3.1.4. This is a minor update including the following changes: Bugfix: CacheFiles for Pages are now deleted when a new minimized file is created Bugfix: An error is thrown if the document root is different to ProcessWire's base path If you find additional bugs or have some feature wishes, please open up a ticket at our GitHub repository. Thank you! Marvin

Hello everybody, thank you for this vital discussion. We've updated Auto Name to Version 1.1, addressing some of the issues and thoughts of this thread. Changes: It is now possible to set a human-readable date format for the created and updated fields Renaming can now be restricted to unpublished pages Includes a fix for a bug that accidentally renamed system pages If you have any additional thoughts, please post them here or open up a ticket on GitHub! Thanks! Marvin

At lightning.pw, we use elements as subdomain names (also I heard, that one or two users spotted some sort of "wire" domains) @Joss: ProcessWire Lemon sounds AWESOME At general, I like the idea of using codenames and i find the Architects' names being the best. It is a nice callback to ProcessWire's origin and most of them sound cool.

@kongondo I was thinking about ProcessWire limitations, but of course, this makes sense

Hello @adrian and @apeisa, @adrian if renaming the page only the first time as an option is a feature wish, we can add this. Beside this, we can include support for your module. Please explain me, how to access the status and which status(es) allow a change of name. @apeisa what is the problem with renaming the page after being edited? I haven't accomplished any problems with this, yet. Thanks!