Friday - The Automatic FAQ Maker
[Significant undocumented/usage issues as at v7.0.4+]
As at v7.0.4 NP Assistant, when importing Header/Footer/Welcome_Page HTML pages does not correctly the code. At present it imports the whole page when it should strip all the tags encasing the body copy. Until this bug is fixed, if you wish to use these features you should save your Header/Footer/Welcome_Page copy as HTML pages but then open them in an HTML text editor. Once opened, delete the opening tags from <html> through to <body> and at the end of the main copy text delete </body> and </html>. Not all web browsers will properly render the page-within-page embedding currently produced by NPA v7.0.4 output, so the above 'fix' is recommended. Note: once HTML files are saved as Header/Footer/Welcome_Page HTML, these pages are saved into to the template set's /resources/ folder.
If a query value contains an ampersand NP will either give no results or inappropriate results. This is because it cannot handle the ampersand character whilst failing to offer the user any method to escape/encode the character.
A knock-on from this is that if your NP template dynamically reads in an MKL or PDLs with ampersands in the list values you will have problems. Either reset the list (and all field values) to use 'and' for '&' or use a dummy field with 'safe' list values as you search field. Clearly the target for the latter will need to be cross-populated and kept in synch manually by the catalogue admin - something of a chore! This bug is still unfixed as at v8.0.0.
At present (v7.0.4), line breaks - paragraph breaks - are not rendered at all by NP. Paragraphs are simply run together.
The built-in template are chock full of layout/formatting errors at coding level. Luckily current browsers seem able to cope with these. However, if doing significant NP-based development you are advised to 'clean' the NPT source code to standards-compliant format. If you are only going to use one variant of the master set for each page type, you can cut the workload 75% by deleting the 3 unused page variants from each page set.
A number of code calls result in NP-generated images which are stored in as non-expiring assets in a [sitename] sub-folder of the cache.
NPA expects to use Portfolio screen previews. If you wish to use your own previews that write custom code to link them to templates and don't use /previews/ as the web storage location. If you use previews but haven't added since the last update, don't un-tick 'previews' during the next site update or else the web catalogue does not get a correct path to the previews (a bug, really, as this shouldn't matter).
This is possible. Look at the syntax:
CatalogSet.get('catalog').getType('CustomPDLField').getPredefinedList();
During (all? part?) of the upload the site, if you attempt access, will be reported as not existing. In fact it is disabled - so NP can't 'see' it as an active site. The resulting message is none too helpful. If you update often or it takes a long time consider manually mounting (by FTP) a static index page indicating the site is temporarily unavailable.
Don't leave out previews if you use them - otherwise the uploaded catalogue is not configured correctly for preview paths on the web server.
To do this you must first unserve the catalogue. Seems like an oversight/bug in the design. Just because the source catalogue is served doesn't mean the web catalogue will be so as well in all cases.
Make sure your NP files don't start with a blank line in the source code or you'll get an erroneous error "Error: you must write all response headers at the top of your template before HTML" inserted at the top of pages that use the affected template.
No. Though via standard HTML form, NP can easily interact with an ecommerce package of your choice.
Not in the root folder. The only safe place to upload non-NP assets via an NP Assistant publish action is to place them in the resources folder. They must then either be accessed from the site's /resources/ sub-folder or be manually moved to the root after upload.
No, or more correctly, not with any ease and then only if you control the web server. By default, most server-side scripting relies on the page extension to tell the server when server-side scripting must be processed. Thus an NP extension will cause the NP code to be processed but any PHP code on the same page would not get run - or vice versa if a PHP extension is used. With control of the web server you can widen the scope of code execution of scripting languages to other page types but this is non-trivial and outside the scope of the FAQ.
As at v7.0.4, this method returns the expected string but also with everything after 'server.np' added on. Instead of
/netpub/server.np?quickfind&site=mysite&catalog=catalog&template=results.np
... you get ...
/netpub/server.np?quickfind&site=mysite&catalog=catalog&template=results.np?quickfind&site=mysite&catalog=catalog&template=results.np
To get the correct string use this in your NP header code:
var sourceURLArr = Request.getRequestURL().split('?');
var sourceURL = sourceURLArr[0] + sourceURLArr[1];
This issue is fixed in v8.0.0
If used server-side, it seems the \d placeholder (only digits) doesn't work - use [0-9] instead. It is not clear why this should be. I suspect some other placeholders may also not work correctly so you may find it sensible to test specimen strings first in local JavaScript before testing server-side to help show up otherwise hard to diagnose errors.
The NP engine requires you to provide a 'template' parameter, even thuogh it has no useful purose and isn't listed as a requirement in the manual. Failure to provide this argument results in an NP error message and no further action.
Question: Significant issues (NP) [FAQ00369.htm]
Last Update:- 24 September 2007
Site and articles © Mark Anderson 2001-2007 - Visit my home page