Craig

This could be down to the IP address of your connection. The ProcessWire config variable 'sessionFingerprint' ensures consistency between IP address and user agent of the session information. This helps to prevent "session fixation" - whereby malicious users could potentially use your session cookie information to impersonate you and gain unauthorised access to the site. To determine if this is the cause, try changing sessionFingerprint to false in your site's config.php file, and carry out your VPN connection test again as you described.

I don't know what that word is; but combine it with "process" and you get a Googlewhack!

Maybe an example would help? Is this right? 1. Field "description" is used on templates "architect" and "basic-page". 2. On the "architect" template, this should be a required field. On the "basic-page" template, it is NOT required. So a field can be required on only certain templates where it is used? If that's correct, then this is possible with the development version of ProcessWire (not on the demo site in your screenshots). My attached screenshot shows this option - when editing a field from the template.

Excellent Yes, that's probably right. A more robust way might be to add the photos via an AJAX, one at a time, showing progress as it goes, and PW would only deal with one picture at a time. It was a quick win for a site that only has a handful of photos at a time, and the server it's on can do those rather quickly, and it hasn't been a problem. The screenshot is displaying the "Grid" functionality, which is part of the new default admin theme on the development branch of the main PW repository. Perhaps there is scope here to work towards a grand, unified Flickr module that offers multiple ways to access and display 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.

OK, sorry about that. Just pushed an update to Github, can you try again with the updated file?

That's strange. Which version of ProcessWire are you using?

I don't know if this will be any good for your situation or not - but I recently forked this module for a specific purpose. The functionality I used it for was to allow a whole Flickr photoset to be added to an image field, just by the URL. A text box is appended to the image list, where the URL of a photoset can be entered. When clicking Save, the module will retrieve the photos from the set, and add them to the field. The PW description field will be populated from the photo's title. Find it here: InputfieldFlickrset. It's rather simple, but you may find it useful to use or to customise as you need.

Thanks for sharing your process in such detail, and the script you used. Well done on wrangling a large volume of content together and assembling what you have

Disabling the CSRF is likely to fix some issues that can occur with sessions and cookies. Are there any other important features or quirks with the hosting environment that you're aware of? Have you used the same service before? Sometimes hosting environments do weird things with the way they handle sessions. One option to look at is to use the "Session Handler Database" module. It should be present in your PW install, and just needs Installing. However, it will be using the database now instead of local files - which comes back to the performance problem you mentioned Whenever the website is hosted away from the database on separate networks, the more likely it is that it will be slower. Template caching might help in terms of the front-end, but not for the admin pages. PW's database caching ($config->dbCache in config.php) is set to true by default, so changing that is unlikely to help. What is the reason for using a remote database in this instance? Are there any other alternatives or different configurations that are available?

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.

Unread forum posts - one of the worst things after returning from holiday! Hope you and the family had a great time, and welcome back

UK - all OK here in Chrome, Firefox and IE

<?php wire('pages')->find("template=drink, category=whisky, type=middletons, ice=1, limit=1");

It's a really elegant design - whitespace, colour, typography - all work really well together. The big banner images on the homepage are really nice as well

Looks excellent! I think I'll go and add the RSS feed to my reader

You might be over-complicating this a bit. Have a look at Pete's post here: Automatically generating new page names. As well as setting the name, you should able to set the title field in the same place as well.

Yes, Adminer is really good - it's what I use most of the time in my day-to-day SQL work. I will switch to the Windows app HeidiSQL when the database dumps are massive, or I need to do a lot of playing around with queries. But yes, I do find Adminer a lot better than phpMyAdmin for doing most things

I did this a while ago, but thought I might as well post it now with a bit of a story. The site: Learning Abilities TV. The website is essentially a YouTube front-end. I initially built the website in about 2009 using plain PHP, with a bit of help from some Flourish classes. I gave the administrator (and myself!) a basic control panel for managing the videos using Adminer Editor, and it worked quite well. This summer, they got back in touch with me regarding some additional features and a whole host of video changes. It came at a time when I had either built one or two PW sites already or had another one or two in progress. I was also on a training course through work at the time, and had to get the changes done with quite a tight turnaround. I was dreading adding a load of content and files to the existing static site. So, in the end, I spent just two short evenings in my hotel room converting the existing site to ProcessWire, and adding all the new features & content at the same time. The structure is quite straightforward. Each video is kept under a hidden parent page of /videos/. As well as title and summary, the video template has a Page reference field to link each video to one or more categories, and it has a URL field for the YouTube URL. I created a module that gets the preview image from YouTube when saving a video which just adds it to the video's Image field (but custom images can also be uploaded). The new features/downloads were catered for with the File fieldtype and sub-pages. Apart from that, it's very very simple.

Potential bug: Has anyone else noticed a problem with the inline datepicker option on the Date inputfield? With the new admin theme, the month/year selection is filling the container's width when it shouldn't - the screenshot attached demonstrates it better than I can put into words. The datepicker appears normally when configured on button click.

It's unlikely a single module will provide everything everyone will need for a login/registration system, because everyone's interpretation of its requirements will be different every time. Will users use email or usernames? What other details do you need to capture about the user? What validation needs to happen on these extra fields? Do people need to validate their email addresses, or do accounts have to be approved manually? What security roles and settings need to be applied? Where do people log in? Is there going to be a "remember me" option? What happens if they forget their password? What if there's a third-party backend system that the authentication needs to tie in to? Those are just some of the considerations I can think of based on my experience of building similar bits of functionality in the past. With the frameworks and CMSs I've used, I can't remember very many of them them that have been flexible enough "out of the box" to do what I needed without having to hack where I shouldn't, or ended up with me writing my own methods to replace theirs. To pick an example. I mainly use CodeIgniter, and have done for a long time. One of the "ready-made" libraries for users is called Ion_Auth (or something like that). In every application I've written with CI, it has never been a good fit because the application demanded either much more or a lot less; or I didn't like the way it handled a certain part. The API is already there in ProcessWire, you just have to utilise it in your template files to suit the website being developed. There really isn't much to it, and because of that, any module that did try to cater for it would either only cater for a particular type of site; or it would be overly complex and force developers into its own way of working - rather than the other way round. In lots of other systems, you have to get modules and plugins for just about everything that isn't in a WYSIWYG box, because the core system is too inflexible to let you do "stuff" any other way. With ProcessWire, the API is completely open to use how you want to use it. One of the reasons I dislike Drumlapress is for the plugin-for-everything mentality. Need to split out some images in a carousel? Install plugin X. Want to put some images in a gallery page? Install another plugin Y; and never the two shall meet (because when they do, their javascripts conflict, and the back-ends are totally separate...). Several months later you might want to put some of those on a map. Oh, that will be a separate plugin Z that doesn't really work with X or Y. And then you update Drumlapress to the next version because of a major security flaw (again). Plugin X is fine, but plugin Y breaks because it's not compatible with the latest version. And then your website is broken.

Just thought I'd add some more info to this that might be relevant. I'm currently working on a site that is a work in progress (using the PW dev branch), and I would encounter an initial page load time that was unnecessarily long (I would get a "max execution time exceeded" message) every now and then. To cut a long story short, it was the SchedulePages LazyCron issue concerning the date field having the '1970' value in the DB. The site in question currently has over 10,000 (imported) news posts that can potentially use SchedulePages. The line below seemed to be returning all of these pages, causing some internal PW page-related functions to time out due to the volume of pages involved. $published = wire("pages")->find("status<" . Page::statusUnpublished . ", publish_until>0"); My solution was just to run this query to remove the existing rows, so those pages with the incorrect values would not be picked up by the "publish_until>0" selector used in the SchedulePages module. DELETE FROM field_publish_until WHERE data = '1970-01-01 01:00:00'; After that, using the bleeding-edge dev branch of PW, I tested the publish from/until fields on some posts and the DB rows get added and deleted as they should do.

I think ProcessWire will be able to handle this fine, with a bit of custom code thrown in. Ryan created a Page Edit Per User "proof of concept" module to demonstrate how a role can be used to restrict the editing of certain pages, so this will be an ideal place to start at.

Hi Ben I've been using the same hosting for a couple of ProcessWire sites myself. The reason I found it fails is because PW is setting the session save path to a directory, but the servers are not configured to use files for sessions - they use a different method. So setting the directory does not make sense. The latest development version of PW has fixed this problem though - it does a check to ensure that the session storage method uses files, before trying to set the path. Another issue I had with this hosting was centred around the cache file that PW generates to keep a track of installed modules. I submitted a small fix for this to Ryan a while ago, which he merged into the development version.

Not at the moment, that I know of. One way you could do this, is to reduce your config.php down to some detection code, make different copies of your configs for different environments, and then just include the relevant one. if (strpos($_SERVER['HTTP_HOST'], '.local') !== FALSE) require('config.local.php'); if (strpos($_SERVER['HTTP_HOST'], 'staging.') !== FALSE) require('config.staging.php'); if ( ! defined('ENVIRONMENT')) require('config.production.php'); I haven't tested that, but I don't think ProcessWire does weird things with config.php so it should work. Give it a go