Date: prev next · Thread: first prev next last
2013 Archives by date, by thread · List index


Hi Erich, *,

On Thu, Mar 28, 2013 at 8:50 PM, Erich Christian <erich_tdf@irq.at> wrote:
Am 28.03.2013 00:51, schrieb Marc Paré:
Le 26/03/13 05:45 AM, Erich Christian a écrit :
Am 26.03.2013 10:11, schrieb Olivier Hallot:

Is there a reason why the images were deleted? Is anyone working on
updating of trimming the photoshuffler images?

Not that I would know. Only a small group has access to the donation
pages, but the shuffler pics are usually located in a folder with public
access for all NL teams.

Yes - it is the files in assets that count here, not the information
on the individual pages. The photoshuffler just stores the IDs to the
files in assets, but then doesn't care - when a file is deleted from
assets, there is no removal of the reference on the individual pages.

So maybe no pics were deleted but just moved somewhere else, possibly by
someone unaware of moving shuffler pics, the filenames unfortunately
don't imply this.

Moving images (using the assets-management, not by deleting and
creating a new entry, or by moving the files around on the filesystem)
should not alter the ID of the file, and thus Photoshuffler should
still see it.

They could also have been inserted from another more (lang-)restricted
folder and are not displayed therefore.

The restriction only applies to the image-search in the CMS-backend,
and doesn't apply for displaying the website itself and should not
affect display of the entries in the photoshuffler tab.
In other words: Having it in a "restricted" folder will make it harder
to add a file to the photoshuffler (as it won't show up in the "add
image" stuff), but if for example an admin (who can see anything, no
matter what) adds one of those, it would work.

Actually I'm not aware of a possibility of tracking deleted or moved
files in assets.

There is none for deleting - if a file is deleted, it is gone, and the
entries in the photoshuffler are left behind pointing to no-longer
existing entries. Files in assets also aren't versioned or something
like that, so the only way to determine what that deleted file was
would be to look into one of the older database backups - or in other
words: lot of effort :-)

What is easy though is to (semi)automatically delete those entries not
pointing to any file anymore - but I'd rather have projects replace
the images than just deleting everything silently.

CCing Christian on this topic.

I posted a list of affected projects in the other thread - for the
curious (and fellow admins :-) here's the SQL-query I used:

SELECT Subsite.Title, SiteTree_Live.URLSegment, SiteTree_Live.ID AS
"pageID", COUNT( ImageResource.ID ) AS  "number of broken entries"
FROM ImageResource
LEFT JOIN File ON ImageResource.AttachmentID = File.ID, SiteTree_Live
INNER JOIN Subsite ON SiteTree_Live.SubsiteID = Subsite.ID
WHERE ImageResource.ShufflerPageID = SiteTree_Live.ID
AND File.ID IS NULL

(File is the assets-management table, ImageResource is the table that
contains the photoshuffler-data, SiteTree_Live is the set of published
pages and Subsite is the subsite definitions)

ciao
Christian

-- 
Unsubscribe instructions: E-mail to website+help@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/website/
All messages sent to this list will be publicly archived and cannot be deleted

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.