Leaderboard

Hi I would like to share with you my first module. Module integrates PixlrEditor with a InputfieldImage. You can easily edit your images online. The module provides a link to edit each field type InputfieldImage. Have fun;) Warning: I have not tested yet on localhost. As Ryan pointed out. It does not work on localhost. Pixlr webservice must have the ability to get images from your server. Source: https://github.com/P...GIX/PixlrEditor Screenshots: Changelog 1.0.2Now Support Thumbnails Module - Thanks to joey102030 for the addition.

Thanks, apeisa. I just pushed the bugfix to Github. @yellowled and Ralf: I'll take a closer look att the datefield issue soon. /Jasper

This module installs a page on your Setup menu in the admin where you can manage comments (assuming you have a comments field installed). Download from the modules directory at: http://modules.processwire.com/modules/process-latest-comments/ Features include: Easily find the latest comments needing approval or moderation. Shows comments from all pages on 1 screen, paginated and in chronological order. Enables you to change the status of any comment, edit the text or delete. Filtering by status/type, cite, email or IP address Screenshot: I've been wanting to build this for a long time, and something like this should have been there from the beginning, as it's a bit tedious to keep track of all your comments on a large site without this. So this module may be moved into the core for version 2.3, in which case it'll be renamed to ProcessComments, so as not to conflict with those that may have this installed.

I often need to find the closest parent Page of a particular type, and I found that something equivalent to jQuery's closest() function was not available. It's a simple addition to the Page class: /** * Return this page's closest parent matching the given selector. * * If no parent matches the given selector, this function returns a NullPage. * * @return Page * */ public function closest($selector) { $parent = $this->parent(); while($parent && $parent->id) { if ($parent->matches($selector)) { return $parent; } $parent = $parent->parent(); } return new NullPage(); } Please consider including this in the next release.

Hi everyone, http://ubasoma.com/ Ubasoma is the work of Suzanne Buljan who does graphics design for film - like supermom Returns, The Knowing and the recently released The Sapphires. Regards Marty

I don't have a simple solution to this one, but will do more thinking about how I could have ProcessWire provide a hook like Pages::statusChanged or something like that. But until we have something like that, here are a couple ways you could do it: Option 1 Add a hook to Pages::saveReady and have your hook function do something like this: Pages::saveReady hook $page = $event->arguments[0]; if($page->id && $page->isChanged('status') && !$page->is(Page::statusUnpublished)) { $result = $this->db->query("SELECT status FROM pages WHERE id={$page->id}"); list($status) = $result->fetch_row(); if($status & Page::statusUnpublished) { // page is about to be published // send your email } } Option 2 The other option would be to change your workflow such that user submitted pages went into a different parent than the live ones. For instance, user-submissions might go into parent /pending/ and published submissions would live in /live/. Then you could have your hook monitor for when a page is moving from /pending/ to /live/. If you wanted to, you could also have it take care of the publishing automatically: Pages::saveReady hook $page = $event->arguments[0]; if(!$page->parentPrevious) return; // if page is not being moved then stop now if($page->parent->name == 'live' && $page->parentPrevious->name == 'pending') { $page->removeStatus(Page::statusUnpublished); // send your email }

closestParent() makes the most sense to me. Though I'm still wondering about just: parent($selector); because the parent() function already implies closest parent (given that it returns the direct parent of the page). So if you provide a selector to it, then it's like saying: "closest parent that has [something]." I also like that extending the existing parent() function in this way wouldn't involve adding a new function to the API. It would also make it consistent with how the child($selector) function works. jQuery uses parent(selector) for something that isn't applicable to ProcessWire. jQuery's parent() can return multiple items, and the selector filters those. So they didn't have a choice to use the parent() function for this purpose. In our context, we don't actually need a separate function like they do.

You know that there are GPO template/admin files for Chrome, right? http://www.chromium.org/administrators/policy-templates /Jasper

Hehe, well they're a bit old school for me as I'm 30 Here's what's coming in the next version in terms of the editor: http://community.invisionpower.com/blog/1174/entry-7940-ipboard-34-dev-update-editor-improvements/

Ryan, i'll take a stab at it over the weekend.

Soma, I find it too long. What about closestP($sel)? It's like a gangsta rapper's nickname Nobody will guess what it means.

Well tough Smileys/emoticons are an easy fix - we can manually add conversions so they will work, though it is not standard to have a hyphen in them and I've used a lot of forum software - more standard without. Like I say though this can easily be solved by adding more variations in the admin so that is neither here nor there. Indentation is an annoying bug. It's on their list of things to fix. Seriously though? Neither of these are showstoppers and no software is perfect (apart from PW). Various editor improvements are coming in in v3.4 so I suspect a lot of the little quirks will be fixed then. It's interesting to note that the editor that you guys don't like is ckEditor (I think - might be TinyMCE even) but there are indeed quirks with their custom implementation. Compared to the previous software though I think it's a lot more useful overall. In summary, it would be a huge pain to switch again and the alternatives all have their own issues, bugs and drawbacks so I don't think either issue is enough to even consider it.

Tha über Soma!

Hi Jasper, I noticed a little typo. Tried to change it via git. As I'm totally new to github, I'm not sure if I did the right thing. Anyway: line 74 says piwik_max_kewords i/o piwik_max_keywords That's all Cheers, J

I like your idea of adding a "wire" template language! We can just stop referring to it as PHP and then all of the sudden people will see: wow this is a really easy template language.

Very well said Ryan, couldn't agree more. While I know I wouldn't use template language, I think that might well make PW a little bit more beginner friendly. Not sure if it is worth the trouble (vs. writing more tutorials, getting started materials etc..). Also maybe we could cheat a little here, and tell that PW uses templating language called "Wire", which looks like this: Output a variable: <?= $page->title ?> Loop for children: <? foreach ($page->children as $p): ?> <h2><?= $p->title ?> <? endforeach; ?>

I've always thought that the "template engines make it easy for non-programmers" was a myth, as it really just comes down to semantics and what characters you think are easier to type. But the reality is that template engines give you something like a jailed environment, and that increases the comfort level of some people. The prospect of limitation becomes an asset in that context. It means it's going to be harder to break things, and there is going to be a ceiling on what can be learned. I don't ever want to be in a "jailed" environment with a low ceiling, but also kind of understand the appeal to someone that may have never stepped beyond the likes of EE (which has come crossover with our audience). As we work to broaden the audience for ProcessWire, an alternate template engine for those that desire limitation here may help us to capture new audiences. There is also just the word "PHP", which scares off some, regardless of what is real or what we do. ProcessWire is always going to be an PHP API-driven environment at it's core, but I'm not opposed to adding on template engine(s) as an option for those that want them, in the future. It's something that's not at the top of the list on priorities, but it is something we'd like to eventually offer. They are a little more tricky to implement in PW vs. a system that is built purely for tags. The reason for this is that ProcessWire templates are executed directly by PHP rather than by ProcessWire itself. ProcessWire just hands off some API variables to the templates and lets PHP and the template execute natively. It's nice, fast and efficient. (Other systems like EE actually execute PHP code in templates using eval(); which is slow and inefficient… they hope you won't be using much PHP). The way we'd have to implement a template engine in ProcessWire, while still retaining the speed, is with compiled templates. The template using template-tags would have to be compiled to a native PHP template before it could be executed. Lots of these new template engines are designed to work that way anyway, so not a big deal, but just outlining how it would be done.