Craig

I would look at using the WireCache functionality.
You can find more about that here: https://processwire.com/blog/posts/processwire-core-updates-2.5.28/

I've found with the field/template import/export, it is sometimes necessary to do it twice. Once to create the entries (skipping the relationships/family settings), and the second time to apply the correct family settings.

Yes, on the Setup > Templates page, you have the ability to Import/Export the templates in the same way as fields.
Export then import your fields first, and then do the same with templates. The screen on import will give an overview of the actions being carried out before you commit to saving the changes.

I have this working as expected on a site I'm currently building, on 2.5.28 dev. Have you followed each step from the instructions?

Hi teo74, welcome to the forum
You are sort of there with InputfieldPageListSelectMultiple - but alone, that is just one method of providing the visual input part of what you need. What you need is the Page fieldtype, which will give you the option of using Page List Select inputs, amongst others, in the backend.
The Fieldtype is how the data is stored, formatted and linked internally, and the Inputfield is how this field is presented and manipulated in the backend by a user.
Have a look at this video - Using the Page Fieldtype - to get an idea of how it all works.
In summary:
Create a new field (called 'related', perhaps?) using the Page fieldtype. Configure it for the types of pages you want to select, and how you want the selector to look (which Inputfield to use) Add it to the template where you want to choose related pages. Edit those pages and choose the related pages In those pages, you can get the related ones, and display the links, by doing something like this in the template code:
<ul> <?php foreach ($page->related as $relatedPage) {     echo "<li><a href='{$relatedPage->url}'>{$relatedPage->title}</a></li>"; } ?> </ul>

Ah, yes, that changes things
I haven't really used repeaters, but I think this might work - just treat each repeater item like a page:
<?php $entries = wire('pages')->find("template=story"); foreach ($entries as $entry) { echo "<br>Checking checkbox on {$entry->title}...<br>"; foreach ($entry->tests as $test) { if ($test->old_check == 1) { $test->of(false); $test->new_check = 1; $test->save(); echo "Converted {$test->scenario}<br>"; } } }

Hi Tom!
There are indeed several ways to manage this!
Your first choice to set the visibility to hidden would be handled by creating a custom module. Your code would hook into the page creation/page save events, check the template for "event", and set the page to hidden. There are several modules in the Modules directory that will hook into the same place which you could look at for examples on how to do it. One that springs to mind is the Date Archiver module.
I don't use MarkupSimpleNavigation, but I think it would be able to support what you want somehow. If you check the documentation, it seems you could do it one of two ways:
1. Use the "selector" configuration option. You might be able to specify "template!=event".
2. It looks like you could use "nav_selector" to customise the output for that section of the website.

In this situation I would either cache the list of years using something like MarkupCache, or use the Date Archiver module to have an additional layer in the page tree for the years, which would be quick and easy to loop through.

You would link multiple users in a similar way - new Page field called users, configured for "template=user", and use the "Multiple pages (PageArray)" option on the field Details tab, and add to the event template. The difference in code would be this:
<?php // Loop through all users added to the page. foreach ($page->users as $u) {     // Use $u (or whatever you like) but not "$user" - it is a ProcessWire system variable (current logged in user).     echo $u->name . " is a member of this event.<br>"; } ?> Locations with the same name would not be permitted to have the same direct parent - so the name would have to be changed when adding it. Each page still has its own ID, name and path which can be used to identify and load them within code. For example:
ID: 1042
Name: concert-hall
Title: Concert Hall
Path: /locations/concert-hall/

The ID cannot be changed, but the name can. And the path is built up based on the name of the page and the names of it's parents.
By default, names are automatically generated from the title field value, but can be overridden if necessary, generated yourself, or automatically using datetime values.

 

Hi xvda
Please feel free to have a look at the code for my LoginPersist module, where I create a hook for Session's authenticate() method for that request. I store a temporary password for the user in the session, and in my hooked authenticate() I check the temporary one rather than the one in the database, and return true if it matches.
I've also created a TwitterLogin module (like the Facebook one you're using) using the above method, but it hasn't been fully tested yet. You're more than welcome to have a look at it though.

Hi John. ProcessWire will be able to handle all of that rather well This is how I would think about doing it...
Students and users
If you want some projects to only be accessible to students, then certainly add students as users. You can extend the "user" system template with additional fields for your extra data. Create a new role "student" to add to these users and to control permissions.
User
title (For full name) name (permanent ProcessWire field - use this for student ID, perhaps?) programme (FieldtypePage, for programme of study) year (FieldtypePage or FieldtypeInteger)
Projects
  title body (FieldtypeTextarea) images (FieldtypeImage. For images only) files (FieldtypeFile. For video or audio) students (FieldtypePage. Allow multiple. Use a custom selector value: template=user, roles=student) programme (same FieldtypePage as above) Each project would have their own page under a parent "Projects" page.
For the Programme of Study, presumably this is just a simple lookup/dropdown list? A common way of doing this in ProcessWire is to create a settings or configuration template (with minimal fields - usually just title) and (hidden) page tree. E.g.
/settings/programmes/ |-- Programme 1 |-- Programme 2 |-- ... You can then create a Page field which will use something like template=settings, parent=/settings/programmes/ to allow selection of the programmes of study for both users and projects.
This makes it incredibly easy to generate a front-end filter for the programmes and build a page query selector string to find projects that belong to the programme of study.
Depending on the way you want to format or structure your year of study you could use the same process. But if it's just going to be the year in numeric format (like 2014) then you could just use an Integer type rather than a Page.
With that structure, there shouldn't be any performance issues.

ProcessWire users can be front end users too, and that might be a good way to do it. But the admin will have to create users, and then add the user to the gallery using a Page reference field.
Perhaps a more simple way of doing it would be like this:
Create two new Text fields called login and password, and add to the template you use for the photo gallery pages. The admin can set and view these in the CMS. When the page is viewed, your template code should check the session or a cookie for presence of a certain value based on the gallery's name. If the value is not set, then present them with a login form only. When the form is submitted, check the submitted details against the page's login & password values.  If they match, create a new session or cookie entry based on the gallery's name, and set a value (like "true" or 1 - just to indicate that the user can view the page). Redirect back to the photogallery page. Because you have set the session or cookie value, your check from step 3 above will be true - so instead of the password form, show the photos.

I think the problem here is down to variable scope. When the code was in your template, it had direct access to ProcessWire pages using the system variable $pages. When you put this inside a function, it's no longer available.
The way you can fix this is to change it to this:
function kiddiMenu(){ $current_page = wire('pages')->get("/planning-your-journey"); $homepage = $current_page; $children = $homepage->children; echo "<ul class='' >"; foreach($children as $child) { $class = $child === wire('page')->rootParent ? " class='active'" : ''; echo "<li><a$class href='{$child->url}'><span class='l'></span><span class='r'></span><span class='t'>{$child->title}</span></a></li>"; } echo"</ul>"; } The difference is that $pages and $page (the variables that are out of scope) are replaced with global function calls which return the same thing, and are available from anywhere in ProcessWire.
The ProcessWire system variables are listed here - variables. Any time you're in a function or a module, just replace them with a call to the wire() function with the name as the parameter. E.g. wire('input') for $input.

It looks like it's something to do with the encoding (or not) of the accented characters in the "description" entry.
I set up an RSS template with the same code and content you provided, and it worked OK for me. In order to reproduce the problem, I had to save the file with an encoding that wasn't UTF-8 (for me, the other main choice is ISO-8859-1).
So - try saving your template file with UTF-8 encoding and see if that solves it.