teppo

You could achieve pretty interesting results by taking this idea a bit further: Define areas on front-end where new elements (widgets, nodes, blocks, whatever) can be dropped and create new page fields for each of them, set up a collection of pre-defined blocks (templates, including proper template files for this purpose) you want users to be able to drop in, create a clean way to add new pages / edit existing ones via front-end (edit/add button, something like Fredi), store newly created pages somewhere and attach them to page field on current page automatically. Preferably you would also let the client re-arrange these blocks by dragging on the front-end side, to make it all function properly. Perhaps even drag blocks from one area / column (page field) to another? That's all very much doable, though I would imagine that it could take quite some time to work all the details out (such as where to store those pages to keep things smooth and stuff like that.) I'm definitely not advocating anything like this, based on similar reasons others have stated above (such as the fact that pages created this way usually end up unbelievably messy in the long run and no longer serve any real purpose, other than perhaps making some content editor very proud of herself) -- just saying that ProcessWire can be used for it if it's what makes you happy. If you're into it, why don't you give it a try yourself? See where it takes you and ask if you need any advice Been there, seen both of those happen more than I'd like to remember. For a very long time I believed this to be "the best way" (partly because it worked for us and made our clients very happy), but after listening and seeing all those problems it caused for our clients at the same time, I've come to one conclusion: this model is in reality one of the worst enemies of properly structured, usable and logical web content. It requires serious mental fortitude to keep things in order when you've got all the tools you could ever ask for right within your grasp. This is true especially in the long run.. and especially when there are multitude of editors to deal with. Ever been asked to re-organize a ten year old site for a client, one that's seen hordes of editors, various shifts in content strategy etc.? Not a trivial task and each and every page having a very different structure doesn't really help. It's rare for there to be someone who could keep it all under control either -- that kind of thing is too often limited to huge organizations only and even then resources tend to be scarce. From my point of view the most obvious (even if still only partial) solution for this is a clearly defined structure that editors must stick with, even if it doesn't please them at all times -- which is exactly what ProcessWire provides tools for. Clients may not "get it" at first, but that's why we as designers, developers and professionals should explain and teach them why this is a good thing. I rest my case.

Awesome.. and already useful by introducing me to jQuery Github which fits perfectly a project I'm working on right now

Just to make sure: does /site/assets/cache/MarkupCache/ directory exist and if it does, is it also writable (either 777 permissions or writable by web server?)

@Eltom: you're essentially describing a new minimum size setting here, which as far as I know doesn't yet exist but would admittedly be quite nice at times. So yes, @horst is right in that you'd currently have to create a new module to implement this. You could also submit this as a feature request to Wishlist & Roadmap section here on the forum.. though posting here may already be enough to catch Ryan's attention Taking a look at the source of InputfieldImage.module, there's a ___fileAdded() method (three underscores means that it's hookable) that could be used by a module. This method actually handles resizing image if it's larger than given max size, so something like this should work: hooking before InputfieldImage::fileAdded, checking if image size is smaller than minimum size given (settings of this new module or perhaps within field settings, though I'm not sure if there's a proper place to hook and add something like that there by hooking after InputfieldImage::getConfigInputFields and adding new field to returned InputfieldWrapper object.. or it could simply be a hard-coded value) .. and if it is, removing file and outputting error (like @horst already described above.) Sounds relatively simple to do, really. If you're even remotely interested in PW module development, you could give it a try yourself.. and please don't hesitate to ask if you face any problems! Extra tip: HelloWorld.module is great starting point for a module that adds hooks

Yes, $page is same as wire('page') and so on

Check out Page References Tab, sounds like you're trying to achieve a very similar effect at least.

Great idea, will definitely try it out! One minor thing I noticed after taking a quick look at your code: you should make sure that $_SERVER['REQUEST_URI'] actually exists before doing that strpos() at init. When bootstrapping ProcessWire for local use (shell scripts etc.) it won't be there and you'll get a PHP notice for that. Not fatal, but annoying in the long run

Note: you've mentioned that this should be done when page is added. I'm a bit confused about that, since your field shouldn't have any value at that point yet. If I'm confusing something here and that is actually the case, you'll probably want to take a look at ProcessPageAdd::execute -- pretty much everything else after this should still apply.. Execute method of ProcessPageEdit.module returns rendered edit form. By hooking after it you'll get access to $event->return, which contains said form markup. This way should be able to modify it before it gets sent to browser. I'm assuming that you're familiar with how hooks are added. If not, wiki has an (unfinished) article about those and HelloWorld.module provides very good examples. Hope this helps.. and that I understood properly what you're doing there

Little bit of background information would be useful here: you're saying that you've got a field you're using to create an image. What type of field is it, what kind of content does it have, does it store that too or is it cleared after image has been created? Is created image always at same location and does it's name vary? Depending on what you're doing exactly you might want to a) create new inputfield and/or fieldtype for this purpose or b) create an autoload module that hooks into ProcessPageEdit::execute (or something more appropriate) and if an image is found from pre-specified location renders it somewhere (positioning could be done with JS, if that's necessary.) Like I said it all depends on what you're trying to achieve and what's the whole context here

Title would be nice, agreed. About the alt text I'm not so sure. First of all, you'd have to take into account that an image used within text content and an image in image field are practically speaking two separate entities. Currently you can use same image over and over again with different alt texts, depending on context -- and that's good thing. From technical point of view image field doesn't know where it's content is / can be used, so you'd have to keep up with that data somehow. This is actually something that Image Manager (to certain extent, ie. when using special image embed tags and after specifying related fields) already does. Extending similar features to regular image tags created by TinyMCE / CKEditor isn't necessarily worth the trouble. At least not as a native feature, that is

"Hook*r, directly from the creator of After Shave Actions".. yeah, that sounds just about right

Not that it matters much, but you might want to reconsider that statement: http://nikic.github.io/2012/01/09/Disproving-the-Single-Quotes-Performance-Myth.html. Quotes don't matter, but concat method ("foo" . $var . "bar") on the other hand does tend to be slightly easier on eyes because many editors won't actually recognize a variable inside quotes (ie. string interpolation) as something that should / could be highlighted. So, essentially, use whichever you prefer. Just wanted to point out that micro-optimizations like these are a) futile and b) often misunderstood -- and thus generally not worth even thinking about

I've got this feeling that hooks debug section is going to be my new best friend. That information could have prevented couple of very nasty situations already. Glad to have it here now, awesome stuff Ryan!

Use double quotes: $tag="1009"; // quotes are not required here by the way, using them just means that you'll get string "1009" instead of integer 1009.. doesn't really matter in this context though so use whichever you prefer foreach ($page->find("template=placemarks, tag=$tag") as $child){

Regarding moving assets (as in static site files, JS and images etc.) outside /site/: Keeping everything "site-specific" within /site/ can make upgrading ProcessWire slightly easier and enables you to move all site-specific files to another server / PW installation etc. without needing to wonder which files were / are part of PW and which belong to this specific site. This is also how (and why) modules such as Site Profile Exporter work; they simply copy (most) content of /site/ folder and leave everything else intact. So, short answer is "yes, you can do it." But that doesn't necessarily mean that you should do it

Great answers, folks! One thing to add for anyone wanting to learn responsive design is to take a good look at Responsive Web Design by Ethan Marcotte -- guy who coined term "responsive web design" and wrote that wonderful article at ALA @kongondo linked above. Book itself is ~150 pages of easy-to-read (and easy-to-understand) practical tips, explanations and examples. Highly recommended (especially, but not limited to, for beginners) and well worth those couple of bucks it'll cost you. You can't get closer to "the source" than this. Keep in mind that even if you're going to let a framework do all the "heavy" lifting for you, it's still worthwhile to understand what's actually happening behind the scenes. (Oh, and while I'm at it, I'd go as far as recommend getting that Responsive Web Design + Mobile First book bundle A Book Apart is offering. Mobile First is another book you'll definitely want to read at some point!)

Agreed. This is something I thought of too.. right after posting that original topic I haven't really had the need to switch mailer "on the fly" before (especially when using Swift Mailer, which has always been pretty damn effective at sending to multiple recipients / batch sending emails etc. out of the box) which is also why I considered replace best method here. This way once an alternative mailer module is installed and configured it just magically takes over and developer doesn't even need to know that anything has changed (other than the fact that suddenly Mailer has awesome super powers.) On the other hand, I could imagine that in some cases (such as when sending those newsletters..) one might definitely want to switch to another provider -- perhaps even a web service like Mailchimp or Campaign Monitor. For this reason alone it would make a lot of sense to have Mailer configurable at code level. There would still be multiple ways to approach this need and I don't think any of them would need to eliminate the ability to create those "drop-in replacement modules": // like posted above ... $postmark = $modules->get("MailerPostmark"); $mailer->provider = $postmark; $mailer->send(...); // ... or you could also init another Mailer! $myMailer = new Mailer("MailerPostmark");

Perhaps http://modules.processwire.com/modules/maintenance-mode/ would help here? Not 100% sure if it'll still work with PW 2.3 though, but might be worth trying

I've been using this module to fill in a database of movies lately. Lets just say that there are "quite a few" of them and it's a lot of work. My point here is that since I happened to need a few custom fields that were always there, I modified module source just enough to include those -- no need for a generic option, just couple of lines of PHP and voilà: inserting movies just got a lot easier! I'm sure this is not what you were looking for there, just wanted to point out that modifying code of this module like that is quite easy to do and can save a lot of time if you're facing importing a lot of data by hand. That's one benefit of free software / open source, you know..

So, I've been seeing some email-related topics around here and actually had quite a few struggles of my own with this very subject myself lately. Thing is that sending email should be easy, but it's not always that; especially for those who have to work on multiple, low-price (and regrettably often low-quality) platforms that may or may not provide proper mail servers.. or prefer to host their services themselves and still want to avoid setting up and maintaining a mail server. Hosting a mail server can be real pain in the ass when things don't work like they should, not to mention that most people have very little knowledge about DNS entries etc. this requires. Anyway, long story short: yesterday I started thinking that wouldn't it be sweet to have a layer of abstraction within ProcessWire for sending email? Of course one could still use PHP mail() -- there's no way and no sense in even trying to stop that -- but using a common gateway would definitely bring in some extra value. This layer I'm talking about could by default use built-in PHP mail() but also make it possible to override it, thus allowing multitude of options that PHP mail(), being bound to Sendmail / it's alternatives, can't offer without additional server-side software (such as Nullmailer.) By making sending emails hookable it could also enable all kinds of interesting tricks to be done when mail is sent -- such as writing a custom log file, sending another email to someone else, updating local content (I'd imagine that this could be useful for building newsletter platform, for an example) and so on. Since words tend to fail me at times like these, I put together a quick proof of concept of what I'm talking about here, accompanied by one example of what could be achieved by doing this: A very simple yet functional Mailer class Two commits on top here list all the changes I've made in my PW fork to make this work -- including the fact that I've altered some default modules to use $mailer->send() instead of mail() SwiftMailer module, again very simple but fully functional (though only tested with Gmail SMTP) drop-in replacement for PHP mail() So, what do you folks think of this? Please keep in mind that this is just a suggestion and I'm not saying that this is the right path to take especially considering that it would add another API variable -- it just felt like best option here and I couldn't think of cleaner way to achieve it.

Umm.. perhaps something as simple as this would work (writing from memory and not tested at all.. and I do have to admit that I wasn't 100% sure which values you actually wanted to find): SELECT t1.g_id, t1.g_title, t1.g_summary, t1.g_description FROM g2_Item t1, g2_CustomFieldMap t2 WHERE t1.g_id = t2.g_itemId AND t1.g_canContainChildren=1 AND (t2.g_field IS NULL OR t2.g_value IS NULL); Slightly offtopic: I find this representation of different join types (even if it's not entirely correct) very useful when trying to get those right..

Actually, there's one huge problem with my approach, which I only just realized (writing things up somewhere tends to help thinking process, should do that more often.) In this case I need to know what that password is in order to use it for authentication with external service. Problem is that this pretty much forces me to write it somewhere in plain text or ask it every time connections to said service are made. Unless I'm missing something important here, that is. So essentially module config storing password in plain text isn't really the problem here -- storing it securely but still using it this way is. Ideas, anyone? How do you usually solve this kind of problem.. or do you just avoid it? Edit: taking a quick look at some related questions at Stack Overflow, I'm starting to think that encrypting the passwords stored in database and storing key either within module code or (probably as an alternative option) in a file within module directory might provide slightly improved security. Still the real problem is that password is even required here.. and sadly that's something I have absolutely no way to bypass.

Altering admin template would probably be fine if I planned this module only for my own use, but since that's not the case here it simply doesn't feel right I'll probably take the custom page route here. Doesn't feel right and requires reinventing some things that default module config has already solved, but I don't really see any other options.

Thanks, @Soma. You're probably right here (as always.) Still having to create a special configuration page just because one module setting happens to be a password seems more than a bit awkward. I don't really see the connection between JSON and plain text; there's nothing wrong with storing a hash within JSON and I'm sure it could be done without clashing with "real" values -- especially considering that certain names are already "reserved" (anything starting with "_" won't get saved.)