ryan

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.

I agree with Pete. This sounds like you are accessing type 'Pageimages' rather than type 'Pageimage' (singular). Since you are bootstrapping ProcessWire, output formatting is going to be off. One of the side effects of that is that all image fields are treated the same (as arrays of images) rather than single images. Since you are using ProcessWire's data for output in this case, I suggest adding a single call to this before you retrieve any pages from PW: wire('pages')->setOutputFormatting(true); That will turn it on for all anything returned from the $pages API var. Or you can do it for just one page, like your banner $page: $banner->setOutputFormatting(true); Turning outputFormatting on will ensure you get the correct behavior for output. And if your image field is set to hold max 1 image, then it'll also ensure you only get that when accessing $banner->pastilla_imagen.

Okay that settles it, I will plan to rename it before we send out 2.2 press releases.

Arjen, Thanks--Let us know how it goes.

Thanks for posting about this BeavenLawrence. I didn't know about these tools, definitely good to know about.

You should also be able to do this: $p->sortfield = 'v_candidate_number';

ProcessWire doesn't allow direct execution of PHP files in its /site/templates/ directory for security. So what you'd want to do is place your ajax PHP file somewhere else, like in the site root or under some other directory that you've created. Then include ProcessWire's /index.php to bootstrap it: /somefile.php <?php include('./index.php'); // bootstrap ProcessWire if(wire('config')->ajax) echo json_encode("Hello"); When you bootstrap ProcessWire, it'll work the same as it would from your template file, except that you have to access the API variables through the wire() function, i.e. wire('pages'), wire('config'), etc. More here: http://processwire.com/api/include/

I will check out that WordPress plugin you mentioned. I think this is a good idea for a ProcessWire module, but probably not something for the core modules just because this seems like more a function of hosting, backup utilities, cron jobs, rsync, etc. The same tools we've always used for this. But one can never have too many backups ... more backups and ways to backup are always good (so long as they are secure).

Arjen, I think that ProcessWire will do exactly what you are looking for here quite easily. For your news page relations, I would echo what Antti said and suggest using either PageListSelect/PageListSelectMultiple or PageAutocomplete. Neither of those are affected by quantity, so will remain fast in the page editor regardless of how many potential page relations there are. Quantity of selected page relations is also unlikely to be a problem. When you load a page, PW doesn't load the data for that page (except for fields where the 'autojoin' option is used), so typically a page will only load with it's 'title' field. It won't load others until you specifically ask for them, like $page->body. In this manner, you can be working with hundreds of pages in memory without much worry of slowing things down. Though this is all behind-the-scenes stuff, and not something you usually need to think about. PW will make you think all the data is loaded and ready to use, but it stays selective behind the scenes to make sure it's never loading stuff you don't need at the time.

Thanks for reporting back, glad that you got it working!

Those DatabaseQuery classes are primarily so that the Fieldtypes can talk to PageFinder to construct an SQL query more abstractly. But for any situation where queries aren't being passed around to different classes, I prefer to write the query rather than abstracting it. PW isn't trying to introduce a new database layer. The database class is just PHP's mysqli with some debug logging options. For the most part I love the tools that PHP provides and don't like too many extra layers. Btw, the code sample I posted should only result in 1 query (assuming 1 page). When you say lots of queries, that makes me think you are constructing a tag cloud from lots of pages (?). You can always reduce queries by using the 'autojoin' option with a field, or by using a FieldtypeCache. But if you know how to write efficient database queries, then that will always be the fastest. Though also want to mention that it's futile to measure anything by quantity of queries in MySQL... it will execute a few hundred simple/optimized queries a lot faster than just 1 complex/unoptimized query. I used to try really hard to keep queries to an absolute minimum. But have since learned that from a performance standpoint, there are many situations where more queries will make things go faster, not slower. So measuring things by time is a lot more useful than measuring by query quantity.

Welcome to the forums Rishi. When you say "SQL Server", I'm thinking you are talking about Microsoft SQL Server, but let me know if I've misunderstood. I've never used SQL Server, so don't know what tools may be available for it, but I have to imagine there would be something like PhpMyAdmin. I think that a tool like that would do exactly what you are asking for.

If you want each of the sites to be completely isolated from each other from a search perspective, and from an admin perspective (where /site1/ is represented by the homepage (id=1) in ProcessWire) then you could install a separate copy of PW in each /site1/, /site2/, /site3/. Of course, you could use a symlink to make them all share the same /wire/ directory. Though unless you need them completely isolated from their database, you may just want to install 1 copy and use access control (in templates) to limit your editors access to the branch you want them to edit.

That will be easy to do. Lets say you've got a field called 'related_pages' that is a multi-page reference field. Here's what you might do on your 'article' template to display them: // get pages that this one is identifying as related $related = $page->related_pages; // get other pages that are identifying this one as related, and merge them $related->import($pages->find("related_pages=$page")); // output the related pages echo $related->render();

If PW is paginating any other $pages->find() / $page->children() calls that you don't want it to, add a "start=0" to your selector, for the calls you don't want it to paginate.

When you say multisite, do you intend to use a different domain to each site? Or are all of these just different sites on the same domain? And just to confirm, you are saying that you don't want the individual sites to have any cross-visibility?

Where as the tags stored? As part of the 'description' field for each image, or are you using a custom Fieldtype/Inputfield for your images? I'm going to assume they are in your description field, so you could do something like this: $tags = array(); $tagCloud = array(); foreach($page->images as $image) { $t = explode(' ', $image->description); $tags = array_merge($tags, $t); } foreach($tags as $tag) { if(isset($tagCloud[$tag])) $tagCloud[$tag]++; else $tagCloud[$tag] = 1; } ksort($tagCloud); The end result would be an alphabetically sorted $tagCloud array with each key being the tag and each value being the number of times the tag appeared. So you could output it in some manner like this: foreach($tagCloud as $tag => $quantity) { $fontSize = 10 + $quantity; echo "<span style='font-size: {$fontSize}px;'>$tag</span> "; }