ryan

There has been a recent change in behavior here (a couple weeks ago), though not one that affect you unless you are trying it for the first time, as there was nothing worthwhile in the previous behavior. PageArray::sort() used to sort by the property value without regard to the page's outputFormatting state. This would mean that it could sort by the formatted date, which would be alpha sorting (of the date string) rather than date sorting. That's really not what you want. So I recently modified it so that it always sorts by the unformatted value, regardless of whether output formatting is on. Meaning, $pageArray->sort('some_date_field'); and $pages->find('..., sort=some_date_field'); should always be consistent. Please let me know if you are up-to-date with your PW version and still experiencing incorrect behavior with this.

Not yet. Lots of context and security considerations with this that are different from what they would be on the admin side, so going to approach this inputfield separately from the ones already included with PW. However, anyone that purchases FormBuilder now will get file/image fields (and a lot more) as soon as they are ready.

Is it possible that your web host moved your files from one place to another (perhaps forgetting to retain the permissions?). It could also be possible that they've got some script going through and changing permissions on you (I've seen this at Media Temple once). Also want to mention that the permissions you indicated (rw for user only) will only work if PHP is running as a CGI or PHPsuexec. Those permissions simply won't work on a lot of web accounts because Apache (often running as Nobody) needs to be able to write to the directory.

There should be no problem with using a multi langage field in a repeater. Just tried to do it here with a PageTitleLanguage field and it worked. What version of PW does it say at the bottom of the screen?

I appreciate your point of view, but understand we're coming from different preferences in this regard. As you know I'm not an IDE fan and my focus is on code best practices, not IDE navigation. I care more about program comprehension, design and code review than static analysis. I veer towards putting my time towards the practices and documentation that best serve and maintain the code base quality, as opposed to accommodating one or another automated tool for static analysis. To put it another way and use the same term you did: I would rather put my clock cycles towards the things that best help code review and overall quality than the things that maximize someone else's static analysis and IDEs. But don't get me wrong, I have nothing against supporting these tools and maximizing the experience with them. As you know, almost every class and function in PW is documented, and most with phpdoc. If time were unlimited, I would take full advantage of communicating above and beyond to everything that PhpStorm (or another IDE or tool) could want, even if it doesn't help me. And over time and within resources, I support this (@interrobang has helped out a lot recently in this area). If there are things that would be beneficial to you in PhpStorm (and you think woud be valuable to others), call them out more specifically so we can get them on paper and make it part of the roadmap and collaborate on implementation.

PHP interfaces are the way that you deal with being able to identify something that is going to have this or that known method. Basically back to this. There's not anything different built into ProcessWire that would accomplish exactly what you are talking about, but of course you could manage your own registry for a custom need. I would avoid anything that relies upon using method_exists() just because that's only telling you that a method name exists and not that it's going to have the expected arguments and return, etc.

$user->language = $languages->get('de');

If the request comes in through ajax, ProcessWire will detect it and your Process module can just return the content (JSON or whatever) that you want in the ajax. Basically, you don't need to do anything other than load the page with ajax and you should get what you want.

I agree with Pete about ServInt. I've used their service for longer than I can remember. They are the real deal. Unlike something like Linode, they are considered "managed", which I think most non-sysadmins like me need. This site (processwire.com) runs from their McLean, VA data center. Their Amsterdam data center is relatively new, but they've had a great reputation here in the US for more than a decade and sounds like they are upholding that reputation in Amsterdam too. Given that most of our traffic is from Europe, maybe I should move to the Amsterdam data center, but I'm a little nostalgic for McLean, VA (I grew up there). Most of my client sites run from ServInt as well, and they've been the only company I deal with that I never have to worry about. At the other end of the spectrum is Media Temple -- a real ball and chain, to put it mildly. As for super-budget hosting (which I sometimes need), I've had decent experiences with both HostGator and BlueHost. But I'd never put something I really cared about on this type of hosting.

Mike, maybe for next year's CMS awards we can get it setup on Form Builder, which keeps out spam with honeypots, Akismet and a Turing test. The advantage of honeypots and Akismet are that the user never knows there are spam prevention measure in place (unless they submit spam), as it all happens beyond their view. The turing test option is within their view (if you decide to use it), but it's up to the administrator to decide how simple or difficult to make the test. Recaptcha would qualify as an extremely difficult Turing test. I don't blame you for using recaptcha. If that was the only choice I would choose it in a heartbeat over an unprotected form. Having built a whole lot of forms over the years, spam would fall near the top of my list of considerations on any form, so I respect use of recaptcha even if it's become a lot more difficult to solve lately.

That's a new trick I didn't know about -- I like it. I have no idea how to do what you are asking, but guessing Soma (our resident TinyMCE expert) might.

In this case I would agree, so this particular validation (password) is at the input level (inputfield) rather than fieldtype. So even though "yo123" would be perfectly fine at the API level, Ralf was right in pointing out it's not consistent with our recommendations for passwords. It's up to the inputfield or fieldtype module author to decide on the details, but a good rule of thumb is that input validation is typically the job of an inputfield, while page data validation (API) is typically the job of the fieldtype. Fieldtype validation is more about integrity of system data, while Inputfield validation is about enforcing rules within the data that is input.

Hard to tell without having the full thing in front of me to step through live. But I'd suggest performing a redirect after a login or logout, so that you are starting with a fresh request, rather than a page pre-login with login happening behind the scenes. Seems like there is possibility for some session conflicts there, though again not positive without experimenting on the live code.

Sounds good to me. Though something to consider is that you may be unpublishing a live page from the site, which could be undesirable in many situations. Depending on the situation, it may be better to save the page and notify the editor of the error rather than fully unpublishing it.

I'm excited to announce that the ProcessWire Form Builder is now available from the DesignIntelligence bookstore: http://store.di.net/...re-form-builder I'm initially giving a 20% discount on the prices there (coupon code PWFB-BETA) because I'm still adding new things to it at a rapid pace, and feel it should still be called "beta test" (and not full price) until it's been out in the wild for a bit. However, a few of us here have been using the Form Builder on production sites for awhile already, and it's working great. But if you don't mind using a pre-release version and giving me feedback or suggestions where appropriate, then there's a nice discount for now (which will expire when we reach version 1.0). If you are wondering what the DesignIntelligence bookstore is, they are one of my long time clients and have agreed to let me provide the Form Builder through there. I actually setup and manage this online store already for them (and have for years), so feel very comfortable putting the Form Builder here. But when we grow big enough, we'll setup our own. When you get Form Builder, you'll also get access to the new Form Builder Support board (in this forum). This is where regular software updates are posted (ZIP files), among other things. So PM me when you do so that I can add you to it. Thanks for your support of ProcessWire and Form Builder!

The most basic reason is that modules are delivered to the API in a configured state where they have had configuration data populated to them by the Modules class. The module itself can use its constructor to populate defaults. Once init() is called (again by the modules class) configuration data has been populated to the module. Once ready() is called, the API is fully ready (if it's an autoload module). Basically, a lot happens between when the module is constructed and when it's delivered to you. If you just do "new ModuleClass()" then you are skipping over a sequence of events that is important for some modules and not for others. So it's a best practice to use $modules->get('ModuleClass') rather than new ModuleClass, so that you don't have to worry about what initialization does or doesn't need to occur in a module based on it's configurability, singular and autoload status. This looks great! I can't wait to try this one out tomorrow (only on mobile this evening). Nice work.

When I'm importing pages and I need to import quantities above 1 million, I usually try and limit it to 450,000 new pages at a time. It is true though that the more memory and execution time you provide, the more you'll be able to do. You also might find advantages to doing this from the API rather than ImportPagesCSV, as you've got more control over memory usage. Though I can't think of anything offhand that would be a memory concern in ImportPagesCSV, but also haven't tried it on a CSV file with 1.8 million rows. Still, major respect for at least attempting to take PW into the 1+ million page territory. Not many have done that, but you can.

This is now fixed in the latest commit. https://github.com/ryancramerdesign/ProcessWire/commit/4b5f8e7aacd56d52dd82f84211870d20492d7520 Basically was converting something to an integer that shouldn't have been converted. Only appeared to affect pages named "0", but the fix was easy and well isolated. Thanks to Nik for helping me to track it down.

Thanks Alan. Funny I thought I'd already fixed this a long long time ago. And actually I did, but turns out I just hadn't pushed it to GitHub. But went ahead and did that so should be fixed now.

I had to click like because this all sounds pretty cool. But you also lost me after "A couple of random ideas and hocus-pocus off the top of my head". Perhaps it's because I don't use an IDE, or maybe because it's the end of the day here… but other than parsing PHPDoc and traits, I have no idea what any of this is. I still need to try PhpStorm (and SlimeText)… but too much work going through the studio right now to experiment. I'm guessing this would all make sense if I had that same IDE context. Anyway, nice for some cool sounding stuff regardless. I'm hoping someone else here knows what you are talking about better than me and can chime in.

When you are in TinyMCE full screen mode, you are fully in TinyMCE and no part of ProcessWire is visible at that point. I'm guessing that there's a good chance it would be possible to add a save button to that full screen mode somehow using the TinyMCE API, but don't currently know how.

This is a good question. Both would give you a new instance of InputfieldText. However, for any module, it is preferable to use $modules->get('moduleClass'); because it ensures the module is ready for use. Modules require an init() method, distinct from the __construct(); method. When you instantiate a module on your own using new you bypass the built-in logic that determines when/if a module needs to be initialized based on it's autoload/singular settings. It's also preferable to use $modules->get('...') because new InputfieldText() wouldn't work if the InputfieldText.module file hadn't already been included. Whereas $modules->get() knows when/if to include files.

I'm not sure I understand the example. What is NubUsers and NubPages? Also something like $fields->find("page=$r->id"); is completely unfamiliar to me. It seems like there are some parts ProcessWire and some parts something else? Here's a simple example that does exactly that: foreach($page->fields as $field) { echo "<p>"; echo "Field: {$field->name}<br />"; echo "Type: {$field->type}<br />"; echo "Value: " . $page->get($field->name); echo "</p>"; }

If there are multiple categories/subcategories, would you just use the first one then? Like this: $url = "/" . $article->categories->first()->name . '/' . $article->subcategories->first()->name . '/' . $article->name . '/';

Very nice functionality here Nico! This almost begs to be a Textformatter module… But probably makes more sense as a code tool like you have it, since the short codes have to be defined somewhere and are likely to be dynamic. What it probably shouldn't be is a Process module, as it is now. Process modules are meant to be mini admin applications, whereas this is more of a markup tool. As a result, I might suggest naming it MarkupShortcodes, and defining it like this: class MarkupShortcodes extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'Short Codes', 'version' => 101, 'summary' => 'Enables WordPress like shortcodes.', 'autoload' => false, 'singular' => true ); } public function init() {} // required by Module interface, but can be blank // ... } I'd also suggest updating your example to use "$modules->get('MarkupShortcodes');" rather than "new MarkupShortcodes();" because the MarkupShortcodes class won't be in scope and in a state where it can be instantiated unless retrieved from $modules. Thanks for your good work in making this module.