ryan

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> "; }

Good to hear. Glad it's working well there--great site!

Okay I will plan to make this update.

Check that $config->debug = true; in your /site/config.php file. However, I'm not sure that'll help us here as it looks like Apache isn't even getting the opportunity to load PW's index file. I'm guessing that the file permissions are such that Apache doesn't have read access. Try doing this from your shell account: chmod og+r /srv/httpd/chrishenn.net/public_html_dev/index.php Or if you only have FTP, check the file permissions in your FTP client to ensure that you have an "r" (read access) for owner, group, and other. I'm guessing there is no read access for 'other'. Update the permission then try to load again. See if the error message changes at all. If it does, then very likely that's it (and you'll need to make the rest of the site readable to apache). Please let us know what you find.