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)

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

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

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

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

(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

.

@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.

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

Mais oui! But thank you for your help anyway.

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

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

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.