PDF Object - modified PDF file is not uploaded to the server 
Autor: IT- TeamHello there
We are using the PDF Object to display a 'Bewohnerliste'
If we modify the 'Bewohnerliste' in the Windows File System (Lokale Datei) and export X5, the old version of the Bewohnerliste remains on the server. This does not only happen for the pdf mentioned, it happens for other pdf files too.
We have run the project through the WebSite X5 Optimizer, we have deleted the contents of the Preview and Upload folders - no effect - the problem remains.
We have done some 'digging' in the library.xml file und the Library folder. In the library.xml file we find an entry that reflects the change
and looking at the file "hyek3sidm2wbhpt8onolyxuxqdv2j0zn" in the Library folder we see the correct (modified) version of the pdf.
However, it is not being uploaded.
Even worse: we replace the file on the server at one.com manually with the correct version (and can see it's now correct on the website (www.lhev.net)). After the next export with X5, the old version is there again.
Can you please advise what we are doing wrong.
Thank you
Werner and Jürg
Hi Fritz.
Does the file have the same name? What if you change that? Just check to see if you manage to fix it like that already.
Additionally, have you tried deleting the PDF Object and inserting that anew? Try that too and see if it helps.
Also keep in mind that the software will mantain certain files connected to itself if you keep backups stored inside the project. Consider creating an IWZIP backup so that you're sure that you've got a backup copy in case you need it (Step 5) and try clearing the backups. If the file was used in one of those older version, it might still be kept under consideration by the software.
Try all of this and let me know the result
Thank you
Stefano
Autor
Hello Stefano
Thank you for your reply.
I think we have done about everything - we are both IT professionals - but are still not clear why and where the old version of the 'Bewohnerliste' is coming from. We have also looked through the two 'library' objects (folder, xml) - which by the way look quite messy because old versions are not cleared - but we could not really identify the logic behind. Sometimes the object in the folder reflects the latest version, sometimes not (like last time - see point 3. below).
To your questions:
My colleague Jürg did testing yesterday 25/10/2018 around 14:45 GMT+7. His findings are as follows:
quote
Hallo Werner
Die ganze Sache wird immer mysteriöser !
Ich habe heute Nachmittag folgendes gemacht:
Ich weiss nicht mehr weiter
unqote
I have added the latest library.xml file - maybe that is of help to you.
Some additional remarks:
a) We followed the instructions in the Posts
https://helpcenter.websitex5.com/es/post/129755
https://helpcenter.websitex5.com/es/post/177145
b) The latter one speaks of a 'bug' and we were hoping that this bug was fixed and that the Website X5 Optimizer, which cleared out quite a number of files, would have been used by Incomedia to resolve the issue -> obviously wrong assumption
Thus we follow the wishes of Myron A. and of Aleksej H. of 12/2017 and 01/2018 and the remark of Andre E Moderator of 01/2018 "and yes if it does not help you need to have patience". Well, patience is not indefinite, not even in Thailand where we are living.
Best regards
Werner and Jürg
Hi Fritz,
I tested all of this functionality again in order to make sure I didn't miss any steps, and I would like to offer an additional procedure you can try and perform to see if the correct file is linked then:
1_ Open the PDF object, right click on the pdf file and remove that.
2_ After doing this, confirm with the green Tick, and launch a preview. Then shut it down.
3_ Now go and reselect the new file.
4_ Upload the file at Step 5.
See if with this procedure you get the correct file to upload, and let me know the result
Thank you for your patience
Stefano
Autor
Hello Stefano
Thank you for your reply. It's me again, Werner. And my collegue Jürg who did some testing, not only with the PDF Object but also with the Bild (Picture) Object.
The results are not really promising. I would say 'it works as designed', but I cannot say it works as it should. Any file syncronisation system can recognize when a file was changed and use the new version. And the 'Export' function of Website X5 is in my opinion (among other functionality of course) nothing but a synchronisation between the development environment and the server. And the same is true for the 'Preview' function.
I am giving you the details of our tests:
1. with the PDF Object
Hoi Werner
Ich habe den Vorschlag von Stefano gerade mal durchgespielt. Es war ja nur notwendig, das Datum im Kopf zu ändern und wieder als PDF zu speichern.
Ich bin wie folgt vorgegangen:
Und siehe da -> es hat funktioniert -> das File mit Datum 1.11.2018 ist geladen.
Etwas umständlich aber es tut.
Gruss Jürg
2. with the Bild (Picture) Object
Ich habe unser PDF-Problem mal mit dem Bild-Objekt wie folgt getestet.
Test 1 – nicht erfolgreich
Verzeichnis Dokumente
Bild 00052-Poolarm.jpg durch ein anderes Bild mit gleichem Namen überschrieben.
WebsiteX5 aufgerufen
Seite «Homepage» aufgerufen
Vorschau gestartet
Neues Bild war NICHT da
Test 2 - erfolgreich
Bild 00051-Pool.jpg durch ein anderes Bild mit gleichem Namen überschrieben.
WebsiteX5 aufgerufen
Seite «Homepage» aufgerufen
Bild angeklickt und «Inhalt» aufgerufen
Verzeichnis gestartet, Bild gesucht und angeklickt
Vorschau gestartet
Neues Bild war da
Wenigstens muss man bei Bildern nur einen Schritt machen.
Aber grundsätzlich sollte ja so sein, dass wenn man auf Vorschau klickt oder hochlädt, die Software untersucht, welche Dokumente geändert wurden und die geänderten hochlädt. Dafür gibt es ja das Änderungsdatum.
Gruss Jürg
I would hope you are telling me, that we are doing something wrong. Because we separate the function of a) the webmaster who updates the information in the (pdf) documents and in the dynamic objects (they change frequently) and b) the developers who do the design of the pages and fiddle around in the 'code'.
I would hope that my conclusion
"Export is not taking the latest version of documents - unusual efforts are necessary"
is not correct and I don't have to open another post with this titel.
Best regards
Werner
Hi Fritz.
I understand your concern but at the same time can confirm that this specific removal step is necessary. And it is most probably so for other fields too, such as the image selection for the Image Object. The project itself gather the data inside itself and basically recognized that data through the use of the file name, but the actual data that is referenced is now inside the project, and not in the outside file. In fact, if you export the project as IWZIP at Step 5, the linked documents will be available on whatever computer you decide to import the project onto.
This means that the link to the file HAS to be removed manually as described, and reassigned in order to the software to update its memory about that specific file.
I can understand that this might prove to be a little troublesome if certain files need to be changed often, but it is the normal behavior of the software as of now.
In any case, since I believe it is a valid point to be discussed, I will proceed to notifying the developers of this possible improvement, so that it might be eventually discussed and examined properly.
Please do let me know if I can provide any further insight on this matter
Thank you
Stefano