ryan

This doesn't work because $page->children is an array of pages (PageArray), not a Page. Think of it like a boat carrying a bunch of people. The boat can't have children, but the people in it can. I'm also not sure $page->children->children would be all that useful, because they would have lost all sorting context. However, I'm only thinking in context of the sites I make and know everyone has different needs. So if you want to have something equivalent to $page->children->children, it would be $page->find('id>0'). But I would suggest using Soma's examples as they are more specific to a template, and it's better to be specific. Nearly any search that gets passed through a selector is fully indexed, so it doesn't have to scan the whole site. If you put in "template=video" it [mysql] heads straight to an index of pages with the video template, so it's not scanning or considering other pages. You'd want to limit that if you were using the video template elsewhere in the site and didn't want videos from one branch getting mixed in with videos from another. However, if you know where you are using the video template and aren't going to be using it on other branches in the site, there's no speed advantage to performing the search within a parent $page rather than just using $pages->find() to do it. Technically, there's slightly more [minor] overhead doing a $page->find() than a $pages->find() because it's adding a lookup table to the search that may or may not need to be there.

Robert, what I link to actually isn't the dev branch. I maintain a separate dev branch locally and then updates go into the master branch after I've tested them to make sure they are working properly. If I'm working on something major, I have that dev branch at GitHub as well so people can switch to it to help test. But I get what you are saying about tags and sending downloaders to that. I'm a little mixed about that because I'm always fixing, optimizing and improving things and would hate to send people to something that is something older than the latest stable. But I suppose I could still do that with tags like 2.1.1.2 or something like that, and then update the download link and version number in the source every time I push a commit. This would at least enable more easy communication of exactly what version someone is using when an issue comes up. I'm willing to give it a try. But that leads to a question: how do I get tags to go to GitHub? I added tag "v2.2.0" to PW as soon as I released the version a few weeks ago, but that tag has yet to show up anywhere at GitHub. Yet if I type "git tag" locally, I can see it. Perhaps I haven't attached it to a specific commit? I need to read up on tags. As a test, I renamed the old ProcessWire 2.0 repository from "ProcessWire" to "ProcessWire-2.0". It worked, but GitHub is telling me "unexpected bad things" and I usually try to avoid unexpected or bad things: They are saying "we" will not setup redirects, but they aren't saying it can't be done. It seems like that leaves open the possibility that I can setup redirects somehow? (maybe just wishful thinking?) How do I update my local repository to point to the new location? What instructions should I give others to update their location? I'm going to test this all with the v2.0 repository before attempting with the 2.2 repository. Thanks, Ryan

Actually abstract classes / interfaces are there to help avoid messes. You could get along just fine without them, but using them keeps things in order and lets you make assumptions about objects rather than having to check that they meet some criteria on your own. If you say that something has to meet an interface and it doesn't, then PHP throws a fatal error. That helps to avoid messes before they start. There's not much more to it than that. The terms "abstract" and "interface" sound technical, but luckily the concept is simple.

I think that your naming convention sounds good. You could find all modules like this: $paymentModules = $modules->find('className^=Payment'); However, your idea of using an abstract class or an interface is something I think you'd also want to do. That's because you are going to want all of your Payment modules to adhere to a specific interface so that all will have a processPayment() method, for example. An abstract class and an interface are basically the same thing except that an abstract class can provide some code implementation (functions) and declare other functions as abstract, where the descending class has to provide the implementation. Whereas an interface provides no implementation, it just defines what the required functions will be. Any functions outlined in an interface would be the same thing as an abstract (no-implementation) function in an abstract class. Neither an abstract class or an interface can be instantiated to an object, so they mainly define requirements for other classes that either extend the abstract class or implement the interface. Here's an example: interface PaymentInterface { /** * Process a payment and return true on success or false on failure * */ public function processPayment($amount); } class PaymentModule extends WireData implements Module, PaymentInterface { public static function getModuleInfo() { return array(...); } public function init() { } public function processPayment($amount) { // a bunch of code here to process a payment return true; } } Since the module above adheres to both the Module and PaymentInterface interfaces, we know that it can be used in the situations where we need it. You know it will always have a processPayment() method. So once you've found your Payment modules, you'd want to make sure that they also implement the interface before using them: if($someModule instanceof PaymentInterface) { // $someModule can be used as a payment module }

Glad that you got it working. Those session files don't need to travel with the site, so I would suggest just deleting everything in /site/assets/sessions/ and /site/assets/cache/Page/ when migrating from one server to another. Though if you use the ProfileExporter to migrate, you don't need to do this.

This is really coming along nicely. You have me seriously thinking that I need to switch from UbertCart to ProcessWire (rather than Shopify) for the store that I manage.

That's a good question, thank for asking. I've been meaning to post some updates to this. I've added the new files to the original list, below: Core /wire/core/Fieldtype.php Inputfield Modules /wire/modules/Inputfield/InputfieldEmail.module /wire/modules/Inputfield/InputfieldFile/InputfieldFile.module /wire/modules/Inputfield/InputfieldImage/InputfieldImage.module /wire/modules/Inputfield/InputfieldPageListSelect/InputfieldPageListSelect.module /wire/modules/Inputfield/InputfieldPageName/InputfieldPageName.module /wire/modules/Inputfield/InputfieldPassword.module /wire/modules/Inputfield/InputfieldSubmit/InputfieldSubmit.module /wire/modules/Inputfield/InputfieldTinyMCE/InputfieldTinyMCE.module /wire/modules/Inputfield/InputfieldURL.module /wire/modules/Inputfield/InputfieldPageAutocomplete/InputfieldPageAutocomplete.module Markup Modules /wire/modules/Markup/MarkupPageFields.module Language Support Modules /wire/modules/LanguageSupport/LanguageSupport.module Process Modules /wire/modules/Process/ProcessForgotPassword.module /wire/modules/Process/ProcessLogin/ProcessLogin.module /wire/modules/Process/ProcessPageAdd/ProcessPageAdd.module /wire/modules/Process/ProcessPageClone.module /wire/modules/Process/ProcessPageEdit/ProcessPageEdit.module /wire/modules/Process/ProcessPageEditImageSelect/ProcessPageEditImageSelect.module /wire/modules/Process/ProcessPageEditLink/ProcessPageEditLink.module /wire/modules/Process/ProcessPageList/ProcessPageList.module /wire/modules/Process/ProcessPageSearch/ProcessPageSearch.module /wire/modules/Process/ProcessPageSort.module /wire/modules/Process/ProcessPageType/ProcessPageType.module /wire/modules/Process/ProcessProfile/ProcessProfile.module /wire/modules/Process/ProcessField/ProcessField.module /wire/modules/Process/ProcessHome.module /wire/modules/Process/ProcessList.module /wire/modules/Process/ProcessModule/ProcessModule.module /wire/modules/Process/ProcessPageTrash.module /wire/modules/Process/ProcessPageView.module /wire/modules/Process/ProcessPermission/ProcessPermission.module /wire/modules/Process/ProcessRole/ProcessRole.module /wire/modules/Process/ProcessTemplate/ProcessTemplate.module /wire/modules/Process/ProcessUser/ProcessUser.module Admin Theme /wire/templates-admin/default.php Note: I've removed ProcessLanguageTranslator, as I was incorrect about it having translatable phrases before. With a name like LanguageTranslator you'd think it would though? B)

Pete, I've added support for page-publish permission. To use it, grab the latest commit and then create a new permission in Setup > Access > Permissions, called 'page-publish'. Once PW sees that there, it'll start to use it. So if you create a role that has page-edit but not page-publish permission, you should get behavior consistent with what you mentioned above. Please test it out and let me know how it works for you. Field-level access is something that is planned, where you can limit edit access to a field by role. But probably not till version 2.3.

It's okay to rename things too. Renaming a field is pretty straightforward, as you can do that right on it's main edit screen. Renaming a template can be done from the 'advanced' tab of the template editor. Renaming a page is done from the 'settings' tab of a page.

I like that feature too, but something we'll probably accomplish with an optional module that bolts on to it. Emails getting fired off every time someone responds to a comment could get out-of-hand on a large comment thread. So it's one of those things that really has to be built very carefully (which we can do).

Juan, we definitely need help with a real Spanish language pack. I don't speak Spanish and have no idea if the one I was working on is even remotely close to how it should be (I'm guessing it's not). I mainly started with a Spanish language pack because my wife speaks a little Spanish and I thought I could impress her. But I don't think she knows Spanish well enough to critique my language pack anyway. If you would be interested in making one, your help would be greatly appreciated! I'll be happy to send my latest Spanish language pack files over to you if it's helpful to use that as a starting point. Thanks, Ryan

Soma this sounds like a different issue than userAuthSalt, because you could expect to see an error message if the authentication was failing. If you aren't seeing any errors, then it sounds to me like there's a flow control issue with the Process module. Can you paste in the exact URL that appears in your address bar when you are on the login page? Is the URL that appears after you submit the form exactly the same? Also note that the URL should always end with a slash here. The only other thing I can think of: have you possibly turned on template caching with the admin template? (I doubt it, but just checking).

Michael, have you tried changing your dates in the CSV to the d-m-Y format? I believe it should import then. The FieldtypeDatetime module sanitizes any string input with PHP's strtotime() function. That function accepts d-m-Y format if you use dashes in the input (rather than slashes).

I shouldn't be angry with WordPress, as this TimThumb plugin is something completely separate from it and like you've mentioned, common in several other CMSs too. But there just seems to be a never ending supply things that can happen in WordPress like this. I suppose that's due to the popularity of the platform more than anything else. But even if it's not the fault of WordPress, I always worry about the clients that I have using it.

Nice work Achabany, this looks great. I will aim to get a similar look with the module.

I just lost the better part of a day fixing a client's WordPress installation that had been hacked, turning their web sever into an IRC file distribution hub, a DDOS farm and peppered with exploit scripts all over the place. Despite running the latest version of WordPress, apparently the site theme had a plugin (TimThumb) with an exploit that lets folks turn your server into a playground. Thankfully the hackers that did it weren't malicious and didn't want anything with the sites on the server, just the resources and bandwidth. So the site never had to come down, though the server load and bandwidth usage was through the roof for a couple days. This may be old news for some, but I don't use WordPress much. If any of you are running WordPress anywhere, do yourself a favor and scan for TimThumb, even if you think everything is up-to-date. I did it like this: grep -r allowedSites wp-content/* If it turns up files like timthumb.php or thumb.php (or anything else), double check that they aren't vulnerable. Here's some more info: http://www.exploit-d...b-exploitation/ http://markmaunder.c...rdpress-themes/ http://wordpress.org...bility-scanner/ While you are in your site files, do this grep as well: grep -r base64 ./* A lot of the scripts that I had to remove today were base64 encoded and eval'd, and this helped to track some of them down (among other searches). This will turn up some legitimate WordPress stuff too, but it's relatively easy to tell the difference. Assuming TimThumb was their entry point, they did a good job of hiding it. All the exploit code was elsewhere in other themes, plugins, cache files, hidden directories and more. Since I lost so much time to WordPress and this issue today, I just wanted to post it in here in case anyone else runs into the issue. I'm just hoping I found everything...

Actually LanguageSupport includes a setLocale setting, but it needs to be defined with the language pack. If you go into Setup > Languages > [your language] > add translation file > Then paste in: /wire/modules/LanguageSupport/LanguageSupport.module You'll see a field come up where you can set the locale. Maybe I should have this disabled by default? (if the translation doesn't define it)

Of course, but PW doesn't get involved in this stuff (it does no JS output on it's own for the front-end of your site). But you can add on whatever JS functionality you want to it.

We've got a queue of changes and improvements planned for the Comments module, and improvements in the area you've mentioned are part of it. The comments output/processing comes in two parts, $page->comments->render(); and $page->comments->renderForm(); Usually you call renderForm(); after render(), which means that the comment form doesn't get processed until after the list of comments has already been rendered. Of course, you could reverse that and render the form first and then get your comment in the list. But that doesn't solve the double post issue, which we really need a redirect to do. So the recommended way to handle it now is to $session->redirect('./'); after a comment is submitted. ProcessWire can't do this for you just because it doesn't know if you are calling upon it before or after you've started output (depending on the way you structure your templates). So it's playing safe by not attempting any redirects and instead lets you maintain control over how you want it to proceed. // get comments before any output sent $list = $page->comments->render(); $form = $page->comments->renderForm(); if($input->post->text && strpos($form, 'success')) { $session->redirect('./'); } // ... later on when you are sending output echo $list . $form; More here: http://processwire.com/api/fieldtypes/comments/ Also note the default behavior and markup created by the comments module was always intended as just an example. It's meant to be iterated and handled like pages are, where you make your own comment markup and form. But I usually go the easier route and just use the built-in 'example' output.

Thanks for the kind feedback Wortell. Glad you are enjoying ProcessWire and thanks for your interest in contributing too--always welcome and appreciated.

The default profile is meant as a clean starting point, though it's also not completely blank. For me, it is at least a much better starting point than nothing, but i know others may prefer something even less. In ProcessWire, you can't have a completely blank stating point because some built-in pages need templates and fields (like admin, home and 404). But here's how you can get to a more blank state: 1. Open the 'trash' page in the page list, then click 'move' to drag these 4 pages to the trash: /about/ /templates/ /sitemap/ /search/ Then empty the trash. This will leave you with just your homepage, 404 page, admin, and trash … all of which are required in any PW installation. 2. Now you want to go to Setup > Templates. Delete the 'sitemap' and 'search' templates, unless you want to keep either one of them. Edit the 'basic-page' and 'home' templates and remove all the fields except for 'title'. Save. 3. Go to Setup > Fields, and delete all the non-system fields except for 'title'. 4. Delete all the files in /site/templates/ except for admin.php and home.php. Following that, you are starting from the most blank state possible in ProcessWire. Now start creating your own templates and fields, and note that you'll very likely be re-creating the fields you just deleted --they are fields that tend to be needed on most sites. That's why I think it's a little better to start with the included profile and rename/replace things as you go--it saves time.

I just tried to reproduce it here, changing my memory limit to 16M and restarting apache. Everything seemed to run fine at 16M. Then I tried again, except this time changing it to 8M -- then I could get memory errors. While I couldn't get memory errors at 16M, I'm guessing it just depends on your PHP version and perhaps other factors on the server. But I agree that 16 or 30 is probably just too low. 32M would probably be the minimum I would use. The default PHP 5.3 setting (128M) is ideal. If you are using PW for large data imports and such on a dev server, you might even want to go higher (the higher the limit, the more pages you can hold in memory).

Apeisa is right. Change this line: .CommentForm_text { clear: both; } To this: .CommentForm_text { clear: left; } I will update that in the basic profile (thought I had, but now see I didn't).

Jan, thanks for letting me know about the error. Do you have a calendar URL I could test with to reproduce it? Feel free to PM to me if it's something you don't want to post publicly. I'll be happy to fix this and update the source code.

page-view permission is supposed to be required of all roles (i.e. an implied permission). Though in testing, I see that it's possible to create a role without giving it page-view permission -- that's a little bug that needs to be fixed. There aren't supposed to be roles without page-view permission just because they wouldn't be very useful. I'll add in some extra code to force this permission to always be present.