Why doesn't FMPA17 import html-files anymore with the scriptstap Import Records from a folder of text files???
It never did. See supported file formats. For instance; this from FileMaker 16 Help.
HTML table format
•Exports data as an HTML table for use as a static webpage.
FileMaker Pro 16 Help
Well, I just ran the same script on the same Mac, same OS but with FMPA16 and it just works fine. I have been using it since FM11.
Again, the script step Import Records from folder with text files.
I tested it on Win7, both FM16 and 17 doesn't import HTML file.
Reading help https://fmhelp.filemaker.com/help/16/fmp/en/#page/FMP_Help%2Fimporting-folder.html%23
Text files must be plain, text-only files with a .txt filename extension or a TEXT file type.
then your HTML files where imported would have TEXT file type?
(But I can't find difference on FM17 in its help)
OP is on MacOS, I wonder if the '/Volumes' is necessary here as for other path places in FMP17?
fmtraining, please post your path calc for Import Records (a folder of documents).
Technically HTML files are text files but with the extension .html
.xml files are still imported for which the same applies.
The path used is a fixed path to a local folder, stored in a text field (and put in a variable) without containing /Volumes
But since the same path works with FMPA16 I don't see why that would make a difference.
I should add I noticed FM becoming more strict about file-extensions earlier, I think FM15. Then, exporting to a file with another file-extension than the file-type was no longer possible.
Don't let FileMaker get in your way!
With just a tiny bit of coding, you can import any kind of file. Using a micro-service and an HTML parser like "Beautiful Soup" or many others, you can parse the HTML and bring back exactly what you want.
Or, if you aren't comfortable with coding, you might be able to pre-process your HTML with a good text editor like BBEdit where you can "Extract" parts of the text file using Regular Expressions or just search expressions.
The beauty of a micro-service is that it works anywhere, with any operating system, on any computer, at any location, with virtually unlimited users. All for free. FileMaker or no FileMaker....a micro-service is totally independent so you can use it with any HTTP-enabled application (an application that can issue HTTP verbs like GET, POST, etc. Terminal, Browser? No problem.). What's not to love?!
Check out my two micro-service tutorials in the App Innovations Area:
Create Micro-Services Using Java and the Spark Java Framework
The Simplest Micro-Service! (Python and Flask)
Yeah, regex is much easier than micro-services.
I rather have the FM functionality back instead of relying on other products and services.
Well, I can't wait for FMI to implement useful functions. For example, there are only 13 marginally-useful date functions, for example. And, as you can see, FMI has been busy implementing new "solutions" in FMP 17 to solve "problems" I've never had (like docking the info panel).
RegEx is simple to use from FMP with a micro-service, also. I posted examples of that and also included that in the micro-services tutorial link above.
Once you create that bridge from FMP to a micro-service (basically a micro-service in any language), the entire world opens up to you to do whatever you want (with FileMaker). The Python example I also posted above is literally a "project type" so you just start a project of that type and you have a working (starting point, anyway) micro-service in Python. SO EASY!
Use FileMaker for what it's good for, which is a lot, but Do NOT let FileMaker's limited functions slow you down or get in your way.
Did you try the Volumes addition? Other threads have this as a solution (for several "path-type" functionality in FMPA17, OSX)
Since other files (.xml) get imported I don't expect de Volumes dir to make a difference. But I tried and it does not improve things.
However, I need to correct myself. I initially said .html files but it is mostly about .php files. So .xml and .txt are still imported but .html and .php are no longer in FM17.
Thank you for the update. You may wish to Report an Issue. Link to this thread, so you need not duplicate all the posts.
Agree with beverly. You should report an issue.
However, .... getting a bug fix from FMI isn't something I've ever encountered after reporting an issue and in my cases, I still need to make forward progress with any application as I'm sure you do, too.
As stated previously, there are simple workarounds where FileMaker doesn't get in your way. And, adding on to what I already posted above, with just a teeny tiny bit of JDBC logic, you could even do SQL INSERTS right into your FMP database with the extracted HTML (or whatever format -- as in ANY FORMAT) text -- eliminating any "import" to begin with.
Also confirming that .xsl (XSLT) are not being imported from a folder. I wonder about .css and .js and .json files as these may be common TEXT-type files used in a website.
Perhaps if Report a Product Issue is going to only get us a point to add a Product Ideas, we'd need to flesh out a method to include a list of extensions as "TEXT-acceptable".
Work arounds, plug-ins etc. lower the pressure on FMI to have their product working properly. We need many fixes not only new features.
"Work arounds, plug-ins etc." enable us to get the job done while we wait an unknown period (possibly endless) time for a fix or upgrade.
As I think Phil was saying, and if I understood him correctly, I totally agree -- my goal, isn't to influence FMI; rather, it's to get the job done. FMP usually gets me at least part of the way there, but FMP's "openness" is terrific so I can augment what is there and get the job (or task) finished. (micro-serivce, plug-in, etc.)
In the case you reported above, I would have been done in a few minutes using standard-but-not-built-into-FMP techniques. Customer happy. Everything humming along...
I do agree with you, however, on fixes over new features. I, like many here, have a long list (mine's over 70 items) of basic features still sorely missing from FMP. The endless march of new features...features....features leaves me cold and unmotivated to upgrade.
IMHO it would be helpful if the recursive function stack size limit of custom functions would be increased. It is hard (for me)
to understand that the current is 50k only and has never changed since introduction of FMP7. Even transitioning to 64bit
with FM14 never gave us more depth. If the limit would be increased or just limited by memory (settings) we could write our own little parsers/compilers etc.
(just tested FM17 and still no change)
Retrieving data ...