Hi All,
I'm using 2.3.3 for one of my client's sites. Its been in place for several months with no difficulties. Today I tried to upload some photos through the CMS for them to use in blog entries, and I no longer have access to that section of the site. When that page loads SS displays an error message. All other pages, both external and admin, seem to work perfectly. The error message is below. Does anyone know how I can fix this?

[Notice] Trying to get property of non-object
GET /admin/assets/

Line 404 in /home/smadmin2/public_html/sapphire/filesystem/Folder.php
Source

395 if($object->$fieldName != NULL) $usedFiles[] = $object->$fieldName;
396 unset($object);
397 }
398 } elseif($joinClass == 'Folder') {
399 // @todo
400 }
401 }
402 }
403 foreach($usedFiles as $file) {
404 $where .= $file->ID . ',';
405 }
406 if($where == "") return "(ClassName = 'File' OR ClassName = 'Image')";
407 $where = substr($where,0,strlen($where)-1);
408 $where = "`File`.ID NOT IN (" . $where . ") AND (ClassName = 'File' OR ClassName = 'Image')";
409 return $where;
410 }

Trace

* Folder->getUsedFilesList()
Line 465 of Folder.php
* Folder_UnusedAssetsField->getAssetList()
Line 439 of Folder.php
* Folder_UnusedAssetsField->getChildren()
Line 452 of Folder.php
* Folder_UnusedAssetsField->FieldHolder()
* call_user_func_array(Array,Array)
Line 408 of ViewableData.php
* ViewableData->XML_val(FieldHolder,,1)
Line 74 of .cache.home.smadmin2.public_html.sapphire.templates.TabSetFieldHolder.ss
* include(/tmp/silverstripe-cache-home-smadmin2-public_html/.cache.home.smadmin2.public_html.sapphire.templates.TabSetFieldHolder.ss)
Line 354 of SSViewer.php
* SSViewer->process(Object id #489)
Line 773 of ViewableData.php
* ViewableData->renderWith(TabSetFieldHolder)
Line 62 of TabSet.php
* TabSet->FieldHolder()
* call_user_func_array(Array,Array)
Line 408 of ViewableData.php
* ViewableData->XML_val(FieldHolder,,1)
Line 70 of .cache.home.smadmin2.public_html.sapphire.templates.Includes.Form.ss
* include(/tmp/silverstripe-cache-home-smadmin2-public_html/.cache.home.smadmin2.public_html.sapphire.templates.Includes.Form.ss)
Line 354 of SSViewer.php
* SSViewer->process(Object id #510)
Line 773 of ViewableData.php
* ViewableData->renderWith(Array)
Line 982 of Form.php
* Form->forTemplate()
Line 424 of ViewableData.php
* ViewableData->XML_val(EditForm,,1)
Line 983 of ViewableData.php
* ViewableData_Customised->XML_val(EditForm,,1)
Line 34 of .cache.home.smadmin2.public_html.cms.templates.Includes.AssetAdmin_right.ss
* include(/tmp/silverstripe-cache-home-smadmin2-public_html/.cache.home.smadmin2.public_html.cms.templates.Includes.AssetAdmin_right.ss)
Line 354 of SSViewer.php
* SSViewer->process(Object id #26)
Line 773 of ViewableData.php
* ViewableData->renderWith(Array)
Line 484 of LeftAndMain.php
* LeftAndMain->Right()
* call_user_func_array(Array,Array)
Line 408 of ViewableData.php
* ViewableData->XML_val(Right,,1)
Line 983 of ViewableData.php
* ViewableData_Customised->XML_val(Right,,1)
Line 71 of .cache.home.smadmin2.public_html.cms.templates.LeftAndMain.ss
* include(/tmp/silverstripe-cache-home-smadmin2-public_html/.cache.home.smadmin2.public_html.cms.templates.LeftAndMain.ss)
Line 354 of SSViewer.php
* SSViewer->process(Object id #26)
Line 166 of Controller.php
* Controller->handleAction(Object id #7)
Line 129 of RequestHandler.php
* RequestHandler->handleRequest(Object id #7)
Line 122 of Controller.php
* Controller->handleRequest(Object id #7)
Line 277 of Director.php
* Director::handleRequest(Object id #7,Session)
Line 121 of Director.php
* Director::direct(/admin/assets/)
Line 118 of main.php

Anyone? I've read everything that I can find on this, and it sounds like the problem is that files were added via FTP instead of through the CMS, but that doesn't make sense to me, and even if its the case I'm not sure how to fix it.

--
Thanks,
Chris

lenwood,
I just had this problem as well. I uploaded images via Dreamweaver and it writes _notes folders to the directories you upload files in to maintain sychronization files in. I deleted these folders as well as their entries in the database via phpMyAdmin and then tried the site in another browser and I got access to the Files and Images tab again.

I've also run into this problem when uploading images via the CMS but didn't have write priveledges to the _resampled folder, so it was looking for thumbnails for my photos but they were never written due to permission problems and Silverstripe choked and refused to render the page.

You may want to try deleting the files you uploaded via FTP and re-upload them using the CMS. You may need to delete their associated entries in the database table named "File" before the Files & Images tab will come back to life. The only way to do this is using phpMyAdmin or directly in mySQL.

Another quirk I briefly mentioned earlier, and why I tested the Admin panel in a totally different browser (if you're using Firefox log in with Safari or IE or vice versa) is because it caches the admin pages and totally blowing out the cache sometimes wouldn't bring the page back up in the admin. It wasn't until I logged in with another browser and it rendered the page correctly that I could then view it in my original browser. Really weird behavior and a pain in the ass to debug.

Thanks for your reply lawless. I did some checking on our server and I think this new error coincides with some updates that we made to the site's theme, so I think we have a direction to go in with resolving this.

I don't understand why SS needs a database record for all of the files on the server. Can anyone explain the logic or reasoning behind this?

--
Thanks,
Chris

Well I've been through the /assets folder, ensuring that _resampled is present for each folder, and has 777 permissions. That didn't fix my problem. In fact I set everything within /assets to 777. After checking all permissions I tried /dev/build?flush=1 as well, and still nothing. I'm at a loss. I might be willing to reinstall SS, but at this point I'm not even sure that would help.

asset management sucks.

recommendation: not use ftp uploads. if you do, you have to know ho to ;-)

it all depends on whether your php user and your ftp user are in the same group.
the chance that they'll be the same user, is near nothing ;-)
if you've got bad luck than they are not even in the same group, so you have to give
'world' rights so that anything can work.

first your '_resampled' folder must have read and write permissions for owner and group. (or world see above)
then your files you upload via ftp must have write permissions for user and group (or world).
becouse resizing of images seems to be done in copying the image to the _resampled
folder first and then changing it in size. dont's know why, but i also learned this lesson 'the hard way' ;-)

problem: if you FTP your files into the asset folder the 'w' for group (and word) won't be set.
your FTP-User is the owner. maybe there's a possibility on your hoster that allows you to specify which rights 'new Files' oder 'Folder' get. mine doesn't support this. so i've to care about 'rights' after upload.
means: if someone loades files 'manually' into the asset folder, he has to ensure, that he sets the appropriate rights AFTER upload. (right click on the file an look for chmod in your FTP-Client)

After that, start ONCE in your CMS the 'Asset management panel' (files & xxx, or what's the name).
This will scan in the new files and generate File Entrys in the Db for them.
The sense oft this is, as i can see, that later you attach only 'File'-Ids of within CMS fields that need 'files'.
So later changes of file-location won't be a problem. good thing.

The Problem i'm dealing with is that i've got 7000 files within my asset management (mainly uploads).
Now i get a timeout not at first start, scan runs 'till now'.
but if a klick at any folder the php script now needs more than 30 seconds. AARGH.

Last: if you USE this 'uploaded file' in CMS (assign it to one of your 'image needing' class-instances, the same time you select this new image a new 'thumbnail' will be created within _resampled. If you've forgotten to give your original file 'write' rights so that your php user cant write this file it will fail. And you' won't see any 'thumbnail'. so that's a good hint to chang this...