SiNNuT

I think it is still the case that you have to explicitly activate all languages when working with the api. More info and code in this thread. https://processwire.com/talk/topic/4383-how-to-set-language-active-via-api/ Like apeisa's last question suggests, it might make more sense if all langs would be enabled by default. Dunno if anything has been done about it, via a Github request or the like.

To my knowledge purifier does not run when saving textarea via api in your own forms. So you should do it yourself, according to needs. I'm not sure how it works when using PW inputfields outside of the admin(solution 1). I never done that. Should be easy to test.

You're right. Depending on what you want to allow you should use the $sanitizer options, for html maybe the purifier, which can be used via the module, or your own stuff. http://cheatsheet.processwire.com/#sanitizer http://modules.processwire.com/modules/markup-htmlpurifier/

I like it. One small thing, on smaller resolutions the model name and info flow a bit strangely around the picture:

Thanks, and likewise! Nice graphics Vrolijk kerstfeest.

It does not need to be a module. It's easy to bootstrap PW to make a export.php script that spits out the desired xml which can be consumed by other sites or services. https://processwire.com/api/include/ There is also http://modules.processwire.com/modules/service-pages/ which is great but returns json.

There is a htmlentities Textformatter active on the field you're working with? Eiter disable the formatter or turn off output formatting in your code?

It's hard to tell from the snippets of code you posted and without knowing exactly what's going on in the code. Maybe if you paste all relevant code we could have a look. On a sidenote If you do figure it out be sure to go for the limit approach. Out of curiosity i did some testing and it showed what probably was to be expected: // Method 1 echo "<strong>Method 1</strong>"; $t = Debug::timer(); $countries = $pages->find("parent=1013, limit=4, sort=random"); echo "<ol>"; foreach ($countries as $rc) { echo "<li>{$rc->title}</li>"; } echo "</ol>"; echo "<p>Found random items in " . Debug::timer($t) . "seconds</p>"; // Method 2 echo "<strong>Method 2</strong>"; $t = Debug::timer(); $countries2 = $pages->find("parent=1013"); $randomCountries = $countries2->findRandom(4); // or whatever number you need echo "<ol>"; foreach ($randomCountries as $rc) { echo "<li>{$rc->title}</li>"; } echo "</ol>"; echo "<p>Found random items in " . Debug::timer($t) . "seconds</p>"; Results in this on a set of 253 pages: Method 1 Botswana Micronesia Sint-Helena, Ascension en Tristan da Cunha Ghana Found random items in 0.0040seconds Method 2 Zwitserland Guatemala Roemenië Taiwan Found random items in 0.0690seconds It shows a pretty consistent speed difference around factor 16. Not that you would probably notice with the small number of ads.

That's strange. Just had a change to test it on 253 country pages which are all children of 1 parent page (countries with id 1013) <?php /* * countries template */ $countries = $pages->find("parent=1013"); $randomCountries = $countries->findRandom(4); // or whatever number you need foreach ($randomCountries as $rc) { echo "{$rc->title}\n"; } // result Ierland Niue Suriname Mayotte // after refresh, result Spanje Grenada Spitsbergen en Jan Mayen Jemen Seems to work a charm. Are you sure you got you're variable names and such correct?? And, this also works, and might be more efficient. Not sure if both give the same 'randomness' but they both seem to work quite nicely: <?php /* * countries template */ $countries = $pages->find("parent=1013, limit=4, sort=random"); foreach ($countries as $rc) { echo "{$rc->title}\n"; }

So of those total 8 ads how many of them are chosen randomly? And did you try my code sample?

Would something like this work? $ads = $pages->find("parent=1304, include=hidden"); $randomAds = $ads->findRandom(4); // or whatever number you need foreach ($randomAds as $a) { #do stuff } If there are a lot of children of parent=1304 be aware that this might not be the best performing option.

This afternoon i was setting up a new laptop with Win7 64bits. Having used it in the past with no problems i decided to use Wampserver 2.5 to setup my webdev environment. Having set up an existing project and a vanilla PW install i noticed that some front-end pages took quite long to respond/render. After logging in i also noticed this in the back-end. Especially opening a template edit page performed bad, with a noticeable 2 to 3 seconds delay in the response. This was not at all the case with the live site running the same code base. After some hair-pulling i discovered that it was xdebug slowing things down. In Wampserver it comes bundled with the following settings in php.ini (to which i added the max_nesting_level because the default 100 will cause problems in PW) : ; XDEBUG Extension zend_extension = "c:/wamp/bin/php/php5.5.12/zend_ext/php_xdebug-2.2.5-5.5-vc11-x86_64.dll" ;xdebug xdebug.remote_enable = off xdebug.profiler_enable = off xdebug.profiler_enable_trigger = off xdebug.profiler_output_name = cachegrind.out.%t.%p xdebug.profiler_output_dir = "c:/wamp/tmp" xdebug.show_local_vars=0 xdebug.max_nesting_level = 200 After commenting out all of the above, basically disabling xdebug altogether, my PW installs where back to normal, snappy performance. Because i don't use xdebug for debugging or profiling i'm fine with totally disabling it. This might be a tip for people experiencing bad performance in relation to xdebug. What i do find surprising is that with the above settings no actual debugging/profiling is enabled. The only thing xdebug needs to do is collect info for it's stack trace. Would this really cause such slowdowns?

Nice site, works well on my smartphone (have not seen it on a bigger screen). I would suggest adding a link back to the homepage to the logo. It's just a nice little shortcut that a lot people have come to expect nowadays.

A perfect use-case for HannaCode, indeed.

This will come in handy some day. Nice.

It's been a while since i last used ModulesManager. I think that most, if not all of it's functionality is already available by default in recent PW versions.

I'm not sure but what happens if you set $cssFile in _main.php? _init.php runs before any template files, and maybe $template->name is not yet available?

It depends on the exact needs but most of the time i use like this: http://modules.processwire.com/modules/batch-child-editor/ http://modules.processwire.com/modules/process-batcher/ http://modules.processwire.com/modules/process-page-field-select-creator/ http://modules.processwire.com/modules/import-pages-csv/ Not seldom i use them all in a project. They really go quite far as 'bulk' actions are concerned. I quite like the fact that it's not all bundled into the core features.

I don't think there are any 'ready to go' solutions for this, mainly because hiding non-editable pages in a tree based hierarchy can be problematic. I'm digging up a quite old -but still relevant i think- thread with also some contributions from Ryan. https://processwire.com/talk/topic/1176-hiding-uneditable-pages-from-users/ If this is really needed i'm wondering if it wouldn't make more sense to keep such users out of the pages tree all together, and instead build a custom page where they can view everything the are allowed to, and nothing more. https://processwire.com/talk/topic/6142-hide-page-tree-in-the-admin/ Maybe someone else has some new insights on this subject.

Hehe...rickrolling, those were the days.

That's looking pretty good.

In this case, because sender_address and reciever_address represent two different things, and you can't have regular fields appear more than once in a page (template), i would just make two fields. To make this easy and fast in the site creation process you can clone a field from when you're editing it. A pic says more than a thousand words: When the project at hands needs it and/or you want to have even more options there are also some commercial modules, made by ryan himself, that can make your life even easier: https://processwire.com/api/modules/profields/textareas/

Also note that while we discuss field/template context, Ryan -the ProcessWire(PW) creator-, has been updating the development version of PW to allow for even more field properties to be set on a per context (template) basis. Up until now this is limited to: field label, description, visibility, column width, and required state. Read more about this here: http://processwire.com/blog/posts/processwire-2.5.7-core-updates/#field-template-context-now-available-for-any-field-property Be sure to keep an eye on the blog posts, and/or the ProcessWire Weekly, and/or subscribe to the PW newsletter.

It definitely sounds kinda intriguing. And i like the way they leverage Github to basically host a bunch of markdown files that make up your site, and surround them with some tools/'artificial intelligence' web developer to do the heavy lifting. Maybe some kind of Jekyll/Octopress on steroids. *bookmarked*

You can get there via the fields menu or directly from the template menu: