Leaderboard

But more importantly: YOU'RE BUILDING A MAILCHIMP NEWSLETTER INTEGRATION MODULE? WHERE DO I SIGN UP?!

Thanks for the Flourish suggestion - I did recently see something about it, but hadn't investigated yet - looks like it could come in quite handy. I know it's been said before, but the community on this forum really is about the best I've ever experienced. I am looking forward to being able to give something back very soon.

mamber_name%^=a

No captchas anywhere, at least no visible ones. They're usually inaccessible, not as “bulletproof” as many people may think, and a nuisance to any visitor. Ever spent half an hour entering whatever you got from those stupid captcha images, failing over and over again although you were sure to have entered the correct pass phrase? Exactly. There is no perfect solution to avoid comment or contact form spam. As soon as you offer any kind of contact via form, you're going to get spam, period. I have found that a hidden captcha/honey pot can work pretty well and avoid a lot of spam. That basically means a hidden text input field which is not supposed to be filled out and is hidden via CSS from visual browsers and screen readers. Spam bots tend to fill out said field anyway, which means the PHP logic of the form will not send it. Of course, at some point, spam bot will adapt to that as well … YL

(Note: Module name temporary and will change) As recently mentioned here I am recently working on a little module. This module gives you a new admin page under "Setup" to create pages in a "batch" mode. What does it do - You can select a parent page where you want to create your pages. Then it will give you a list of templates you can chose from. Those should be permission and template setting aware. Also only parents that really can have children will work, else it will give an alert. - Add as many pages you like by clicking "+add Page". You can set the pages published or hidden status. Sort or remove the pages. - After you entered a template and at least a title you'll be able to klick "create Pages". If successful it will append the list of pages you just created with an open in page tree or edit link, and also the parent. - You can add pages and repeat the process to add pages to the pages you created simply by changing the parent page in the field above the table and go on. It's all ajax and not page load. Also the links of the created pages that get appended below will stay in the document and only the form entries get cleared. This is still work in progress, but I thought enough to share and if you like you can try/test/use it. Download: ProcessTools.zip Screen:

ProcessWire is fast. With ProCache, ProcessWire is insanely fast! ProCache provides the ultimate performance for your website by completely bypassing PHP and MySQL and enabling your web server to deliver pages of your ProcessWire site as if they were static HTML files. The performance benefits are major and visible. Using ApacheBench with the homepage of the Skyscrapers site profile, we completed 500 requests (10 concurrent) to the homepage. The amount of time occupied to complete each of these was as follows: 29 seconds: no cache enabled 6 seconds: built-in cache enabled 0.017 seconds: ProCache enabled As you can see, the performance benefits are substantial. ProCache gives you the ability to drastically reduce server resources and exponentially increase the amount of traffic your server can handle. This is especially useful for traffic spikes. Beyond measurements, ProCache makes your website feel faster to users, respond faster to search spiders (which can help with SEO), and helps to conserve server resources for requests that actually need PHP and MySQL. ProcessWire is already very fast, and not everybody necessarily needs what ProCache delivers. But regardless of whether you need it or not, there is little doubt that you can benefit greatly from ProCache. For an example of ProCache in action, visit processwire.com or the skyscrapers site. Look in the lower right corner of the page (in the footer). If it says "ProCache", it means the page was delivered via ProCache. We did this for demonstration purposes (ProCache does not put anything in your markup unless you tell it to). More information about ProCache can be found on the ProCache documentation page. Please note There is a known issue when using ProCache with the LanguageLocalizedURL module. I hope to have this figured out soon, but for the moment you should not use ProCache in combination with that module as it doesn't appear to work in full. ProCache does not yet support multi-host capability (i.e. cache and delivery of different content per hostname), but it will very soon. How to get it Like with Form Builder, ProCache was produced as a commercial module to support development of ProcessWire. It is now available for purchase here. ProCache is in a beta test period. As a result, it's being offered with introductory pricing that may increase once we're out of that period. During the beta test period, I just ask that you let me know if you run into any bugs or issues during your use of ProCache. I also recommend that you follow the usual best practices with regard to backing up your site and testing everything before assuming it's all working. Beyond the introductory pricing, you may also use coupon code PWPC-BETA for 10% off the listed prices at checkout. This code will expire as soon as we're out of beta. When you get ProCache, you'll also get 1-year of access to the ProCache-members support and upgrades board, available here in the ProcessWire forums. Upgrades to ProCache will also be posted there for download. Disclaimer: At the date/time that I'm writing this, I think that I am currently the only one using ProCache in production use. That's why I'm providing it with the lower costs and coupon. If you are running production sites where everything must always work perfectly, you will either want to: 1) wait to install on important sites till it's out of beta; or 2) test thoroughly on a staging server or localhost before taking it to production use. In either case, always make sure you have good backups anywhere you install new modules, and always test to double check everything works how you want it to. Get ProCache Now ProCache Documentation Below are a few screenshots that show the configuration screens of ProCache. Have questions about ProCache? Please reply to this topic. Thanks for your interest in ProcessWire ProCache!

I've been wanted to start this theme for a while because ever since I first heard of ProcessWire I felt it needed a really calm theme, one void of clutter and noise. While I may have taken this one to the extreme, I'm hoping some will find it's simplicity refreshing. It will be optimised for mobile devices and you can customise the colours, even the grey. I look forward to posting more of my progress!

Fancy Admin Mode Just had a little funwith fancybox iframes, and created a little module that opens all admin links (topnav links, edit, view, new, copy actions) except "Pages" screen and "Site", "Search" in a FancyBox, so you'll never leave the page tree. It even works with inherit editing child pages. Download: https://github.com/s.../FancyAdminMode Little screencast to se it in action:

Hi guys! here is my first published site made with ProcessWire: http://max-cafe-bar.de The design is not mine but Erika's, I only adapted it to the screen and made all the changes needed for being responsive to screen sizes. I'm aware that it is extremely slow... the server is where they had the old site hosted, and since the PW back office is also acting very slow, I'm assuming It has something to do with them. Anyone from Germany has any experience with strato.de?

So this month marks an entire year since someone opened me to the world of Processwire. Can't believe it's been that long. I have to say that without PW I would have lost many hours of coding and recoding classes, setting up basic websites and database tables. Aside from that, the API is something I would have killed for 5 years ago. PW has already given me a load of leverage of building projects fast and making way more money in less time. That said, after doing around 20+ installs since starting to use PW, I've noticed a few things about my work flow that I think could be improved. These improvements could spike productivity through the roof and save me even more hours and make me more dollars than before. There's a LOT of back and forth when setting up a website in PW. What we need is a way to reduce the amount of time creating new templates, fields and pages, as well as editing all of this stuff. Today I was thinking, wouldn't it be great if there was a way to just add a new page by typing it in a new slot below the other pages, selecting a template and clicking save. By default a template could be selected, for example the allowed child templates or the default-page template. Also, it would be cool to add and edit templates on the fly as well. Let's say we create a new page, click add new template (JQuery window pops up) and we can either add or edit the template right there as we're creating a new page. Also we could create new fields while editing the template. That way we could create a page on the fly with minimal settings, set up the template, add any additional fields we need and save it and publish it all in the same area. Now, this would not be easy to code by a long shot. Would take a lot of ajax calls and JQuery to get it to work. But having something like that would be wicked. With this, we could basically set up a page tree in 10 minutes or less. I know the obvious answer is, "well, go and code it," I seriously don't have the time for this right now. ProcessWireSexy was my planned theme but I'm still trying to find time to even start on it. Is there a theme out there like this that someone has already made? Someone has to have already thought of this.

There's some issues with floated elements in widget content (already mentioned this couple times) 1. I have two floated buttons and I need to hack the container to be able to avoid collapsing. 2. When floating the inputfield buttons, the margin on the button is adding and you see the background color when hovering, instead the margin should be on the wrapping <a>. So simply doing this in my css to float the buttons #MC_NewsletterPreview div a { float: left; } And get this: Instead I have to do this to fix both issues with it, which is not really nice. Overflow hidden on container is a solution I would avoid. #MC_NewsletterPreview div a { float: left; margin: 0 1em 0 0; /* add margin */ } #MC_NewsletterPreview .ui-widget-content .ui-button{ margin: 0 0 0 0; /* fix hover background color issue */ } #MC_NewsletterPreview .ui-widget-content{ overflow: hidden; /* fix floated content issue */ } To get this #id's Last but not least. When I have a inputfield "title" it adds an #title id to it. But the admin page when editing a page has already a #title for the page title above form. This should be changed to something like "#pw_title" to avoid issues. Stupid me, I just have to set a different ID, forgot it's not set by PW but by my code. So not a real problem just something to keep in mind.

Is anyone else noticing something wrong with these two statements?

Actually when using dev-branch, both ^= and %^= are using SQL LIKE and thus both work with short words and MySQL stopwords. Master branch (production version) behaves differently, like described above. @ryan: Was this the intention? The change was made here: https://github.com/ryancramerdesign/ProcessWire/commit/0f0be7b60690db9de4af664dbb5b94ef7e6ecef1#wire/core/DatabaseQuerySelectFulltext.php and it actually obsoletes parts of matchContains() method there. Looks like I hit this behaviour with a couple of tests just yesterday (using ^= and not testing %^= at all as I remembered they're the same thing - not so much black box testing...).

@pete you're good! YOU SPOILED IT!

Good tip, thank you - I think at one point I was actually wanting the user's name assigned to $u, rather than their id, but turns out I am not using that now anyways, so $user-> works a treat. Although come to think of it, there would still have been no need for the "$users->get" - not sure why I used it

Yeah and you can make them look the way you want. Of course for the female users, they're all male.

Hey Joss, Not a total solution, more of an idea to get you started; when you hear phrases like "ad-infinitum" in the context of computation you probably need to be thinking of using recursion rather than iteration. In most programming languages this is handled by having a function that calls itself as many times as needed to get the job done. Something like this perhaps... function renderChildrenOf($parent) { $output = ''; $children = $parent->children; foreach ($children as $child) { // Render this child. NB use of .= which is a PHP shortcut to // concatenate stuff at the end of existing $output. // Adjust this to suit your needs $output .= '<li>' . $child->title . '</li>'; // If this child is itself a parent, then render it's children in their own menu too... if (count($child->children)) { $output .= '<ul class="dropdown-menu">' . renderChildrenOf($child) . '</ul>'; } } return $output; } $homepage = $pages->get("/"); // Setup the start of the top-level menu... $menu = '<ul class="nav">'; // Append something for the homepage (as menus usually squish the root node in with its children anyway)... $menu .= '<li><a href="/">' . $homepage->title . '</a></li>'; // Set the ball rolling... $menu .= renderChildrenOf($homepage); // Close the top-level menu... $menu .= '</ul>'; // Show the result to the world... echo $menu; Ok, that's off the top of my head and is meant to give you a starting point to address your ad-infinitum issue. You'll need to experiment some and adjust the markup as needed for bootstrap. Hope that helps.

I'm guessing you don't like Laravel much? There is a reason why statics exist as a language construct, and there is a reason why we use them where we do. Though our usage is admittedly rare, there has never been a goal to "avoid statics as much as possible". The goal has been to use the tools available to us to make ProcessWire as simple, flexible and extendable, to the intended audience, as possible. It's not often that we have use for a static method in ProcessWire, but when we use them it's because they are the most appropriate solution. Keep in mind, we don't actually "need" static methods. We could certainly do without them. They just make a whole lot more sense in our context than the alternative. It's important to realize that Module is just an interface for communication between ProcessWire and the functionality you want to provide. It is not a class or even an abstract class. It provides no implementation for you (other than what you might optionally choose to extend from some other class). The only requirement for a module is that ProcessWire can ask it what it is. That comes from the Module interface's 1 static method: getModuleInfo(). Without that, it is not a Module. The ConfigurableModule interface has 1 static method: getModuleConfigInputfields(), which you can choose to delegate elsewhere if you choose. Beyond the obvious benefits, these methods are static for correctness: they are about all instances, not a specific one. The existence of the interface is not a suggestion that you implement everything in the class itself. That's entirely up to you. If the scope or philosophy of your need is such that you want to split every part of it into separate classes and files, then you should (this is what I do in FormBuilder). The Module interface facilities this. But the reality is that most modules are not of that scope, and there's rarely a tangible benefit in our context to being more verbose. But we ultimately leave that choice to the developer. A module is a singleton only if the developer specifies "singular" in his/her module definition. Otherwise you will get a new instance every time you ask for a module. I understand what you are trying to get at here. There may be someday when the configuration needs of modules increases in scope to the point where we might benefit from such an approach, but we're not near that yet. In the present, I think the majority of module cases benefit more from less verbosity and the current approach. We already have the door open to this approach, even if it's not implicit--FormBuilder uses something very similar, for example. But I would be happy to support this more implicitly as a second option for module configuration in the future. Instance types are not loaded before they are needed. They are loaded on-demand, unless the module's definition specifies "autoload". ProcessWire caches its module information so that it doesn't need to even include a module's file until ready to instantiate. It's the module developer that should make the call about whether their module is designed to be singular or multi-instance. A singular module might very well be coded differently than a multi-instance one. I don't want the consumer to have to think about this variable. I'm not opposed to making architectural changes in major releases so long as they are geared at make things simpler or easier for the users of the software. While I don't share all your opinions on how some things should work, I appreciate and respect them, and am especially glad for your interest in them. If we were to implement an architectural change to make module configuration more implicit to a separate class, I'd support it (after all, it's an approach I already take in some modules). But it would be added as an option, rather than a replacement. In terms of future major releases, I don't like breaking backwards compatibility unless absolutely necessary. But if there's a net benefit to the wider audience, then I have no problem with it. The only thing in my mind that carries that status right now is the switch to namespaces in 2.4 (and the changes that would go along with it), which I'm looking forward to collaborating on.

To build such tools is time consuming. And we all can't afford the time and energy and knowledge, like you too, to build them. Also it's nothing to do with admin theme per se, as those workflow and bulk editing things wouldn't be able to be build solely there. It would have to be built by modules. And I create already quite a lot of helper modules and theme that help out a lot and has improved my working with PW alot already. Ajax editing isn't possible within PW, as there's fields that need a lot more than just content (TinyMCE, Page etc) and need additional script and configurations. At least it isn't something easy. @raydale. But I have something else for you which is fun http://processwire.com/talk/topic/2380-fancy-admin-mode/ :) Regarding workflow and bulk editing. I see many possibilities creating custom edit modules and I think time will come where these appear (as my WIP). It's just we all haven't got the time needed to do everything within the short amount of time PW is out. Also I don't see all this workflows and bulk editing everybody requests as something that important, as you can easily open 2-3 tabs and do that without going back and forth clicking in the menus, and I know other (Ryan) also works this way. So having a flow that allows to edit everything from everything wouldn't be much of a time saver as I see it. Further the API can be used to create a lot of pages or field or templates quickly. DAMN STUPID FORUM SOFTWARE!!! It's getting worse and worse.... sorry

Love this! Want this! Need this!

Oh wow, are we charging now??

Just updated to 1.0.3 with some fix and new feature. fixed issue with template edit link added support for repeater fields http://modules.processwire.com/modules/helper-field-links/

This is a perfect way and I think the only one, even ProcessPageEdit uses it. If you output in your module $this->page you'll get the id of the admin page and not the edited one. So the GET id is there to know what page. I think there's other way to get to the page but it will end in the same call somewhere anyway. To check process your on in admin try $this->process and you'll get ProcessPageEdit as it's the process module running. So get the page and set it to the inpufield module with $this->page = $this->pages->get($this->input->get->id); Is simple enough and will always work in this context. Then use it as usual if(!$this->page->editable()){...}

This looks fantastic Ryan. I will be making a purchase for sure. ProcessWire already seems incredibly scalable and ProCache looks to be the icing on the cake.

This is interesting - http://docs.jquery.com/Tutorials:Safer_Contact_Forms_Without_CAPTCHAs

@WillyC Con.sider do secure pass.phrase gyration service u.can? you perhaps kickfarter?

Hopefully you are getting at least some form entries though? There are a couple things in FormBuilder that will likely keep out most spam even if you don't enable any spam prevention measures. You are right that the iframe makes it invisible to most spiders, so that's one of them. The other is that it requires a unique submit "key" for each form submission, and it must match up with the key in the form that was presented, as well as the one saved in the user's session. Most automated spam isn't sophisticated enough to maintain sessions and retain values in hidden fields. They usually just populate every field available with their spam. So it's unusual for spam to get through a FormBuilder form, even if you aren't using any spam prevention measures.

Honeypot as described by @yellowled, sometimes (depending on what you're building and for whom) accompanied with some JavaScript magic to make it sligthtly more efficient, still seems to work surprisingly well. I haven't felt any real need to apply CAPTCHA's in years. Just saying Anyway, this 2011 smashing mag article illustrates in great detail most common spam prevention solutions. It also points out their strong and weak points and even mentions some methods I hadn't even heard of before, like the slider -- that's actually damn elegant, but of course limits your audience, as they mention in the text.

You had me at hello. My order (developer licence) was placed successfully.

Is it faster than Lightning McQueen?

Hey guys, I've created an initial ProcessWire bootstrap repository if any of you want to use it. Try this, branch it out, do whatever you want with it. https://bitbucket.org/thatgibbyguy/base_html5_processwire The features of this bootstrap are: HTML5 Boilerplate Modernizr/HTML5 Shiv Javascript Libraries: Twitter Bootstrap Javascript Library jQuery-1.8.2 jQueryUI-1.9.1 jQuery.fittext.js jQuery.mobile-1.20 jQuery.scrollto-1.4.3.1 retina-0.0.2 CSS/LESS Frameworks: font-awesome (not 3.0 yet) KUBE Grid (in LESS) Twitter Bootstrap Library (in LESS - library.less) Base LESS file (style.less) Key changes to Ryan's initial download are just that I took each one of his calls and abstracted them out as includes. So Ryan's functionality has been abstracted into the following includes: Breadcrumbs -> breadcrumb.inc Page Titles -> pagetitle.inc Random Image -> randomimage.inc Search -> search.inc Sidebar -> sidebar.inc For example, to add the breadcrumbs to your site, simply include it in your markup like so: Also included is Soma's Markup Simple Module.

$event = $pages->get("template=calendar-event, sort=calendar_event, calendar_event>today"); if($event->id) { // you got one } That's repeating what nik already said. But I wanted to mention that you can just type "today" in the selector (no need for the mktime). PW runs any non-integer you put in there through PHP's strtotime(), so you can do things like "today", "yesterday", "next week", "+3 hours" etc.

(Sorry tinacious, formatting code and quotes just doesn't work for me atm...) You could do it the way you've described with a little change: if($date > $today) { // now you've got what you're looking for in $event $firstUpcomingEvent = $event; // break out of the loop break; } While the example above would do it, I'd say the best way to go is using a single get() with the right kind of selector . This is all you need: $today = mktime(0,0,0,date("m"),date("d"),date("Y")); $firstUpcomingEvent = $pages->get("template=calendar-event, calendar_event>$today, sort=calendar_event"); Although, it's a bit confusing to me when you've got a date field called 'calendar_event' in a template called 'calendar-event'. I would definitely make a mistake with that kind of setup one day myself . I'd change the name of the field to something else, like 'calendar_event_date' or whatever that makes the selectors understandable. But that's just me, the selector does work as it is. Maybe it's just a snippet and there's some html coming up in the actual template file or something, but just in case: it's a good practice to omit the closing PHP tag (at the end of the file) to prevent accidental whitespace, see http://php.net/manual/en/language.basic-syntax.phptags.php . ( Edit 1: I don't get it, since the forum update editing code and/or quotes just does not work. Is it just me? Using Chrome on a Mac. Edit 2: Let's see if I got it right after second edit... Going to use plain text editor from now on. Edit 3: Nope, not even that works anymore. Without any tags then? )

Why do you have to check this always? As for your second idea: Got to: Setup -> Templates -> Filters -> Show System Templates? -> Yes Edit the "language" template, add a textfield "code" and set your language code

Antti, yes, it's certainly possible. You can hook whenever and wherever you like. It's just a matter of being certain your hook has been registered before the event you're aiming for takes place. So you only need an autoload module to hook something you don't have full control yourself, and don't want to or are not able to require some initialization being called before using the hook. Here goes. And this one I tested a little so I know it works, for me at least . function myCustomAuthentication($event) { $user = $event->arguments[0]; $pass = $event->arguments[1]; // TODO: do whatever check is needed to authenticate $user // $pass has whatever you like, a token of some kind probably // must set replace-flag to prevent the original Session::authenticate() being called $event->replace = true; // return value is boolean // true: successfully authenticated // false: authentication failed $event->return = true; } // ...aquire a user name, somewhere, somehow... // hook *before* Session::authenticate() to override it // second argument is null because we're using a plain function and not a method inside an object $session->addHookBefore('authenticate', null, 'myCustomAuthentication'); // log in the user, passing whatever needed by myCustomAuthentication() as a password - if anything $user = $session->login("some-username", "some-token-with-a-meaning-in-this-very-context"); I'll actually be using this piece of code myself as well, this week I hope.

Hi, I just rebuild my website using ProcessWire: http://nico.is/ Should be working on all major browsers (that excludes IE). Two things: - The "browsers" are build with pure CSS3 (not the arrows) - Have a look at the footer / Nico

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.

Not sure if I am dreaming here, but was'n page creating in API working with just title at some point (it created name automatically from title). I just updated one project to latest and my "used to work nicely" code now cries: Error Uncaught exception 'WireException' with message 'Can't save page 0: /asiasanat//: It has an empty 'name' field' in /data/www/testi.potilaanlaakarilehti.fi/doc/wire/core/Pages.php:463 Code that used to work and now doesn't is: $t = new Page(); $t->template = $templates->get("tag"); $t->parent = $pages->get(1011); // 1011 => /asiasanat/ $t->title = $tag; $t->save(); Fix is of course simple, but I used to like this shorter way to create pages... EDIT: Never mind, it does work. It doesn't work if your $tag is actually empty string...