Raymond Geerts

Just wanted to mention that editing comments doesnt work in Google Chrome (PW 2.2.9). As soon as the "Submit" button is clicked after editing a comment. It defaults to the value it was before editing the comment. It works fine in FireFox.

Perhaps its possible to split it up to different pages. Where each type is a seperated page. But im not sure what your exact structure is. By the way: i never have tried using a repeater inside a different repeater myself

As its mentioned in the following topic it should not be a problem to nest different repeaters http://processwire.com/talk/topic/1358-repeater-inside-itself/

You could use a repeater for the text field. With that the customer can add / remove and sort the text fields quite easy. http://processwire.com/videos/repeater-field-type/ http://processwire.com/api/fieldtypes/repeaters/

Adrian, thanks for posting the links to that topic. But taking a look at the code i see its not realy a solution. I think it will not work when having multiple color pickers in one template. The thing is that the colorpicket swatch work fine in the default admin template. But stop working in the new admin template. I have taken a closer look and see that the solution Pete has posted is working great http://processwire.com/talk/topic/4650-new-processwire-admin-theme-on-dev-branch/?p=46380 I have modified the javascript from the colorpicker module and it works now great on the "old" and "new" template aswell. And made a pull request on GitHub for soma. Thanks guys!

With the new admin templates that come with the 2.3.5 version of PW there seems to be a bug related to the color swatches. When clicked they do not execute anymore, so the color value of the swatch is not send to the color value. I'm almost certain it is related to CSS. Removing the "templates-admin" folder from the site folder gives the "old" admin template in which it works fine. I had no luck yet looking for a fix. Has anybody an idea what change causes this problem, or how to fix it?

Not sure, it could mean several things. Could you check if the .htaccess file is in the folder on the server where you uploaded the site.

Are there any errors in the log file?

@teppo: the field does contain the value "wire_challenge". But your comment reminded me that i had modified the config file and set sessionChallenge and sessionFingerprint both to false when i had trouble login in to the manager just after moving the site to the live server. I have set these settings both to true again and now pro-cache works as expected again. So it was my own mistake that caused the wire_challenge cookies to not be set anymore

First of all, I'm loving pro-cache. It make the site load so much faster its almost science fiction. But since today we noticed that even when logged in to the manager as super user the site keeps serving the pro-cached pages. We first have to save a page in the manager to be able to see the un-cached pages. This gives some problems because when logged in to the manager the website has front-end edit functions, that do not show up anymore, before saving a page in the manager itself.

Some projects i have used SCSS, just not in this project. Maybe if i can find some spare time the normal CSS could be converted to SCSS. But for now im using my colleges Martijn his Markup CssCompress module, that works great too. http://modules.processwire.com/modules/markup-csscompress/

Your both right. When rescaling the window some divs around images are hidden (bootstrap 3 hidden-xs for example). But also jQuery takes care of some of the background images. I'm using data-bg-big and data-bg-small with both an image URL the latter one is resize a bit smaller. Then with some jQuery throttle function at resize checking every 250 ms for the window size. Depending on the size i show the big, small or no background image. So if you are on any screensize < 768 the background images never gets loaded. You are right about that, this is something i still have to do. Didnt had the time to finish it all before the deadline. The meta description tags are going to be filled as we speak.

Nice looking site. I like the "sec" style design. If i ever come to Groningen i'll have to remember this place for when im hungry.

Just finished our companies new website build with Processwire. Main site: http://www.agrio.nl/ A few branding pages: http://www.vee-en-gewas.nl/ http://www.melkvee-magazine.nl/ http://www.agriomediaplanner.nl/ fully responsive pro-cached several "one page" pages for each section / brand unique structure with templates as building blocks Our companies home page structure is shown in the attached screenshot. It contains several templates used as building blocks. The goal was to have a reproduceable structure and design to be able to easily create new landingspages without the need to code anything on the front-end level. An additional benefit from this structure is the posibility to give content editors only access to the content templates (orange coloured). Another thing to mention is the shared (green) pages, which contains content that needs to be re-used on several places in the website. For example the footer contact and google maps. But also structures for certain content.

@Horst I have updated my previous post and added an image containing 5 thumbnails with the PNG transparency issue.

Horst, thanks for that tip. I have installed PiM and see i can configure it for the FieldtypeCropImage and by that turn off sharpening specificly for the field, instead of globaly in the config.php file. I have attached an image which contains 5 thumbnails created with soft sharpening from several 24bit transparent PNG files. There you can see they all have somekind of black lines or dots on the left side of the image that occured while generating the thumbnails.

@Martijn: That would probably work if the thumbnail was made at the template level. But i just noticed that the thumbnail image is made in the backend. So passing any config settings in the template where the image is shown has no effect what so ever. I have now disabled sharpening by setting it to none in the config.php file. (which means if i want to use it on any image i have to pass it in a $options array.

How can i disable sharpening completely? When using this module on PNG images with 24 bit transparency i get strange noise, in the form of black lines or dots) around the edges. Is it possible to pass somekind of $options array as with the normal image field? ps. I already applied "jdiderik" his fix for alpha transparency, to get rid of the black background.

Thanks, just what i was looking for. Needed to check if a path on module config save, that can be set on the module configuration, exists, has certain subfolders and files and is readable.

WOW thats a massive list. Putting the files in that folder (in my case Sublime Text 3) works fine as you mentioned. No need to install anything because it worked right away.

Thanks for making this available, i realy like Sublime Text too. Any hints how to install these on OSX 10.7.x without using Package Control in Sublime?

I might have found a bug with field dependencies and the image field. I have the Visitibility Presentation set to default "Always Open (default)" and have set "Show this field only if" to the folowing condition: p_type_select!=1024,p_type_select!=1025,p_type_select!=1026,p_type_select!=1032,p_type_select!=1186,p_type_select!=1187 When i try to upload an image (both drag&drop and with the button) it somehow fails. Removing the "Show this field only if" condition makes the field useable again. Note: The image field is inside a Field Set Tab, but im not sure if thats the cause of the problem.

Realy nice this module. I noticed when using the "Hanna Code Text Formatter" to output a field that has also "Hanna Code Text Formatter" you need to set Output Filtering to false at some point. In my example i wanted to output the page title of multiple pages, while the page title itself also had the "Hanna Code Text Formatter" attached. Then it would show only the last title. Edit: i just see that this is kinda what Ryan mentioned 2 posts before. echo $child->getUnformatted('body'); The following works also, thats what i am using, but i suppose its the "same same, but different": $child->of(false); echo $child->body;

It looks like this fixed the problem. Now making a field required and setting the "Required only if..." in conjunction with "Show this field only if..." seems to work as expected. It seems to handle the column width fine again.

Sometimes requiredIf isn't removed from database. Thats what i noticed too. As soon you have set a requiredIf condition, saved it and then uncheck required, the condition still remains in the database. This causes the fields to showup rumbled (wrong calculations of field width), it also still shows a * character on the field.