Leaderboard

12 days to go, it's time for those that didn't vote to do it. There is a link on the top of this page, but I will make it even easier for you http://www.cmscritic.com/critics-choice-cms-awards/

al.so spelche.ck no work cd ..

I just used this to add AD login abilities to a company docs intranet site for PW and would like to suggest some changes. In this particular environment, the AD logins are in the format of "Forename Surname" <- the problem here is the space in the middle and PW replaces it with an underscore before the check against the LDAP server so it fails and doesn't authenticate properly. The following fixes it: Replace this: $name = $event->arguments[0]; $pass = $event->arguments[1]; with this: $name = wire('input')->post->login_name; $pass = wire('input')->post->login_pass; And this: $user = wire('users')->get("name=$name" with this: $user = wire('users')->get("name=".$event->arguments[0]); Any other suggestions welcome, but that should work correctly in more situations. Antti, did you do any more work with AD groups mapped to roles?

Glad you found the problem. This is where the Autocomplete Page Inputfield Module comes in handy, but its not installed by default so you have to enable it first.

Hi this was discussed a little in another thread: http://processwire.c...age__hl__mailer I actually use templates and Mandrill to send some of my transactional emails such as welcome emails and confirmations. It's relatively easy to do this using SMTP. Here's an example: <?php require_once "Mail.php"; require_once "Mail/mime.php"; $email = new Page(); $email->template = $templates->get("email-template"); $email->somePageVariable = "example"; $email->setOutputFormatting(true); $body = $email->render(); // Header info $from = "<info@yoursite.com>"; $to = "<user@name.com>"; $subject = "Thank you for registering!"; // Send via Mandrill $host = "ssl://smtp.mandrillapp.com"; $port = "465"; $username = "info@yoursite.com"; // Your mandrill user name $password = "secretKey"; // Your mandrill API key $headers = array ( 'From' => $from, 'To' => $to, 'Subject' => $subject, ); $smtp = Mail::factory('smtp', array ( 'host' => $host, 'port' => $port, 'auth' => true, 'username' => $username, 'password' => $password )); $message = new Mail_mime(); $message->setHTMLBody($body); $mail = $smtp->send($to, $message->headers($headers), $message->get()); if (PEAR::isError($mail)) { echo($mail->getMessage() . "\n"); } else { echo("Message successfully sent!\n"); } Because the template can pull in content anywhere from your site, you can easily make templates for upcoming events, latest news, etc. For inlining CSS, premailer now offers an API. I think it's best to use netcarver's tag parser for user-specific details when bulk mailing. You could render these in the template and pass in the user ID to that, but then you'd have to inline the CSS after rendering each and every email. It should be possible to avoid this by rendering the template, sending to premailer, and then looping through the recipients replacing the first_name, surname etc. I've not tried this out yet though. Stephen

I don't think it is a good practice to use official PW logo with modules, site profiles etc. It will lead to confusion in the long run. I think same with naming: actually my module name for "Shop for ProcessWire" is not good name either. It is better than "ProcessWire Shop", but I think all 3rd party modules/profiles etc should stay away from ProcessWire name and logo (but be very clear about ProcessWire connection in otherwise, of course). At least PHP has this kind of practice: http://www.php.net/license/index.php#other-lic

All of the markup and classes can be specified from the $options to MarkupPagerNav's render() method. Originally I had the Blog profile using Zurb Foundation and so had it outputting in Foundation-specific markup/classes for pagination. Doing the same thing with Bootstrap is certainly possible and should be relatively simple. Take a look in /site/templates/blog.inc and find the renderPosts() function. At the bottom of that function is this line: if($posts->getLimit() < $posts->getTotal()) $out .= $posts->renderPager(); You'd want to change it to specify an $options array to the renderPager() function, like this: $options = array( 'listMarkup' => "<ul class='MarkupPagerNav'>{out}</ul>", 'itemMarkup' => "<li class='{class}'>{out}</li>", 'linkMarkup' => "<a href='{url}'><span>{out}</span></a>", 'currentItemClass' => 'MarkupPagerNavOn' ); if($posts->getLimit() < $posts->getTotal()) $out .= $posts->renderPager($options); Change the markup and class names as you see fit. There are many other things you can specify in this options array (I've just included a few examples above). For a full list of options you can specify, see the $options array present near the top of this file: /wire/modules/Markup/MarkupPagerNav/MarkupPagerNav.module

Hi Ferahl and welcome to the forums. You can put html into text or textarea fields. When using textarea, you can also choose TinyMCE editor and then customize it (per field basis) to contain only the needed controls. There ain't (or at least I don't know) any ready parser module for bb-tags, if that is what you are looking for?

$biology = $pages->get("/subjects/biology/"); $biology_students = $pages->find("template=student, subject=$biology, sort=title"); It does pretty much the same as your code, but in a more readable way. Also works with multiple pages like this: $subjects = $pages->find("template=subject, some_selector=value"); $students = $pages->find("template=student, subject=$subjects, sort=title");

PW pulls this from GitHub directly and caches it for a period of time. It looks like GitHub gave us a page with a meta redirect in it on the last pull... I'm guessing it was a "GitHub is down, try again" type thing that reloads itself. Anyway, I cleared the cache and that seems to have fixed it. Thanks for letting me know.

There is something funky happening with the cheatsheet. It's working fine on Soma's Github. Edit: for those that need it, here is the link http://somatonic.github.com/ProcessWireCheatsheet/

It's not a good idea for 'autoload' to be the only condition necessary to add script or css/style files. That's because some (including me) use things like $config->scripts and $config->styles on the front-end of sites, and don't want it to be populated with files irrelevant to my site. Furthermore, we can't assume that we always know what ProcessWire is being used for (it might not have anything to do with HTML), so it's just taking up extra memory if some autoload module is populating filenames when they won't ever be used. This is why none of PW's modules that deal with script/style files are autoload, and also why Process and ModuleJS module interfaces are not autoload. Process modules are on-demand, but if you have a Process module that you've made autoload, then you'd want to manually load any script/style files in the relevant execute() method -- this ensures they won't get loaded unless they'll actually be used. The ModuleJS class is different, as it's really not intended to be autoload at all, so there's not really any use in combining ModuleJS with autoload. The whole idea of javascript or css is specific to a runtime and on-demand context. And this is how it's happening in the admin template, as it is what ultimately triggers the JqueryCore and JqueryUI libraries to be loaded. And this is the time that they get placed into the $config->scripts array. So we'd just have to find some way to hook after that takes place, but before the markup of the page is generated. I think this may work for an autoload module: public function ready() { if($this->page->template == 'admin') $this->addHookBefore('ProcessController::execute', $this, 'hookExecute'); } public function hookExecute(HookEvent $event) { $this->config->scripts->add(' your script file '); }

I just recognized that on some new installation the module doesn't work as it failed to add the script needed. I corrected this and update the repo with version 1.0.2. http://modules.processwire.com/modules/form-save-reminder/

I see what you mean. Sorry for the confusion this may have caused. I will think more here about how to handle this. I don't want it interfering with API usage such as yours, but do want it to be able to still work with any login form (whether ProcessLogin or a custom one). Initially I'm thinking maybe I should just have it throw an Exception rather than a $this->error(). Errors communicated via $this->error() require something to report them (like the admin template), so this could be hard to find in API usage. Whereas an Exception would be hard to miss. Beyond this, I think a way to disable SessionLoginThrottle at runtime would be worthwhile for a case like this too.

Ryan, That was exactly what I needed. That makes a lot more sense than editing the core module. Thanks!!!

Does anyone know if it is possible to have templates & pages without a title field. I seem to run into a lot of cases where I don't need a title in my data structure and I end up making some excuse about how I can accomodate the title field in my data. As an example, lately, I am just dynamically populating the title field with a unix timestamp... just to fill something in to the title when I am creating pages with the APi. I don't need to view the titles of the pages I am creating in the page tree. and I don't need this field for anything in my data, output, selectors, anything really. Thanks in advance for any tips.

Setup > fields > title > advanced tab > turn off global flag > save > remove from templates where you don't need it. I think that should fix it -- but don't know if that's the official way to do it.

Add it here: Options +FollowSymLinks -MultiViews For those who may be interested, apparently GoDaddy has multiviews enabled by default, and this can mess up some rules http://support.godad...che-multiviews/

I don't mean "execute" function literally, just a hook or function that is added to a hook or process in the system or called directly somewhere. Adding script alone in the init on a autload module will always append it before jquery core. The code example on that link does have a hook with with a addLink function. This will get processed at a certain point where jquery core and likely other script are already appended. If you give us more example of what you are doing I can help. The code Ryan posted, is how the ModuleJS does it, but as I recently found out, doing it the same way in your module init, will add it before jquery core always, so you can't use ModuleJS. Look at the extensive thread I created also about the same subject here

You're welcome. I read most anything in the API and watched most video's. Also check out the cheatsheat. It's made by soma and is very handy when you quickly need to find something.

I got this figured out. It was a problem on my end. I have a "city" page field in the User template that used an AsmSelect input. The problem was that I recently imported over 30,000 cities into the database. As a result, trying to edit the user required the input field in the edit form to be populated with every city. Duh! I changed the input type to PageListSelect and it solved the problem.

Ryan, just for the record, Apple seems to support the file api now in Safari 6, I uploaded a file some minutes ago with drag-drop and it worked. Caniuse.com also lists the File API as supported on Safari 6: http://caniuse.com/#search=File%20API

Just bought it. It works marvelous. Great module! When I buy a one year license can we use it for one year or can we download upgrades and recieve support for one year?

I've not used it yet myself, partly because I am too dim to have thought of uses yet, but I am sure they will come to me and I am sure you clever guys will easily see how this service might be used within PW installs in some cases. https://deadmanssnitch.com/ I hope it's of some interest to someone, I'm sure one day I'll suddenly remember it and rush over to use it to solve a requirement. PS: Slightly douchy link removed.

$page->users->sort("email")

Hi, thanks for the feedback. Never thought about this really important problem. Agree Agree I think the best way to contribute will be the official logo + slogan somewhere in the footer section.

As a quick fix, you could add it to the top of /wire/templates-admin/default.php. If you want to write a module for doing that, a simple autoload module which hooks right before Page::render and just sends the header there should be enough. The Helloworld.module that ships with ProcessWire default theme is a nice starting point for this (it's already autoload and demonstrates how hooks are used.) The only code you'll need in init() would look pretty much like this: $this->addHookBefore('Page::render', $this, "sendHeader"); And your sendHeader() method would only need to contain that header you've posted above: public function sendHeader() { header("Content-Type: text/html;charset=UTF-8"); } Hope this helps!

I agree with Antti here. Using "ProcessWire" (or "PW") in the name of your site / product / module / whatever may imply that you have an official bond with ProcessWire project itself, whether or not that's really the situation, and thus should be avoided (unless that really is the situation of course.) That's also why the way @Luis' site above uses (modified but still very much recognizable) PW logo makes me think of an official PW apparel shop or something like that. I'm really sorry for having to be a bit blunt here, but that's the image I'm getting. And just for the record, I also think that PHP devs are being surprisingly lax regarding this matter. They're not saying that you can't use PHP in product naming, just that you "should seriously consider avoiding it", which for most developers out there seems to mean "it's all OK, we don't really care!" Then again, changing an old policy like that afterwards would not only cause a shitload of work, it would also be quite impossible to supervise and possibly even harmful to the spirit of the PHP community. So I guess they're pretty much out of options already

Great ideas here, but I'm still voting for putting up wiki site as a starting point. Developing something more sophisticated later on won't be much of a problem, but IMHO what we need now is first version - and we need it pretty quick, so that we can see how it starts gaining momentum. When discussing the platform choices, keep in mind that most wiki platforms are exceptionally good at handling stuff like multiple editors, access restrictions and revision history - absolute necessities if we're going to have more people producing content. My experience comes mostly from MediaWiki, though, so that's what I'd suggest. It's ugly and kinda bloated but it does get things done @charliez, that sounds great too, but wouldn't it provide some extra credibility if wiki site was running at manual.processwire.com or something similar? Though I'm not sure if this was what Ryan had in mind..