WebSite X5Help Center

 
Malcolm P.
Malcolm P.
User

V2019.2.7 beta adds random suffix to downloaded file  en

Autor: Malcolm P.
Visitado 1441, Followers 1, Compartido 0  

New links to downloadable pdf files add an underscore plus a random 8-character suffix to the filename, both when the file is viewed and also on the downloaded file itself, thus:

Stonehouse Studios Term Course Details.pdf becomes Stonehouse-Studios-Term-Course-Details_0vhjfqaq.pdf

This also occurs if an existing link is updated to point to a new pdf. Existing links from previous versions opened in v2019.2.7 that are left unchanged appear unaffected.

I presume this is an internally generated temporary filename that is being appended rather than replaced.

The issue is reproducible simply by adding a new link to an external pdf file on the local computer and downloading that file.

Publicado en
15 RESPUESTAS - 2 úTIL - 1 CORRECTO
Paul M.
Paul M.
Moderator

Hello Malcolm,

If I understand you correctly then I believe this behaviour is by design on Incomedia's part.

WebSite X5 has used this method for a long while now to differentiate between files where a file with the same name is already on the server (or has otherwise previously been used by WebSite X5 in some way, such as in the preview/Preview folder).  This is not confined to the v2019.2.7 BETA as such, nor does it only apply to downloadable files.

Nonetheless I will ask Incomedia to take a look at your comments, but please bear in mind that they don't return to work till Monday.

Kind regards,

Paul

Search the WebSite X5 Help Center (multilingual)

Leer más
Publicado en de Paul M.
Malcolm P.
Malcolm P.
User
Autor

Hi Paul,

Thanks for your very prompt response.

I've never seen this in previous versions of WX5 (I have had the same download links on this particular site for some while), and it does not occur with existing links in a version of the site from v2019.2.5 imported into v2019.2.7, only if those links are then modified or with new links generated in v2019.2.7.

I can only show you a live sample of it working 'correctly'; if you go to the second section 'Booking Your Classes' on the page http://stonehousestudios.co.uk/autumn-term.php and click on the highlighted link in the first line, you will see the pdf with the original title without the random suffix.

The only other thing I can think of is that I wanted a number of separate links to the same file (it is intended to serve Spring, Summer and Autumn courses identically); would that cause the behaviour you describe under those circimstances? Although I've just tried two links to the same external pdf in v2019.2.5 and that does not generate the suffix.

Sorry if I didn't make that sufficiently clear originally - does that shed any further light on things?

No worries about waiting for Incomedia, as this is not yet an issue on the site in question (though it will be later) so not currently urgent.

Many thanks,

Malcolm

Leer más
Publicado en de Malcolm P.
Paul M.
Paul M.
Moderator
Malcolm P.
Although I've just tried two links to the same external pdf in v2019.2.5 and that does not generate the suffix.

Yes, it will never happen with external files (by that I mean any which are not included in WebSite X5's preview folder before upload).

Here's an old thread from 2015 which might be helpful to you:

https://helpcenter.websitex5.com/es/post/128664

It should only happen when a file is either generated by WebSite X5, or attached/included by WebSite X5 in the preview folder, ready for upload in Step 5.  It can commonly be seen happening with the Contact Form Object.  The very first Contact Form which WebSite X5 generates in a project will be called imEmailForm.php  -  if more than one Contact Form is used in the same project then a different 'suffix' will be generated by the software to distinguish between each one.

It's great that WebSite X5 has the ability to attach files from the local hard drive and upload them to the right place on the server, as it makes it easy for the beginner webmaster to create a site.  For the more technically proficient, however, a far better solution is to upload all additional files once only to a location of your choice on the server (it can be handy to use dedicated folders)  -  then simply link to them when working with them in WebSite X5 using the 'Internet file' option instead of the 'Local file on PC' option.  If one does that then issues like this become a thing of the past, and it has the added advantage that WebSite X5 will not reupload the same file over and over again following an edit to the project, or update to the software.

Leer más
Publicado en de Paul M.
Malcolm P.
Malcolm P.
User
Autor

Hi Paul,

Thank you for that helpful link, which did give me a clue as to what might be going on, but I still can't quite get my head around the fact that I can change or add new links to the same file in v2019.2.5 without exhibiting this behaviour, yet as soon as I do the same thing with the same file and the same imported website in v2019.2.7 the suffix appears? If it is relevant, this is occurring on the local preview before the site with the new links has been uploaded to the server.

If I understand your definition correctly, the linked pdf is an external file by that definition, i.e. it is a file on the local PC and therefore not included in the WX5 preview folder? (presumably - I haven't yet had an opportunity to check).

There were a couple of other suggestions in that thread which also may be worth trying, so I'll pursue those as well if this is really by design and remains unresolved.

As mentioned out of frustration in my other thread, I am working with the Client From Hell on this site and she really doesn't need any more excuses to be difficult.

Cheers,

Malcolm

Leer más
Publicado en de Malcolm P.
Paul M.
Paul M.
Moderator
Malcolm P.
Hi Paul, If I understand your definition correctly, the linked pdf is an external file by that definition, i.e. it is a file on the local PC and therefore not included in the WX5 preview folder? (presumably - I haven't yet had an opportunity to check).

No, it's exactly the opposite actually...  my apologies if I have not explained things clearly.

An external file would be a file that is already present on the web somewhere (it doesn't even have to be on your own server), and which you associate with WebSite X5 purely by way of a hyperlink using the 'Internet file' option.

Local files on your PC which you link to in WebSite X5 (using the 'Local file on PC' option) will have a copy of them stored in the Preview folder, before uploading to the server in Step 5 (to the equivalent mirror folder on the server).  WebSite X5 invariably puts files like this in the 'files' folder within the 'Preview' folder.

Once again, sorry for any confusion on my part.

Leer más
Publicado en de Paul M.
Malcolm P.
Malcolm P.
User
Autor

No, my fault I think - thanks for the clarification. That might explain the behaviour if WX5 is attempting to upload a second copy of the pdf with the new link, though I am still puzzled about the apparent differences between v2019.2.5 and v2019.2.7 in that respect.

Malcolm

Leer más
Publicado en de Malcolm P.
Paul M.
Paul M.
Moderator

Don't worry, either Stefano or Elisa will provide a definitive response soon!

Leer más
Publicado en de Paul M.
 ‪ KolAsim ‪ ‪
 ‪ KolAsim ‪ ‪
Moderator
Usuario del mes PT
Malcolm P.
... ... ... That might explain the behaviour if WX5 is attempting to upload a second copy of the pdf with the new link, ... ... ... 

(It > En) ... ... if you make use of links to the same file from different pages, the file name will be corrected with a suffix to prevent it from being accidentally overwritten ...
... so on the net you could have copies of the same file ...
... to avoid this, and use only one file with its original name, just use the URLs of the files ...
... to upload PDF files online you have two ways;
1) - the first way to prefer is to send PDF files in the "pdf" folder (to be created)  with a third-party FTP client (filezilla, ws_ftp, ...);
2) - the second way, attach the PDF file to the ATTACHMENTS, leaving "files" as the target folder proposed by default; in this case the relative URL will be files/filename.pdf  ... and will also work in Preview; ... this method, even if it is simple, weighs down the project and the export flow in the network.

.

ciao

.

Leer más
Publicado en de  ‪ KolAsim ‪ ‪
Malcolm P.
Malcolm P.
User
Autor

@KolAsim. Many thanks for your suggestions, which should provide a solution if the situation is not otherwise resolved.

I understand the need to retain distinct versions of files on the server and the use of suffixes for this purpose. However, the behaviour still appears different in versions 2019.2.5 and 2019.2.7.

Specifically: in v2019.2.5 I can add multiple links to the same file from different pages and the filename remains as the original file when previewed or downloaded from any of the links. In the particular example I am discussing, I have four separate links to the same file from different pages and the downloaded filename is identical in every case.

Conversely, in v2019.2.7 (beta), existing links in an .iwzip project file imported from v2019.2.5 remain as they were originally, but any new link or a relink of an existing one immediately adds the suffix to the target file, which then remains visible in the filename when previewed or downloaded.

It is this specific difference in behaviour that confused me and caused me to suspect a bug.

Thank you for any further insights or clarification.

Leer más
Publicado en de Malcolm P.
 ‪ KolAsim ‪ ‪
 ‪ KolAsim ‪ ‪
Moderator
Usuario del mes PT

... OK, ... nous attendons le STAFF ... wink ... ciao...

Leer más
Publicado en de  ‪ KolAsim ‪ ‪
Malcolm P.
Malcolm P.
User
Autor

Mais oui! smile But thank you for your help anyway.

Leer más
Publicado en de Malcolm P.
Incomedia
Stefano G.
Incomedia

Hi Malcolm

I've tested this on the newest Beta and would like to provide a little more explanation on this, trying to understand what exactly is going on in your test.

Could it be that in your previous website, the file you are uploading as PDF is being exported in a different place on your hosting? There is no way multiple files with the same name could co-exist in the same space online, or you would be downloading always the same file, no matter where you're downloading it from. Perhaps those were being uploaded in different folders?

While now, you're uploading the file in the same folder and thus the program is adding such characters to its name.

Please verify this and keep me posted on the result

Thank you

Stefano

Leer más
Publicado en de Stefano G.
Malcolm P.
Malcolm P.
User
Autor

Hi Stefano,

Apologies if I haven't previously explained this sufficiently clearly.

I have checked the server, and there is only a single file of that name (in this case, Stonehouse Studios Term Course Details.pdf), in the /files folder. This is linked from four separate pages without problems. And the issue with the suffix in v.2019.2.7 occurs when previewing and editing the links in WX5 on the local PC, i.e. before it gets anywhere near the server.

However, in the course of replying to your post I have just this moment had a further thought:

The beta version 2019.2.7 is located on my laptop so as not to affect the 2019.2.5 installation on my main machine. The identical pdf file has been copied to the laptop but is located in a different folder on the laptop from that on the main machine with v2019.2.5. Is it possible that WX5 is taking the full pathname into account when linking and is therefore seeing it as a different file but with the same filename and therfore adding the suffix to discriminate the two? The issue only occurs when relinking/adding new links to the original project file on the laptop, but that is the only place the source file is a different location. Might that account for the apparent issue?

If that is not the case, please advise and I shall attempt to explain the sequence of events further.

Many thanks for your patience!

Malcolm

Leer más
Publicado en de Malcolm P.
Malcolm P.
Malcolm P.
User
Autor

Updating to the full non-beta v2019.2.7 on my main machine appears to confirm my speculation immediately above that the different location and path to the source file on my laptop may have been the cause of the issue, rather than the beta software. 

i.e., with nothing else changed other than the new version, adding new links or revising old ones on this machine does not generate an unwanted suffix.

Apoligies to anyone whose time I may have wasted; hopefully this thread may still act as clarification for anyone who might get caught out by a similar issue in future.

Very many thanks to all the moderators and Incomedia staff for their assistance and patience.

Leer más
Publicado en de Malcolm P.
Paul M.
Paul M.
Moderator

Thanks very much for following up in so much detail and letting us know, Malcolm.  It's always helpful to get feedback on the resolution of an issue as it can help others in the future like you say.

Leer más
Publicado en de Paul M.