Leaderboard

I'll have to agree with Adrian: many clients won't see the benefit and many ProcessWire developers aren't hosting client sites themselves so that they could really benefit from this themselves. Problem with large images doesn't seem huge when you're visiting a site often enough for cache to kick in (which is true for many clients, I'm afraid). Unless you use analytics to see how the site is doing for wider audience you might not even notice that anything is wrong. Most of the sites we build also have couple of API calls to images tops and a ton of images included within page content (Tiny / CK fields). Benefits of minimize.pw for sites like that would be less dramatic. Then there are people like me. I've been minimising static images with tools like OptiPNG and also had plans to develop something similar to this module for local use. Your prices aren't high, but if I can do same thing locally without any costs (other than the work required) and without any image limits and so on.. well, it does sound tempting. (People like me are probably not your target audience.) Long post in a nutshell: I'd try to make the benefit of this service as clear as possible and consider what @apeisa said about minimising images during upload. Latter is what I see as the biggest flaw in your current product, actually: if the service would automagically start working after one-click install I believe it would be a lot more beneficial than current solution. Ease of use combined with very clear explanation about what happens when your free quota is gone (does the service still work, does it prevent using the site normally etc.) and easy way to upgrade your plan and you've got a winner.. probably .. and, of course, if you want to make big bucks with this, add native support for more platforms.

Hi guys I have resolved the issue -- it was to do with my fast_cgi parameters (particularly cache) in nginx.conf. I have put these back to default and the error has gone away. Alex

This is already old news to many of you here, but I finished writing up the full announcement today so figured I should post it (click the link below). Numerous upgrades and refinements make ProcessWire 2.4 our most friendly and powerful version yet! ProcessWire 2.4 is focused on listening to the feedback from of our users and answering with the best CMS experience for web designers/developers and their clients. Read the full announcement. For those upgrading from a previous version of ProcessWire, please read all of the upgrade instructions. Hope that you enjoy this new version! A huge thanks to Avoine for sponsoring the Field Dependencies feature new to ProcessWire 2.4!

After a bit of digging around, the issue was my instance of MAMP needed more memory for the resizing transaction to work as it should. This thread and Ryans suggestion of bumping up the memory limit from 32M to 256M got it working for me... http://processwire.com/talk/topic/2357-image-upload-gettings-stuck-on-100 Cheers guys!

apeisa is right - to have a chance of an audience you need to expand the service to other platforms using plugins. That opens two markets really - professional developers and designers and the non professional market; Wordpress users particularly. Now, obviously there are competitive services out there that are offering both lossy (TinyPNG) and Lossless. But I suspect this is a growing market, particularly on the lossless side as people want to make their offering more and more media rich, need to keep speed up but don't want to lose visual quality. It is a numbers game though. It will always be a small percentage of users that would even think of using such a service, and it is always a small percentage of those that are interested that will actually sign up. It may be that once the service is a bit more developed and broader based, you need to sell it directly into some companies (especially agencies) so you can boast a few names on your website. Once you are in that position, then you will probably need to advertise. When it comes to the two market areas, they will need to be treated very differently with different package offerings (the pro side needing more flexibility) and different looks. At the moment, the market does seem very complicated, from command line options and download systems like FileOptimize using a lot of open source plugins, to more domestically orientated system like TinyPNG and others like Riot and the developer orientated Kraken. What you will need to do is decide where the line is between the two markets and then develop the two offerings to meet those markets, making sure one feeds into the other, of course.

You share with us your experience with this service I really appreciate this, next it shows us your and your companies straightness. Great comments here are given. And I do think your service is wonderful. Teppo pointed out that this service could work if it is a one click, put it on/off service. One given thing is that we rely on services to build our websites. We rely on jQuery, we rely on the plug-ins we rely on ProcessWire on the Modules and on YouTube. We all have experience with failing services. I remember a using jQuery: //ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js which gave me problems because Google served me an updated jQuery (I asked for), but the new update was not compatible with some parts of the site. Without services we could not compete with all other web building companies, but depending on a service is tricky. I think we're all getting "smarter" & don't want to rely on some services what potentially can give problems or disappear. It's never fun to fix an old website because some of the services fails.

Do you want to find something in a set of 10.000 pages or do you mean a find result of 10.000 items? Searching in 10.000 pages isn't a problem, PW is really fast. But if there are a lot of possible results it's generally advised to limit the pages->find call to 25, 50 or another sane value. http://processwire.com/api/selectors/#limit . If you want you can combine this with pagination. The reason for this (others can prolly explain better) is that the pages->find call will return a PageArray that gets put in memory and if there are a lot of pages in the array things will inevitably slow down. Of course, depending on the situation, 'slow' in PW terms may still be acceptable. I have grabbed hundreds or even thousands of pages in one go and it still performed pretty well.

Phillip - thanks for a great writeup of your experience. To be honest, I am starting the get the feeling that too many clients/developers don't know/care about image file sizes. It amazes me the number of sites that I visit these days that have images of 500Kb to 1MB, sometimes bigger. I think some have gotten caught up in fabulous full page images, but don't realize that they can be made smaller and still look good. Also, I have to say that I think I would have a hard time getting clients to fork out an annual subscription for an image compression service when with a little care they can make sure the images are properly compressed before uploading. Of course this will depend greatly on the client - I am sure some will love the ability to not have to worry about anything when uploading images and would be happy to pay for your service. I hope your new pricing model works out for you - best of luck!

Thanks Nico. After three weeks, we want to share our experience and some informations about the module and service. We think that an open and honest approach on this topic might help others to develop great commercial (and free) modules. minimize.pw started as an internal solution for a problem. Working with an agency with large PNGs, we searched for a way to compress them with PNGQuant. We thought that other developers would be interested in this kind of a service and that lead us to the decision to make it a commercial service. We have to pay for the servers and maintenance. The whole developement took around 3 days with some additional hours in writing backend jobs like backups and payment management. As today, 21 days after launch, we've only got a single "Free" signup and zero licences sold. We got some E-mails and questions but nothing more. Beside our internal usage on three client sites not much happened. We didn't expect much, but we thought there would at least be more free signups. So what went wrong? Well, we made some assumptions: There is no interest in this kind of service. The pricing is to high and the free plan isn't worth a look. Our website could't convince visitors to use the service To many open questions because there isn't a FAQ or something similar We just have to wait longer The module missed some important features We hope that the first point isn't true. With some feedback from twitter, we think that there is a market for some developers to use this service. The same applies to the last point - at least we should have some more signups. So we might have to improve the remaining 4 assumptions. In the next week, we will update our service/site: An improved and better free plan: You will get 1000 images per year and you don't have to renew after a month. More images on new paid plans (replacing the old monthly model):Standard with 30 000 images / year and up to three sites for 39€ Large with 100 000 images / year and ten sites, 99€ A new webpage with better examples and a FAQ. We will later add a case study with a larger site. Planned features for the module itself:Compression while uploading images Replace images instead of making variants (as an option) Usage with the Thumbnails module (CropImage) (An Async performance modus) But before doing this, we would be glad to hear what the community thinks about this. We would appreciate some feedback and/or your thoughts on the service and the module. P.S. Here is a special key with unlimited images and sites, valid for the next four weeks: zE1DptpPYN

There aren't many tools I look forward to using every single day. PW has always been a joy to use and this release makes it even more so. Thanks Ryan and everyone who worked on this release!

PW caches any image sizes you create with $image->size(), $image->width() or $image->height(). They are all stored in your assets folder and called directly if they already exist.

@dragan: thanks, that actually solved it. There was an issue with storing language versions; language ID's were getting "stacked" instead of last one being used, which resulted in useless data. Looks like I never properly tested this with multiple language versions.. I've just pushed fix to GitHub and would suggest you (and everyone else reading this) to update the module. To fix existing data you can do something like this in your database: UPDATE version_control_for_text_fields__data SET property = "data1015" WHERE property = "data10141015"; UPDATE version_control_for_text_fields__data SET property = "data1016" WHERE property = "data101410151016"; # .. and so on

There was some change to labels and it is hidden via css so you also need to add a hidden class I think InputfieldLabelHidden. One of some changes in core affecting your site after update which is not documented...

Thanks for the feedback. Great thoughts. I think this should be our priority No. 1 for the next module update. Select the image-fields you want to minimize and done. We just have to decide what happens to image variants and how we can "catch" them. That was on my mind when writing the assumptions above. We couldn't clearly communicate the benefits of the module/service. That you will get faster page speeds because a webpage nowadays contains mostly (large)images. Question: Target more the developers or our "customers" (clients). As of today, the module will still work if our servers go down or your licence key expire. You just won't get minimized images because the module hands through the original PageImage. If you want to update your plan, buy another licence key... ? And again, the 1-click-solution as mentioned before. Got this one Our intention was never about "big money". The dev community here is small (compared to other plattforms) and we knew this. We could reach out to other CMS like Typo3 or Wordpress but thats not the plan and there are already other solutions out there. We just thought, that we would have more than a single "Free signup" after three weeks and maybe even a sale(!). We made the service commercial, to cover our server costs (currently a single instance for 20$/m) and maybe to get a little bit more to cover the costs for e.g. Ryans ProCache and FormBuilder for our own use. It's not for everyone to setup the scripts and a server to compress images. It should be as easy as possible and you should just have to focus on using the service rather than running it. It's hard to find prices and the right way to market your product. I think we still have to figure this out and see, where we will go. We will invest some more time but this might result in a better outcome for everyone (even other developers who might try to make a commercial service/module for ProcessWire).

<qoute>experience with running $pages->find("selector") api call on over 10,000 pages?</quote> I Don't think you will have any noticeable slowness with that amount of pages to be searched. You can't compare getResources with the ProcessWire way of finding pages. So far I understand Modx loads all the fields with getResources & the custom fields if needed in your results. ProcessWire wil only load the fields when you access them, so there's no field load with a page find. Result, searching 100.000 pages is not a problem. Searching 10.000 pages, just a blink of an eye.

Teppo pointed us to this jQuery selector for linking to images only if they are in ProcessWire. $('a[href*="/assets/files/"]:has(img)').addClass('fancybox'); Next I want to point out, if you set a maximum height & width for the image, you always know the maximum image size for the popup image.

thanks for the honest post. Your service definitely got me interested right from beginning. I think main reason for only one free account - there is not much to test. Your service is super helpful, but I have no rush to test it before I have need for it. I already know how it works and what it does. Also - pw community is pretty small compared to many others. I think you should offer rest api and plugins for other platforms too, if you really want to focus on your service. About your site - it definitely promotes the service well... but maybe you should focus on why page speed matters and how much images affect on that? Finally - I think service that does it on runtime (when uploaded) would be preferable, since no need for any custom template code then.

I think vxda is asking about the built-in gettext-like translatable strings in template files: http://processwire.com/api/multi-language-support/code-i18n/

Update: version 1.3.0, just pushed to GitHub, adds support for repeaters -- or, to be more precise, support for saving revision data for fields that are within repeaters. Repeaters being pages after all, it seemed most logical to treat them as such. If repeater field added to a template for which version control has been enabled contains fields that are also under version control, values of those fields will be stored just like they would be for the main page (page containing the repeater field). I'm not confident that my explanation made any sense, so let's just say that this should be self-evident once you try it. Main point is that instead of saving repeater values on per repeater basis the module is treating individual repeater fields (or repeater field fields..) separately Another thing to note is that snapshot feature added in previous update is now module called PageSnapshots. It's still bundled with VersionControlForTextFields and initiated (and automatically installed) by VersionControlForTextFields init() method, so this shouldn't change anything. I'm simply trying to keep the "core" version control module as lean as possible. Once again, I'd suggest making sure that things work properly before putting this update into real world use. There have been a lot of changes and something could've broken. I've tried to write and run tests vigorously, but those definitely won't catch all issues.. yet

Great tutorial Soma! This is the best summary of using PW's Inputfields that I've seen. I noticed you did $field->attr('id+name', 'email') so just wanted to explain what that is for those that may be unsure of the syntax. That syntax is basically saying to set the 'id' and 'name' attribute to have the 'email'. While every field needs a 'name' attribute (like in HTML) the 'id' attribute is optional… if you don't assign an id attribute, PW will make one up. If you intend to custom style a field with CSS or target it from javascript, then it's best to assign your own 'id' attribute. Otherwise, it doesn't matter. // this… $field->attr('id+name', 'email'); // …is the same as: $field->attr('id', 'email'); $field->attr('name', 'email'); // …as is this (direct reference): $field->id = 'email'; $field->name = 'email'; The advantage of using the attr() function over direct reference is that attr() can't ever collide with other Inputfield properties that might have the same name as a field attribute. It's basically your way of saying "this should definitely be an HTML attribute and not anything else." For recognized attributes like 'name' or 'value' it doesn't matter what syntax you use because an Inputfield already knows 'name' and 'value' are standard HTML attributes. But if you needed to add a custom attribute like "data-something", well then you'd definitely want to use the attr() method of setting. That attr() method should only be used for things that would actually be HTML attributes of the <input>, because they will literally end up there. So if you do an $field->attr('label', 'Hello'); you'll end up with an <input label='Hello'> in the markup, which is obviously not something that you want. That's why you assign a non-attribute property like 'label' or 'description' directly, like: $field->label = 'Something'; Last note about $attr() is that it can be used for both setting and getting attributes: $field->attr('value', 'something'); echo "The field's value is: " . $field->attr('value'); // same as: $field->value = 'something'; echo "The field's value is $field->value"; To extend your example, lets say that you wanted the 'email' and 'password' fields in a fieldset titled "About You". You would create the fieldset, and then add/append the fields to the $fieldset rather than the $form. Then you'd add the $fieldset to the $form: $fieldset = $modules->get('InputfieldFieldset'); $fieldset->label = 'About You'; $field = $modules->get("InputfieldEmail"); $field->label = "E-Mail"; $field->attr('id+name','email'); $field->required = 1; $fieldset->append($field); // append the field $field = $modules->get("InputfieldPassword"); $field->label = "Password"; $field->attr("id+name","pass"); $field->required = 1; $fieldset->append($field); $form->append($fieldset); Or lets say that you wanted those 'email' and 'password' fields to be each in their own column so that are next to each other horizontally rather than vertically. You would assign the 'columnWidth' property to both the email and password fields. In this case, we'd give them both a value of 50 to say that we want them to be a 50% width column: $field->columnWidth = 50; To jump out of tutorial mode and into idea mode: lately I've been thinking that PW should have a YAML to Inputfields conversion tool in the core (something that would be pretty easy to build), so that one could define a form like this: And create it like this (where $yaml is the string above above): $form = $modules->get('InputfieldForm'); $form->load($yaml); echo $form->render();