Persistent URLs for Objects to be Replaced

What is the best way to create persistent URLs for objects within Plone that will be accessed from external applications? Is the UID the best choice? If so, how does one replace an object with a new one so that it will keep the same UID?

The solution depends on your usecase. As long as /path/to/your/content remains stable, it will remain stable unless you rename the object or change the storage path. The internal UID might be good enough as a reference for external systems however we usually maintain a dedicated uuid field (uuid4 or uuid1) that is populated during object creation and never ever touched again. In some cases you link Plone content with an external system where the UUID is provided by the external this case you assign this uuid to a dedicated field...make it searchable (ZCatalog) in order to query by this UUID...the plone.restapi should give you everything you need. Rule of thumb: don't rely on the Plone UUID when you interact if external systems---move the logic under your own control.

Hi Andreas,

Thanks for your prompt response. I should have provided a little more background information to establish better context for my question.

I am writing a standalone web app with HTML5 and JS, which, among other things, will provide a carousel of jpg images extracted from another image carousel that runs on a Plone website. The images are posters for events sponsored by the organization I work for. Because of this some images are added to Plone and others expire every day. However, I can't rewrite the HTML every day to accommodate the specific names of the new and expired images, so I have make a best guess about the number to be extracted and use some form of persistent URL to access them.

With a standard file system I would ask the people who create and upload the images to assign them names that could be used over and over again, such as 01.jpg, 02.jpg, 03.jpg, etc. From what I have been told this approach would not work in Plone because the earlier 01.jpg would not be overwritten by the subsequent 01.jpg. Hence I was seeking an alternate solution when I came across the UIDs. However, it now looks as if the UID is not really a fixed address that can be used for changing content.

Therefore, I would be most appreciative of any suggestions that you or the Plone community might have on this issue.


Jerry Caswell

Why wouldn't uploading a new file for the existing 01.jpg object overwrite it?

When I have tried to overwrite an image file by uploading additional files with the same name, the new files are added to the contents list with different URLs and UIDs.

--Jerry Caswell.

No, overwriting by editing the existing objects.

I wasn't aware that there is an image editor in Plone; bur, if there is, it might be a good solution.

Thanks for the suggestion!

--Jerry C.

What Roel is suggesting, is to edit the Image object (i.e. the Plone container object which holds your image file). In it, together with title, description, etc you will also find the field which holds the actual image file. You can easily upload your new image there.

There is no complex one, but Plone resizes and auto-rotate images. With the add-on the crop area can be selected TTW.

You need to edit the image content and upload a new image into the existing type. So, then the following applies:

To load the original image it is enough to just call ``/Plone/myimage` which should always deliver the newest upload.

The UID URL of an image scale (like /Plone/myimage/@@images/SOMEUID) is optimized for caching and gets a cache header to never expire.
If one overrides the image, a new scale with a new URL must be generated - the scale under the old URL UID will be discarded. In order to reference an image w/o caching header set always pointing to the newest upload, use the form /Plone/myimage/@@images/FIELDNAME/SCALENAME.

@jensens I believe @caswell wants to familiarize himself a bit more with Plone content types before going further. There are a myriad awesome Plugins for Plone - including imagecropping - which allow users to extend and customize its functionality. Those would be things to explore down the road.

Jerry probably used the image upload tool to upload his initial images. What this does, is to create image objects with the same name as the filename of your uploaded images. Don't worry about UID's as those are only internal values.

Let's say one of your images is at http://localhost:8000/Plone/MyFolder/MyImage.jpg
If you are logged into Plone and navigate to that URL, you will see a panel on the left of your screen, click edit in that panel and scroll down to where you can upload a new image.

As @zopyx already mentiioned, the URL will stay the same and your external carousel app will get the newly uploaded image when it is replaced.

This is not true if you replace your image in the way suggested. i.e. navigate to the image you wish to replace, click edit and upload your new image in the 'image' field.

This adds a layer of complexity you may wish to avoid. Have your carousel get the images straight from Plone. If you require a scaled image, get it in the format Jens suggested:


Such a URL would not change. 'large' is just an example of a standard scale provided out of the box. You can set different scales from the Plone administration controlpanel.

1 Like

Thanks to everyone for the additional suggestions. What I found suits my immediate needs is selecting an image from the contents list. clicking the edit tab, and clicking on the option to replace the image with a new one. That worked well with the fourteen "fixed" objects which I created and linked to from the external carousel.

Because the people who create and upload the images for the internal carousel may not be familiar with this process, I will show them how to do this. Presumably they can substitute these "fixed" images in the internal carousel as well, so that one upload and replace action will satisfy both needs. It will have the additional benefit of limiting the expired images that are left in the system.

I will be exploring other facets of Plone in the near future, but my first objective is to complete the external application.

Thanks again for the help!

--Jerry C.

Plone Foundation Code of Conduct