LostKobrakai

You should take a look at this: https://processwire.com/talk/topic/9879-fieldtypereference/. It's essentially doing just minor things more than you seem to imagine.

Umlauts are not supported (see processwire's page-name restriction) and somewhere on the forums did Ryan give a statement about that fact, but I don't remember where it was.

1. is easy: If there's no corresponding template.php for a template, than nobody can see it from outside. Furthermore, the only thing a search engine can crawl is the html you're outputting in your templates, so those children could even have template.php files, but not output markup and e.g. redirect to 404 on direct access. 2. If SEO is important I'd go with a one-page-per-asset approach, so you've all the flexibility to show and use those assets in the way you want. 3. Drafts is still an issue, that I doubt will be fully solved until a core solution is introduced.

If you can recreate the issue, could you please post a step-by-step guide to it or upload a site-profile of your installation?

It's certainly possible, but there's no fieldtype to support that. The standard file field might be sufficient to upload the zip file, but as soon as the zip is extracted with folder structure it won't display anything. If one doesn't need those files to be visible/manageable in the backend than all the tools php provides are available.

The url field should give you the complete relative url to the image. foreach($images as $image){ echo "<img src='$image->url' alt='$image->description'>"; }

I've not worked on a multi language system for a bit of time and I now noticed, that users do get multi-language names as well. The ability to "activate" users per language might be quite nice, but having to manage usernames in multiple textfields seems like a big invitation to human failure.

Sure, but from some blogposts one could think this is the new holy grail, but it still has all the problems of other preprocessors in terms of providing new alternative syntaxes to writing css. The speed issue is so true, even libsass is sometimes quite slow, couldn't work with the ruby one anymore.

I'm not sure, but if I understand the PostCSS thing right, than it's just a css parser per se and nothing more. So one can really only evaluate the use-cases for it's plugins. I've yet to grasp why so many people think this is different to other preprocessors except for the fact it's more customizable.

-X is not a command, maybe you want a "curl" in front of it.

If methods are really meant to be used only by a single PageType, isn't it better to go the inheritance route? The thing that always bugged me about the hooking way is, that a added methods are available to all Pages, which is almost never what I want it to be. Maybe the conditional hooking will solve this. It does solve the issue.

@teppo There are surely issues with this type of system, but actually I was thinking about something even more rigid. I thought of having an additional field like name, that is required to be set before creating a page, that's added to the PageAdd form, is unique and does prevent saving when invalid / empty. But I think this would only be useful for a unique username and unique email situation for users. I cannot think of other cases, where such a system would be beneficial as well. Maybe I'll just stick to the email-as-name tactic as I've currently no real need for usernames.

Is there anything those different website should share in terms of data? If not (or only few) than it's probably the easiest do just use three different pw installations and if needed share data via something like the ServicePages module. Otherwise I suggest taking a look into the Multisite and the Dynamic Roles modules. They would allow you to setup the structure you're envisioning in a single pw installation with some shared and some exclusive data. Design is by default set up on a by-template basis, so each subdomain could simply use their one templates. If needed you could also implement custom logic to reuse templates between subdomains and only adjust the styling depending on the location.

The code you posted is a simple loop over children, which has nothing to do with repeater-fields. This should work on a template, where pagination is enabled. <?php $paginatedChildren = $page->children("limit=9"); $pagination = $paginatedChildren->renderPager(); ?> <div class="container"> <div class="row"> <?php foreach($paginatedChildren as $c) { ?> <div class="col-xs-6 col-md-4"> <h3><?php echo $c->title; ?></h3> <p><?php echo $c->festivals_body; ?> </p><hr> </div> <?php }?> </div><!-- closing row --> <?php echo $pagination; ?> </div>

That's why I specifically added the "like the name field" part. Having a field required by this checkbox does not prevent a page/user from being created/saved, which is what I want to happen.

I'm just experimenting with an unique email per user system. Now I wondering if there is a way to have a required field like the name field? Required in that the page cannot and will not be saved without the email field being uniquely populated. To ensure uniqueness I'm currently using a fork of FieldtypeTextUnique.

+1 for this request. While it's always in the hands of the dev to prevent malicious access to content, even if someone does fiddle with some id's, it's still an added layer of obstruction. This can for example be handy when using id's on the frontend site, like as urlSegments.

$copyYear doesn't need to be an integer. It's only compared to a string value, so it can just stay in a text field.

I know this may be more of a "Pro" feature right now, but PageTables could really sport the AJAX editing option like ListerPro, maybe even just for enabled fields. In some cases the PageTable might be quite narrow where only a small select option should be editable and a field with a more spacious inputfield should not be editable.

I'd suggest you read the first three of those linked topics here: http://processwire.com/api/multi-language-support/ The URL one does explain how you'd get those urls without doing anything to the .htaccess file. The first one does explain how the internationalization of static texts in templates work and the middle one is about how you can setup the fields for your dynamic content, so everything is language aware, too.

The import methods does not search for pages. It does import either WireArrays of WireData objects (like Pages) or a simple php array of WireData objects. So it's not so important how those objects are group but the objects must be of the right type when importing.

One notable difference between setOutputFormatting() and of() is the difference in return value. // setOutputFormatting is chainable and returns the page object $page->setOutputFormatting(false)->set("field", "value")->save(); // of() is not chainable, but does return the previous OutputFormatting status $oldOf = $page->of(false); $page->set("field", "value"); $page->save(); $page->of($oldOf);

You can check this by enabling "view system templates" in the template overview. This should show those automatically created templates. Edit: you need to literally add "repeater_" in front of thr name.

Maybe you need to set "include=hidden".

$list = $page->siblings("content_type!=6"); $list->getPrev($page); $list->getNext($page);