Worth noting - In Panorama 6 the results of folder( ended with a colon. In Panorama X the results do not.
So if filenames or other folders are to be appended, it’s important to add the colon yourself.
Do you mean folderpath( ? In Panorama 6, the folder( function returned a 6 byte binary folder ID. In Panorama X, it returns a / separated path, that does not end in a slash.
The folderpath( function returns a colon separated path in both Panorama 6 and Panorama X, and in both cases, it ends in a colon.
In Panorama 6, it was never allowed to append text to the result of the folder( function. The only thing you could do with the result of that function would be to pass it along to a statement or function that required a folder id value. So if you have code that appends something to the result of the folder( function, that code could never have worked in Panorama 6 or earlier.
As Dave explained, the folder( function returns a folder id value. In Panorama 6, this was a binary value. Folder ID values were a concept embedded into the original “classic” Apple operating system. However, OS X (and now macOS) doesn’t use these binary values – they simply don’t exist any more. So in Panorama X the path to the folder is now used as the folder id. Since the folder id is now text rather than binary, you could append to it. But I would suggest simply removing the folder( function instead. I don’t believe I’ve ever used the folder( function in any code I’ve written since 2014.
There were several statements and functions in Panorama 6 that used a folder id value in combination with a file name – most commonly fileload( and filesave. Everything is designed so that code written for Panorama 6 that deals with folder id and files will work without needing any change.
However, if you’re writing new code, there’s no reason to continue to use folder id values. Every staement and function that used to use the combination of a folder id value and a filename can now use a single combined parameter of the complete path. There’s really no reason to use the folder( function, since all it does is give you back whatever path you give it.
This topic is covered in detail in the Files, Paths & Directories session of the Intensive Training course from 2015-2016. This is also all documented in the Files and Folders help page:
In a Pan6 file I’m converting there are many places that pathstr(folder( are used with folders and files appended, depending on the situation. Nothing was being appended to folder( itself but rather to the result which always had a separator when converted to a string.
In the former Pan6 file, PanX keeps reporting that files or folders don’t exist due to the missing separator. In Pan6 I used folder( quite a bit in constructs such as fileexists(folder(pathstr(dbinfo(“Folder”,“”))+“graphics”),“logo.jpg”).
Although un-noted, pathstr( is apparently obsolete but tolerated within PanX procedures.
Without resorting to new testing of folder( in Panorama 6, I did note the documentation that shows a colon at the end
And I noted the colon lacking in the PanX Help along with the welcome fact that it’s no longer binary. I’m now rooting out all of the instances I need to rewrite in order to once again have valid paths.
I deemed the time in discovering the cause of my path errors was noteworthy on this forum in case others encounter it.
folder( has changed
That snippet of documentation shows a colon at the end of the input to the folder( function, not the output from the function. (Actually, I think it would work whether you included the colon or not). The output of the folder( function did not end with a colon, in fact, the output wasn’t text at all.
The pathstr( function DOES add a colon at the end, in both Panorama 6 and X, as shown in Dave’s screenshots above (and I checked this also).
By the way, the pathstr( function is now called folderpath(. I have just now added a note to this effect in the folderpath( documentation, which also means that pathstr( will now show up when you do a full text search of the help (or it will show up when the next version comes out).
This formula is perfectly good in “as-is” in both Panorama 6 AND Panorama X. I just double checked to make sure, and you can also see in Dave’s screenshot above that the pathstr( adds a trailing colon in both versions. Of course, it won’t work if there is no graphics folder in the same folder as the database. There is no change needed, in fact, if you add a colon, you will break it.
I hope you will investigate this further, because the one code snippet you posted does not have an error.
Back in 2014 I put a lot of thought into figuring out how to make sure that existing code dealing with folder ids could work the same in Panorama 6 and Panorama X, even though the underlying operating system handling of folders is completely different. There hasn’t been any report of a problem with this ever before today, and the example code you posted today does work correctly. If you have an example that does show that this is handled incorrectly I definitely want to see it, but so far I don’t see it.
FYI, if I wanted to modernize your formula, here is how I would write it now. Neither the folder( or pathstr( function is needed any more.
fileexists(dbinfo("folder","")+"graphics/logo.jpg")
Notice that dbinfo("folder","") does put a / at the end, so another one should not be appended. However, some other functions that return folders do not put the / on the end, for example info("panoramafolder"), so you have to check the function you are using.
But again, there is no need to modernize -
fileexists(folder(pathstr(dbinfo(“Folder”,“”))+“graphics”),“logo.jpg”)
will continue to work just fine with no modification required.
I will.
In response to your note about never using folder( yourself, I grabbed a convenient example of how I’ve used it. It was in a larger procedure in which there are definitely errors coming up that items don’t exist. In the error messages it’s an appended file or folder name that is not properly separated from the rest of the path. These had been working in Pan6 but have require revisions to work in PanX.
I’ll have to pull a fresh copy of the Pan6 file, after documenting how it is configured and working there. The file has a lot of toggling between binary and text paths.
What I actually said was
There are still some folder( and folderpath( functions in the Panorama library code and wizards that I never bothered to rewrite. These continue to work as they did before. But in any new code written since then, I don’t use the folder( function, I just use UNIX paths.
I went back and pulled more info together as promised…
In the Pan6 website being converted to PanX, the various paths to folders in the site were based on saved text entries.
When the server started up, many of those were converted to binary in order to work properly in some of the Pan6 functions such as Fileload(, PathExists(, etc. The binary path was saved in a variable that could then be used throughout the program for processing web hits.
As in the example below, with fgSitePath being the binary path, it was not unusual to have instances where it was needed in both binary and text formats. When converted back to text using pathstr( that result always ended with a colon: Macintosh HD:Library:WebServer:Documents:TheHtmlSite:
If not(folderexists(fgSitePath,“BackUps”))
Makefolder pathstr(fgSitePath)+“BackUps”
SetFilePermissions fgSitePath,“BackUps”,16895
EndIf
SetFilePermissions is obsolete but helps illustrate the past need for both binary and text formats. But makefolder will now fail in this scenario on PanX.
It’s easy enough to correct the starting text entry by adding the ending separator, now a backslash.
But in PanX, applying folder( to “/Library/WebServer/Documents/TheHtmlSite/includes/” removes it. That leads to an error such as the one that started this thread when files or folders are appended:
WEBMERGE Error: Template “/Library/WebServer/Documents/TheHtmlSite/includesheader.php” does not exist!
It’s truly a great thing to be relieved of dealing with the binary formats,
But, in all the many places that I had used folder( it is necessary to find and rewrite each one because, as I posted previously, folder( has changed.
Thank you, however, I am still not following what you are saying.
UPDATE – I did figure it out, skip to the bottom to see what the real problem is. In fact, I think I’ll change the title of this thread.
No, it won’t, at least not because of a missing colon. As Dave clearly showed in the 5th post in this thread, the pathstr( function still appends a colon in Panorama X, just as it did in Panorama 6. It did so in my tests as well. If you have some example where this doesn’t happen, you haven’t shared it with us so far.
Yes, it certainly has. Where we disagree is in the nature of the change. The nature of the change is that it is now completely different – it now returns text instead of a binary value.
HOLD THE PHONE! EUREKA! This is the first mention of WEBMERGE in this thread. And that is the key. There is no problem with the folder( function. But there is a bug in the WEBMERGE statement!. It doesn’t work if you supply a folder. (By the way, I did not know about this bug until just now.)
It’s a good thing we both perservered on this, because now we know what the actual bug is so it can be fixed. I’m also quite glad you reported this rather than just fixing your own code. You’ll have to undo the fixes you’ve made, but it shouldn’t be hard because you just need to search for WEBMERGE. I’ve made the fix for b33. I think in the meantime you can make the fix yourself. Open the code for the WEBMERGE statement (it’s in _EnterpriseWebPublishLib, which I think you should be able to edit), and change line 35 from:
templateFile = parameter(1)+templateFile
to:
templateFile = parameter(1)+"/"+templateFile
If you do that, please let me know that it fixes the problem. I’m pretty confident it will.
Agreed. And to be clear, the binary format came from Apple, not from ProVUE. Apple got rid of the concept of a folder ID, so Panorama did also.
And so it did. 
It seemed necessary to Upload the changed procedure since Pan Server was running.
Sorry I forgot to mention that. Actually, I’m glad that worked, I didn’t realize that could be done other than on the debug version. So that’s good to know.