Jeremy Brown wrote:
Could I put FMS13 on my host server and allow teachers to access it using their FM12 client?
But keep in mind that FileMaker Pro 13 features will not work in this configuration. In other words, if your file uses Popovers or Slide Controls (for example) they will not work with the FileMaker Pro 12 clients.
two different versions of server cannot be on the same machine. Is that right ?
Correct - only one version of FileMaker Server can be installed and active at one time.
FMP12 willwork as a client with FMS13, but FMS12 and FMS13 cannot be installed on the same server.
If you install FMS13 on the same machine after uninstalling FMS12, the existing opener file should still reach that address and file OK using either FMP12 or FMP13.
And, as Steveromig pointed out, since FM13 features won't work on FMP12 client, even if hosted by FMS13, FileMaker recommends not developing the files in 13 if you still use Pro12 clients to access them.
Thank you Steve and Stephen.
I figured that might be the case.
I'll simply start by developing some layouts, or revising some to work with the webdirect better and show the people who make the decisions what can be done.
It works the other way around too. FMPro 13 will read files hosted by FMS 12—with the same provisos about new FM13 features of course.
I would definitely recommend duplicating some current layouts and working off of them. The very first step after duplication is to apply some theme to the layout, and certainly NOT 'Classic'. Now that you can customize existing themes and create your own themes and apply them across several layouts, there should be a lot less pain in getting a consistent look to your work.
From what I understand, setting a theme is ESSENTIAL because it sets the CSS that will be used by Web Direct and applies it to all of the layout objects. If you don't use a theme on a 'converted' (i.e. FM12 --> FM13) file, Web Direct will create CSS definitions for each and every layout object independently, resulting in a LOT of slowness in page loading.
Also, if you apply several themes to a layout until you get one that you like, you can now remove the previously applied theme information from the layout, resulting in tidier CSS and better Web Direct performance.
-- Drew Tenenholz
This was not true in FMP12, and I have not yet encountered any reference to the cleaning-up of CSS being improved with the release of 13, though it would sure be welcome.
In 12, we had a specific warning from FM staffers that files accumulate CSS from used-and-discarded theme tests, bloating the file. It was recommended that we do theme testing on a discardable copy of the file, and make the final theme selection in a cleaner copy of the file when done testing themes.
Can you point us to the documentation that obsolete CSS encoding from tested themes is now removed when the theme is changed?
One short answer—incomplete, as I'm sure there are complexities and nuances to this stuff—is that you can actually now delete, from the file itself, any themes that were added at some point to the file but are no longer used in any layout. The new Manage Themes dialog shows how many layouts each theme which has been added to the file is used in: if 0, you can completely remove the theme from the file.
Another observation is that in 12, changing themes too many times in a layout often resulted in some wonkiness in the formatting. I have not been able to replicate that in 13, having "stress tested" a practice layout by going through all 50 pre-defined themes and back. With each change, the layout seems to get completely updated to the new theme correctly.
Now, I was previously under the impression (false? maybe) that when adding a theme to a layout, it was copied into the file, and also copied into the layout itself. Meaning that if Onyx were used in 10 layouts, there would be 10 (or 11?) copies of that stylesheet in the file, and that there could therefore be quite a bit of "accumulation" of css cruft over time. On the surface, that never made a lot of sense, as it would seem more logical to just keep one copy of each needed stylesheet in the file and associate layouts with it as needed.
I've done a bit of semi-scientific (meaning take with the usual grain of salt) testing to try and understand how this might be playing out in 13. I don't have my notes, or the numbers I generated, in front of me, so this is strictly from memory of testing I did maybe 3 weeks back, but here goes:
1. I created a new, blank file with one (default) table, no fields, and no records. It opened, of course, into layout mode, where I immediately changed the theme to Classic (presumed to be the "lightest"). I saved the change and, in Manage Themes, deleted the (new default for 13) "Enlightened" theme from the file. Next, I duplicated my blank layout 9 times, for a total of 10 blank layouts, all with the Classic theme. I closed the file and noted its size. (This is the point where I wish I had my notes in front of me, so I could report hard numbers. If I remember to look for those notes tonight, I'll update this post.)
2. Next, I went back into layout mode and changed one layout to another theme (forgot which one, but I picked the theme with the largest css file size). Closed the file and noted its size: it had grown by a significant factor, as expected.
3. Next, I went back into layout mode and applied that same theme to four more layouts. Closed file and noted size (using Get Info each time, to get an exact byte count!): no change in size at all. CONCLUSION: it looks like the theme is just copied once into the file and associated with each layout where used, rather than being copied into each layout. Well, that sure makes sense.
4. Now, I returned to layout mode and applied a second non-classic theme to the sixth layout. Closed file and noted size: another significant jump in file size, as there were now two non-classic themes in the file.
5. As in step 3, I next applied this second theme to layouts 7-10 (previously Classic). Closed file and noted size: as expected from my conclusion in step 3, there was no change in file size from step 4.
6. Next, I returned to layout mode and changed layouts 6-10 to the first non-classic theme, meaning that all 10 layouts were now using the same theme, but both non-classic themes were still in the file. Closed file and noted size: no change from step 5.
7. Now, I openend Manage Themes and deleted the no-longer-used theme that had been added in steps 4 and 5. Closed file and noted size: wondrously, it had returned to the one-theme size it was back in step 3!
OVERALL CONCLUSION: themes accumulate at the file level, not the layout level (which really makes sense), and clearing out unused accumulated themes via Manage Themes appears to completely recover the space.
As noted above, I'm sure there are nuances that my testing failed to reveal—perhaps even a total misinterpretation of results on my part—but I tentatively interpret it as good news re the effects of changing themes and resultant accumulation of css stylesheets in the file.
Thank you very much for your testing report!
This is a clear indication that the layout themes options have improved with 13 -- a Manage Themes menu didn't even exist in 12, and the accumulation of unwanted CSS code reminded me of an old inefficient HTML editor.