Adam Kiss

Yeah, I noticed, thanks. If the MM has update function, can you update the version on modules.processwire.com ? I'd love to try that [sorry for DP both here and on GH]

In case you didn't notice, I posted you a Issue on GH: https://github.com/somatonic/ColorPicker/issues/1

You might want to look at this: and let us know, whether that worked

Hello there! Antti answered the question regarding grouping, your functions will work out themselves (if not, there is always forums). However if I may propose one suggestion, it would be nice if you renamed the module to something like FieldtypeImageEffects (because ultimately, your field will be fieldtype), so this doesn't confuses your users: yes, in some groups, instagram may have popularized these effects; However, they were here long before Instagram and additionaly, the name 'Instagram Module' as well as 'imageInstagram' are better suited to module connecting your PW install to your Instagram account. Welcome to PW community

Okay, I'll take this quick The font choice (Cabin) is nice, but doesn't really work in this case for headlines. Some changes, like little lighter color, maybe blue-ish, maybe changed weight - something lighter - would help the colors are little too undersaturated; It's really hard (close to impossible) to create pastel-colored website, out of 'retro style'. But your font choices (signed off by client, I believe) don't fit the 'retro' style I would try to steer the logo color little away from the purple-ish blue, more into more saturated one grey/black shadows on blue background don't usually work, they look dirty. A little push of the shadow into blues will make it look cleaner. – for comparison, I changed your main body shadow to rgb(blue_top_header, 0.4) – (top is new shadow, bottom is old one) little more spacing always helps; You've got nice gap between article and sidebar, but the sides need a little more too, as well as content from the top. I tried to give it a little room to breathe, result: the border around the main picture doesn't help, but I couldn't turn it off in the code and couldn't be bothered to look for it for 15 minutes the 'active' item would like some more saturated color as well... and less blurry arrow I hope this helps, and I wasn't too harsh

Oh, I see. Super impractical. Thumbs up for laziness. J/K But it would be awesome! Imagine how the devs would love the PW, if we gave them a way to manage support tickets! Of course, you can do that on github easily.

Not really a fan of design, but the IA/structure seems well thought of, and you've got extra points for the nice implementation of responsivness. Good work!

You can become Jr. Member if you tell me whether or not you see this

Maybe if we call it something else than 'default value'? You know, like 'Populate value for new fields'. That should take care of some confusion, right?

Interesting, you really can.

Not to have big eyes, but I think the traffic will pick up, I think... So will support time. --anyway, you're the forums admin

But there is always way to do this; Imagine following forum structure: - Modules support - [modules groups subforums] - [modules subforums] - support 'tickets' Now, this would be a bitch to navigate through; however, a clear link from modules detail would solve this (and take you straight to modules forum]. --- Of course, if the problem is in the sheer size of the forums, that's a different story... But as Ryan uses to say: disk space is cheap.

This is actually called (the module class) HelperRender, because the module itself does nothing, just gives you some static class methods to use while working on a website.

https://github.com/adamkiss/HelperRender Finally, after a while, I built something! It is my way of working with templates, and pushing all the echoing into 'views', rather than having it scattered all over the template files. This is its third incarnation, built less the 'somehow tie it into PW' way, and more the 'it makes sense' way, its selfcontained, installs as a module, and gives you a bunch of 'Render::*' methods you can use both in your templates and in your views. I am particulloary interested whether the documentation makes any sense, because... well, I wrote it after working on this reincarnation for two days straight

If you are interested, I am trying about similar approach in my module Render::, which is currently in the 'proof of concept' phase.

I think that simple notice 'save before you set your files' should suffice here: after all, you do this only once, right?

Actually Pete, I think that in long run, it would be for the best if you made this configurable. I, for one, often use either /assets/[js|css] or /site/assets/[js|css] as my directories

Sorry, I assumed you had your first look around Yes, pictures are stored with the page, and are specific to page; In most use cases, this is fine. If you need to reuse images, there are always ways how to achieve it, easily, but there are many ways, based on scenario. As PW happens to be different sort of beast than most CMS, this often actually isn't needed... Well you'll find this out soon enough Some documentation regarding images is here: http://processwire.com/api/fieldtypes/images/

Unfortunately, you can't define any actions in ProcessWire. You also can't define where the files go — they always upload into /site/assets/files/$page_id. Regarding different file sizes, those are generated automatically when you load resized versions via $page->image->size() [this pseudocode, real image call is a little different] this is also to remeber, that if you e.g. Create gallery with 200+ images, first load takes a while, when different sizes are created., so it's better to do the first page load yourself, immediately

Fantastic, thanks!

And if I wanted to keep a key based array of all functions supplemented by these slaves, how would i add it to the module? Thanks Ryan

Hey Ryan (and few of those 'I know core' devs ) I am doing little something, and I'd really like to get to the data user assigned to $page during template processing. If I do this, for instance: $page->custom_value = 'test'; I can get the information about 'custom_value' existence from the $page object in both $page->data and $page->changes; Unfortunately, both of them are protected. Of course data is even better, because there is value as well, but I thought that if I had the name even, I could get to content. Is there any way around this? Thanks

Yeah, and there is still the thing that PW calls itself CMF (framework) - and if you need to have optional file in huge volume of data, you'd need to hack around via having separate 'file' pages and connecting them via 'page' field, for instance... So if it's possible to create/delete folders dynamically based on files count, that would be ideal. (Note: I did this. I had an application [albeit microapplication, with only 1k pages], which had exactly this setting - optional file fields, and only about 3% of pages had any file)

I think it's in the Pagefiles::cleanBasename... Can you try these changes, please? it should give us some info of what is happening with basename. Thanks public function cleanBasename($basename, $originalize = false) { $path = $this->path(); $this->message("before: {$basename}"); // ADD THIS $basename = strtolower(basename($basename)); $this->message("lower: {$basename}"); // ADD THIS $basename = preg_replace('/[^-_.a-zA-Z0-9]/', '_', $basename); $this->message("preg: {$basename}"); // ADD THIS if($originalize) { $n = 0; while(is_file($path . $basename)) { $basename = (++$n) . "_" . preg_replace('/^\d+_/', '', $basename); $this->message("origin: {$basename}"); // ADD THIS$this->message("{$basename}"); // ADD THIS } } $this->message("final: {$basename}"); // ADD THIS return $basename; } --- it looks like this on mac:

I've built an extendable module; you can install one 'master' module, and multiple 'slave' (content modules), but I'm struggling on how to tie them together; Option A: slave modules are autoloaded and hooked onto the master modules main function, and ran as needed. This is good from the terms of simplicity, but absolutely terrible - such a waste of memory (you hardly need all slave modules at once) Option B: Upon installation, slave module pings master module 'hey, I am here, you can find me under this key' and master module then builds directory of available slaves. What I'm struggling with is the most PW-compatible way to save a key=>value dictionary in a way available to module. I prefer option B, but so far I have just to ideas: either save it as serialized array (sounds incredibly stupid) or create repeater field with two text fields (sounds better, but repeater is optional and I'd like to have this as self-sufficient as possible). Need help, please. P.S.: I reveal more once it's at least in stable beta.