adrian

Christophe, Is this on the same site that you gave me access to last week? Let me know and if you mind me taking another look - it might be the easiest way for me to decipher where things are going wrong for you.

I just added an "Upgrade Cleanup" option. Now you can easily cleanup all of the backups from the ProcessWire Upgrade module. It lets you review all the folders/files tagged for deletion and then deletes all with one click. It covers core wire folders, .htaccess and index.php backups, as well as all site module backups. I am also hoping to do some thorough testing of the entire module and get it ready for release fairly soon - is anyone out there using it regularly? Any comments/suggestions/issues? PS If you're not already using the PW Upgrade module be sure to make it one of your defaults to install on every site - it handles PW core and 3rd party site modules.

Just bumping this thread - I have updated the title and first post to now refer to PW 3.0. It would be great to start seeing the modules directory full of modules tagged as compatible with 3.0 before it is declared stable and released. Hopefully 3.x will attract a new round of developers looking to see what PW is all about - we don't want it to look like our modules aren't being updated. Even though we all know that in most cases older modules still work in newer versions of PW - this is often not the case with other CMS's.

I bet @BitPoet is spot on with his diagnosis!

Looks like I have tried to help someone with a similar situation before and they ended up using WireUpload: https://processwire.com/talk/topic/5490-hook-for-wireupload-filename-images/?p=53997 Does that help?

Ok, I just tested (got my own mapquest api key) and am getting the same error as you - this is something that will need to be dealt with before PW tries to sanitize the file - there is no file extension, so it doesn't know what it is. Either way, the error is coming before CUN gets a look in, so it won't help in this case. You could use wireUpload I guess, or maybe hook in earlier - perhaps Pagefile::filename - I'll keep digging.

Ok, I just checked with a filename over 260 characters and it uploaded ok, but didn't get renamed by CUN. Not because of the length, but because the filename didn't end in .jpg, .png etc I just used this is a test: http://domain.com/image_name.png?test=565675765675675675625625625672567256256254672567256256256725167256526725672567253625679267829647218546152412346725876651266781624582678512676567247625875267456255269759766786736738673678467836782357653675438762354675375 I can take a look at making CUN support things like this if it would help. PS - it was actually renamed, but the "test=1267686....." remained on the end.

Just something quick to try. Instead of: wire("pages")->save($pageModel); what happens with: $pageModel->save(); As for that selector - can you post what it looks like after all those variables and constants have been parsed so when can see what is actually been sent to the PW selector engine?

Hi Dave - I just tested CUN again with an API upload and it's working fine - can you please post your API code so I can take a look. EDIT: This is what I am using: $page->of(false); $page->images->add("http://domain.com/the_image.png"); $page->save("images");

It should definitely work through the API - let me take a look to confirm that I didn't break that functionality at some point, or that there isn't an issue with it and PW 3.x or anything else amiss. Will get back to you shortly.

Hi Dave, Custom Upload Names should take care of it: http://modules.processwire.com/modules/process-custom-upload-names/ EDIT: Otherwise take a look at hooking after: Pagefile::install - you can either pull the code from the hook from the above module if you'd like.

If you are going to shamelessly self-promote, you should at least provide a link to Media Manager: https://processwire.com/talk/topic/11224-media-manager/

Man - you aren't just on fire at the moment, you are ablaze Nice work - I have used Blueimp on some other projects pre-PW and loved it, so thank you!

Glad you found a solution by placing under admin, but if you want, here is a tested option. Place this in your admin.php - just replace the xxxx with the id of the Settings page. With this the autocomplete won't return any pages under Settings. $this->pages->addHookAfter('ProcessPageSearch::executeFor', null, 'removeBranchFromSearch'); function removeBranchFromSearch($event) { $response = $event->return; $responseArray = json_decode($response, true); $matches = $responseArray['matches']; $i=0; foreach($matches as $match) { if(wire('pages')->get($match['id'])->is("has_parent=xxxx")) { unset($matches[$i]); } $i++; } $responseArray['matches'] = $matches; $event->return = json_encode($responseArray); }

Just an FYI - you only need one of these - they are identical. $page->of(false); $page->setOutputFormatting(false);

I know you said you have tried using start, but I only see one "start=1". I admit I haven't really read your code carefully, but the usual issue is that you need to put "start=0" in each of the selectors that is not the main page one - in this case it would be the "then" and "older" queries. But as I said, I didn't read carefully so may be off on this one

@mr-fan, This actually should be quite simple. Add an after hook on: ProcessPageSearch::executeFor and call this method: public function removeHiddenFromSearch($event) { $response = $event->return; $responseArray = json_decode($response, true); $matches = $responseArray['matches']; $i=0; foreach($matches as $match) { if($this->pages->get($match['id'])->isHidden()) { unset($matches[$i]); } $i++; } $responseArray['matches'] = $matches; $event->return = json_encode($responseArray); } This will remove all hidden pages from the results, but I get the feeling the pages themselves are not actually hidden, just the "Settings" parent. Is that correct? In that case change "isHidden()" to check if the page is a child of the "Settings" parent - I'll let you figure that out

Did you try: $database = wire('database'); You may also need to modify the sql queries to work with PDO. If you're not familiar with the needed changes, a quick google should get you going Once you get it working, a PR for Ryan might nice

That error says that you don't have the mysqli php extension installed on the server. I can't see the source for this module right now as Github is down, but I expect it is using mysqli instead of PDO which is what the PW core now uses. So I am guessing this module needs an update to use PDO. Change any instances of $db to $database. Although I am surprised that this module uses any direct db calls. Are you sure it's actually this module that is the problem?

Disturbing read Willy! but good idea - disposable Twitter account worked a treat - I've voted!

True enough - I actually assumed it must have been an omission from the cheatsheet so didn't check!

Here a link to a search for "StatusLocked" on the PW Github repo: https://github.com/ryancramerdesign/ProcessWire/search?utf8=%E2%9C%93&q=statuslocked&type=Code That should show you what you need.

Me: Hi guys - I would like to join your community but I don't have (or want) a Twitter or Facebook account. Would you consider adding a Github and/or Google login, or even a separate registration process? PH: We don't have any immediate plans for it, but I'll sure to pass along the suggestion to the rest of the team!

They won't let me login without a Twitter or Facebook account - what is the world coming to

Glad that worked for. Just in case you don't know you can avoid the need for an entire module to add simple hooks like this. You can place the hook and method in site/templates/admin.php There are also site/init.php site/ready.php and site/finished.php files that you can make use of. More reading here: https://processwire.com/blog/posts/processwire-2.6.7-core-updates-and-more/#new-core-files-for-site-hooks