Pete

In my travels, I came across this library today: https://github.com/jamesiarmes/php-ews It has some great examples too: https://github.com/jamesiarmes/php-ews/wiki In pretty much no time at all, I'd pulled 10 months' worth of calendar entries from an Exchange server. There's much more you can do with it aside from that though - well worth a look. Also, I didn't even bother setting the version from the default (Exchange 2007) and it worked on Exchange 2013, though I've only done limited testing so far.

Your current code wouldn't be massively scalable as you're iterating every single page regardless of whether it has been previously processed or not. Your additional check you just mentioned - yes, you could (and probably should) do that with a longer selector, but I'm not sure what it's actually doing (is there a field for every language? Not sure what status$lang is doing). The extra field with the 1 in it after saving a page you've processed would mean the loop skips loading those pages that have already been processed next time you run it. I suggested the field with the 1 in purely as a quick example. The extra field wouldn't add much overhead as it's only used during this process (fields aren't pulled from the database when viewing a page unless you use them somewhere in your templates) but yes, there are other ways to do this too. If it is only to be run after every time you import large numbers of pages, you could also just jot down the last page ID and put ", id>14950" for example at the end of your selector. Lots of options

No worries - yeah, alpha on live wouldn't be a great idea

Which version of ProcessWire are you using? I'm guessing 2.x. Version 3.x has namespaces baked in so might be a better way to go to test things - everything starts off in the ProcessWire namespace I believe: https://processwire.com/blog/posts/processwire-2.6.20-and-surprise-processwire-3.0-alpha-1/#processwire-3.0-alpha-1 That topic also explains that 2.x runs in the root PHP namespace, so what you've done above is set your own namespace and then everything that follows is looking for that namespace, but ProcessWire is in the root PHP namespace (2.x) or in the ProcessWire\ namespace (3.x). So any advice will depend on the version you're using really.

Changed the best answer because Sinnut is right, scripts that are to alter things after a big import routine should only be run once, not repeatedly. Also, it might be worth having another field called something like "languages_done" so if you do your import of new pages more than once you can store a 1 in that field and skip over the pages that are already done and only do the new pages otherwise you're changing and saving the existing pages too.

I have visions of Hobbits creating sites in ProcessShire now, whilst getting drunk and causing mischief

What was the code in your ready.php file? Would help to narrow down the issue further as technically anything could go in ready.php

Yup - you're right. There are methods on the one I linked to (further up I think) to stop multiple submissions with JS: https://processwire.com/talk/topic/3633-prevent-form-resubmission/?p=35551 so not sure why I confused the issue with CSRF. The main thing is to play it safe you should use CSRF to make sure the form is submitted securely as well as some code to stop multiple submissions (ideally client side and server side, but at the very least server side as obviously JS can be disabled in the browser).

The only thing I would add to blynx's approach would be to add a CSRF token to the form so it can only be submitted once rather than someone spamming the Submit button - more on that here: https://processwire.com/talk/topic/3633-prevent-form-resubmission/?p=35585 Other than that I use almost the exact same approach in some of my own forms. EDIT: Oh, and so you don't get stuck with the default form styles/classes/markup: https://processwire.com/talk/topic/2089-create-simple-forms-using-api/?p=39436

I ended up ripping apart my code and starting again The original version was based on an older version of Fredi, so I went back and found that Apeisa was doing something totally different there now. Sure enough, adapting the newer Fredi code for my purposes worked well. It also gave me some good ideas for quick custom admin forms too but I don't think there are enough hours in the day to work on all these ideas unfortunately

Hmm... now when I save the debug error is gone, but instead of putting in a created date in the table for that file, it just deletes it!

Duh, turn debug on - it helps! Because my custom form render function was skipping some fields in certain scenarios, one of them isn't there when another one is trying to use it as a dependency. Whoops! Should have this wrapped up in 5 mins - should have realised about 3 hours ago

Setting the field to overwrite seems to skip the draft status on file fields introduced here: https://processwire.com/blog/posts/processwire-2.5.7-core-updates/ which works around my issue. What I still don't understand is why when saving the page with the file field it's no changing them from draft file status to published (putting a created date in the "created" column for the file in the DB).

Hi guys and gals I've created a backend module that essentially just loads in a template and its fields and this saves fine with file fields. My issue is on that page I've created a modal window that also does the same with some other file fields and these get created in the DB with a creation date of 1st Jan 1970, +10 seconds (so basically the Pagefile::createdTemp constant). Next time I go to view this modal window with the files in, the files are deleted: So it seems that files saved by the modal have no date set, which is confusing as the modal page is saved, whereas the parent page - using near-identical code - saves the files with a created date. The code used is this (more or less): if($this->config->ajax && (isset($_SERVER['HTTP_X_FIELDNAME']) || count($_POST))) { $subfiles= $this->input->get('subfiles') ? true : false; // If we're dealing with a file submitted through the SubFiles modal if ($subfiles) { $this->pageContext = $this->pages->get('id=' . (int)$this->input->get('subfiles') . ', include=hidden'); // else it's the parent page the modal was opened on } else { $this->pageContext = $this->pages->get($this->input->urlSegment2)->child('template=attachments, include=hidden'); } $this->pageContext->setTrackChanges(true); $this->input->get->id = $this->pageContext->id; // ProcessPageEdit expects a GET or POST called 'id' $this->pageEdit = $this->modules->getModule("ProcessPageEdit", array('noPermissionCheck' => true)); $this->pageEdit->setTrackChanges(true); $this->pageContext->trackChange($_SERVER['HTTP_X_FIELDNAME']); return $this->pageEdit->ajaxSave($this->pageContext); } Any ideas? It's really difficult to explain, so hopefully someone knows what I'm talking about

Just using a variation of this and, although I'm importing a large amount of posts and pages (pages was quite interesting - not a lot of changes required to import the tree structure as well! ) I do still of course have to go through and check all the pages just in case. This has been a huge help - thanks Ryan!

The idea of a separate URL and repo of modules that folks can set up themselves had crossed my mind, but that wasn't what I thought the OP was asking - now I read it again it was I do like the idea of this if it's easy enough to do.

Hi Thomas I don't think that's practical really mainly because there is a workflow involved with modules appearing in the modules directory. Someone actually takes the time to approve entries (and updates) I think so opening it up to private use would add more burden to the person/people managing that. If you use them across most of your sites, or you don't mind them sitting there uninstalled on the occasion you don't, why not create a Site Profile for yourself where these modules are bundled? It's pretty easy: http://modules.processwire.com/modules/process-export-profile/ So easy in fact I need to do this myself as I'm finding lots of repetition with my installations lately

Before posting, it's worth noting there is an existing section on Security relating to ProcessWire in the Docs section of this website: http://processwire.com/docs/security/ It contains several sub-pages that are worth a read as they offer code examples where appropriate and pointers for general security beyond ProcessWire.

Done. I've been woken up early by my darling daughter (5am...) so doing this on my phone means I can't set where it appears in the forum list so it's below the Jobs forum for now. I would suggest a couple of starter topics - one signposting to the existing docs and another if someone wants to kick off with an example of form validation/sanitation that we might all use on a daily basis (a simple contact form perhaps).

QuickForms? SimpleForms works too. RockettForms sounds cool too I'm actually less interested in the processing than I am of the very first part - JSON array converting to HTML output (which needs to be configurable of course for different form elements so you can use with different UI kits or file uploaders etc).

A great idea - I've been thinking about something similar for a while but just don't have the time myself so will be keeping an eye on this with interest

Welcome to the forums Tom! All kudos to Soma for the cheatsheet. Best thing since sliced bread More detailed examples are a little slower in happening but some of the items do have examples, not all. Shift and Pop are like their PHP array equivalents - shift gets the first item from the array, pop the last, and essentially removes it from the array for use right now. So your example would be something like: // Shift the first item off the beginning of the array to use right now. It's no longer in the array for this instance of the page $featured = $page->gallery->shift(); echo $featured->size(800,550)->url; // Get the footer item now for use later on - we don't want to iterate over it when displaying the other images just below: $footer = $page->gallery->pop(); // Now do some funky gallery stuff - this instance of the gallery array no longer contains the first and last items it did earlier foreach ($page->gallery as $item) { echo $item->size(400,400)->url; } // And now we can echo the footer echo $footer->size(800,550)->url; That should work, though typed into the browser and untested - let us know how you get on P.S. It is also perfectly acceptable to create two new single-image fields for featured and footer - might keep things neater in the admin for you - but this was an interesting request to explain some less-used functionality I think so I went with it

^ That's the same module I linked to But yes Beluga, you're right and that's what I would say too - the API isn't going to fundamentally change any time soon so the majority of frontend development like this module shouldn't be affected by upgrades most of the time. I would say actually admin modules have a little more chance of being affected by upgrades when larger new features are added to PW, but that's why you have to make the decision for yourself which branch you download from Github for your sites. You also have to balance this with the other responsibilities of being a web developer/admin - any updates should theoretically be checked by yourself on a non-live copy to see what the impact will be on the modules/templates you're using. This is best practice, however it doesn't always happen (I know I'm guilty of throwing caution to the wind with my personal sites anyway ). And of course when modules aren't updated or code breaks, there's a forum full of folks here to help out. I think in the absolute worst case scenario, if a module you like doesn't get updated for compatibility with newer versions of ProcessWire, you don't actually have to upgrade ProcessWire itself on the affected site. I know that, unlike any other CMS I've used, my sites are all on varying versions of ProcessWire and ticking along quite nicely which is nice.

Interesting - just the basics like registration, login, change password, email address and name etc? Isn't that what this module does: http://modules.processwire.com/modules/frontend-user/ ? I've not used it myself but seems to be covering similar features.

Not a problem, and glad it worked out for you. Sometimes the easy way is the way to go when you're on a tight timescale that can't be changed, even if you know there could be a better way. Web developers aren't supermen after all (with the exception of Ryan of course). What was the skin you used in the end, just out of curiosity? I don't really like the default one that ships with MediaWiki myself - feels a bit outdated.