Friday - The Automatic FAQ Maker
For those migrating from v7 to v8 the vendor sadly overlooked a number of important factors for users which I will attempt to address below. In comparing v7 to v8, you should assume 'v7' refers to v7.0.4; note v7.0.6 components are functionally the same as v7.0.4 but both these are incompatible with v7.0.0.. NP = NetPublish, NPS = NetPublish Server, NPA = NetPublish Assistant. v8.x refers to v8.0/1 and v8.5.
No, and you should stop and uninstall the old version before installing the new one otherwise you'll have problems. For safety's sake, if your /webroot/ folders are in the default location inside the NP program then you might want to archive that folder set before uninstalling. On Mac v7 and v8 install to the same folder. On Windows, v7 uses \Portfolio NetPublish Server\ (regardless of licence type) and v8 uses \Portfolio NetPublish\
It's been discontinued. Apparently there were very few licences sold. As from v8 there are only 2 NP versions. NP 5-User (allows only 5 discrete IPs to access the site concurrently) or NPS. The Extensis v8 NP pages are rather misleading, though I'm sure not intentionally so (I've suggested some wording changes), as there is no mention of the '5-user' constraint until the purchase link and there is no available description of what this restriction means. Unless you are a small creative group wanting to use this on an intranet you all now need the NP Server version v8. If you have an NPS licence you can still use it like v7 NP Unlimited (NPU), publishing catalogues direct from the client. This direct mode is only available if a catalogue is unpublished. There is an upgrade path from NPU v7 to NPS v8. IT is to be assumed this changed range of products is part of a gradual move to a more client/server user base.
v7 appears to upload to v8 NP without problems. I've not tried serving a v7 catalogue to v8 NPS but I believe it should be possible. In either of these v7->v8 scenarios they are not advised - or supported - for production environments but might be useful whilst transitioning multi-user setups to the new version. In reverse, trying to upload/serve to v7 NP from v8 results in an immediate but unhandled error; the publish stalls and NPA doesn't crash but you get no feedback. You may get v8.5 client to v8.0/8.1 NPS to work but it's not recommended or supported.
In 99% of cases the answer is a definite yes. Anyone doing deep customisation might want to peruse the NP library changes detailed further below, but this should be the easy part of the upgrade - no work required!
There are no new templates and indications are a few of the templates have been tweaked to match some minor changes in the libraries used by NPA for outputting sites (I've not run comparisons across the whole set of master files). However, the source code is untouched and still messy. If you want a clean source code you'll still need to clean it yourself or get someone to do it for you. That said, if you never look at the source code, the bundled templates are functionally pretty free from errors. The biggest problem with the built-in designs is that overly enthusiastic uses of IFrames that only accommodate very small changes from the default without becoming a scroll-bar fest ruining the visual look and feel. Language support has been increased, as described below.
Like the HTML most of the JS libraries will work functionally but won't validate (no {} bracketing, missing line terminators, etc.). This is a shame as it makes it much harder for the not expert to modify - and a real pain to do even if you do understand. Cleaning a whole site - i.e. all 4 variations of possibly 4 template types plus CSS, NP libraries, JS and XML files can be a lot of work. If you don't need all versions when customising you're advised to go in and delete unwanted template variants and unused libraries.
No, the templates are as in v8.0/1.
All string-driven sites are now localised for English/Japanese/French/German, though the client is hard-wired to using the assets for the installed language choice used for the clients. As before the NP server's language is the same for all sites - in terms of error messages. A French site on a German server will see NP error messages in German. There are no changes going from v8.0 to v8.5
Yes. This is something I thought would be fixed, as the issue was reported and acknowledged early in v7's release. The uploads aren't harmful to web page operation but more a waste of space/bandwidth and a bug for those trying to compose well-ordered custom NP sites. The lack of change indicates that very little of NPA's underpinnings were changed for v8.
Despite rumours of work on this, the indication is no. Given that the NP Unlimited version was axed in v8, and whilst v8 NPS can accept uploaded catalogues it seems the vendor solution to the upload issue is buy Portfolio Server - not a low impact 'fix' for smaller users!
Yes. Uploaded originals are still prefixed with the Item ID. Thus item #123, "pic.jpg" is stored as "123 - pic.jpg". This is a pragmatic defence against name clashes where two or more files with the same name from different folders are uploaded to a common folder. The NP API offers a syntax for setting the correct name for downloads. Web users dragging pages to the desktop or using a right-click save should still get the correct name (without ID#). However, with static pages assets are output as item ID + '.jpg', i.e. "123.jpg". The same name is used for each record's thumbnail, preview using 3 different folders. This is much more problematic as users of uploaded static pages get the 'wrong' filename. This is a major DAM no-no and was reported under v7 but remains unresolved as yet.
Frustratingly, yes. A properly secure IIS web server will not serve any files if any of the folders have a dot (period) in their name. This renders the output unusable for many users' needs - purely due to files (particularly originals) not holding the original source filename. The static page output creates folders like /detail.np/ and these can't be served via a secured IIS server and probably on a well secured Mac Apache server as well. The only workaround is to rename such folders and run a batch rename on all web pages in the set to correct the embedded paths. A simple fix for this was suggested when spotted under v7 but sadly has not been implemented. Sadly there's no way, using the NP API to avoid these 'bad' names as the code requiring change is inside a compiled (non-user-editable) library file. Although a folder name like /detail.np/ is not strictly illegal by web standards term is it banned by most anti-hacking security updates and is therefore a de facto illegal name as you can't reliably use it on all web servers supported by NP.
No. The workaround, as in v7, is to create a multi-value custom field, named [whatever] with a pre-defined list (PDL) of all your custom gallery/smart gallery names, or at least those you wish to expose; the PDL can be read dynamically by the NP API. For each gallery, select all items and apply the gallery's name from to your custom field. Clearly this is a totally manual method but it does work. NPS server users note that editing a PDL requires admin access so you'll have to close of the site every time you need to update the PDL.
In v8 any custom gallery in the catalogue can be served concurrently and independently of other galleries and the whole catalogue. If the gallery only has 25 items then only those 25 records will be in the scope of any searches from that particular site. In principle a catalogue with 10 custom galleries could back-end 11 separate NP sites - the whole catalogue and 1 per gallery. Thus internal users might see everything but each client may have their own specific sub-site. Do bear in mind that records can belong to more than one gallery so if using customer specific sites on a common catalogue make sure records are unique to each customer/site. Documentation of this feature is patchy - less info than is given here.
IMPORTANT: If publishing galleries you are strongly advised to teach users to select the desired gallery and publish via the NetPublish option on the Gallery menu, and not use the Catalog menu. Why? The former ensures the gallery pop-up on the Publish page of NPA pre-selects the correct gallery. Going via the Catalogue menu the same action defaults to 'All Items' and it is all too easy for the user to publish the wrong gallery - dangerous if web users shouldn't see content for other galleries (e.g. for other customers, etc.).
Can you use Gallery publishing in upload mode? Yes. However, there's little point as while the site only accesses the gallery in question, the whole source catalogue is uploaded. Uploading a 100 Mb catalogue just to serve 10 records might be disproportionate effort - but it is possible.
Yes, though the feature appears unfinished and is barely documented - so I've a hunch there's more to come here. The change is a new button on the NP Administration dialog (so it's not directly available to hosted NP customers). The admin can optionally supply a date range (the format required is not documented) and/or a site name. A tab-delimited text file can then be saved. This file lists the time and filename of al downloads. However, it gives no user information, such as an IP. As presented it's hard to see the point of this - here's hoping the finished version has some user info; even a bare IP number would help. Here's an example of output from v8.0.0.
Logging, in the assets.log (in the /app/ folder, now includes the following:
The Extensis web site slightly incorrectly lists this as an NP feature. What it really refers to is the cumulative effect of smart galleries. In fact all this is do-able in v7 but v8 offers 3 pre-customised catalogues with some of these features in place. Unfortunately the catalogues in question aren't installed by the program so many users will never find them!
No this remains broken. The best advice here is not to use multiple paragraphs in your text block fields, if possible. If you must use them, make sure each paragraph ends with a space after the closing punctuation so when the next paragraph follows it - as seen on the web page - the sentences don't run together. No change in v8.5.
The following section list changes to code in NPA's output libraries and two of the user-editable NP global libraries. You only need the information below if doing detailed customisation or encounter issues in v8 with your master templates produced in v7. Changes were compiled by doing comparisons of the English language clients libraries using WinMerge.
Changes to dynamic_search.np
NO CHANGES
Changes to dynamic_collection.np
In function Collection_outputFieldsWithSeperator(),
<% fieldValue = htmlEncode(fieldValue); %>
... becomes...
<% fieldValue = htmlEncode(LocalizeFieldValue(fieldValue)); %>
Changes to dynamic_detail.np
In function Detail():
if (size == "Original Size" || size == "Original")
this.imageSize = 0;
else
this.imageSize = parseInt(size);
// If we want to use the original size or we're doing a static publish
if (this.imageSize == 0 || !Template.dynamic || Template.preview)
this.imageWidthArg = '""';
else if (this.imageSource == "original")
{
this.imageWidthArg = '""';
}
else
... becomes...
if (size == "Original Size" || size == "Original size")
this.imageSize = 0;
else
this.imageSize = parseInt(size);
// If we want to use the original size or we're doing a static publish
if (this.imageSize == 0 || !Template.dynamic || Template.preview)
this.imageWidthArg = '""';
else
The terminology for Detail.size has changed though be warned the implementation of this change in NPA v8 is buggy!
Changes to dynamic_results.np
In function Results_outputFieldsWithSeperator(),
<% fieldValue = htmlEncode(fieldValue); %>
... becomes ...
<% fieldValue = htmlEncode(LocalizeFieldValue(fieldValue)); %>
Changes to dynamic_global.np
Adds new function:
// this will encode in UTF-8 while urlEncode() uses %uhhhh for >=256. (7#13287)
function urlEncodeUTF8(value)
{
return encodeURIComponent(value).replace(/\+/g, '%2C').replace(/\"/g,'%22').replace(/\'/g, '%27');
}
Bug Alert! The correct hex code for a + sign is %2B. This bug also exists in v7.x in the urlEncode() function. On researching this, the v7 built-in files (NPT templates, libraries, etc) never call urlEncode(). In v8, dynamic_global.np, makes one internal use of urlEncodeUTF8() to encode the filename of the site logo file. As long as that filename does use a plus sign (+) in its name - it's a legal character - then you should be fine. As with v7, the v8 site templates, etc., don't appear to call this feature. Note also that these functions are in libraries used solely for NP Assistant's NPT -> NP output process and thus not within the actual output web sites.
The user can safely fix this bug locally by simply changing the '%2C' to a '%2B'. Note that if you do this, always check after updates that your amended dynamic_global file hasn't been overwritten again with the buggy original.
Adds new function:
function JSSafeGetFieldValue(recordObjectString, fieldName)
{
return recordObjectString + ".get(unescape('" + escape(fieldName) + "'))";
}
This function:
function encodeEscapeURI(s)
{
if (s == undefined)
{
s = "";
}
else
{
var s1 = new String(s);
s1 = encodeURI(s1);
// Single quote
s1 = s1.replace(/\x27/g, "%27");
// Double quote
s1 = s1.replace(/\x22/g, "%22");
// Ampersand
s1 = s1.replace(/\x26/g, "%26");
// backslash
s1 = s1.replace(/\x5c/g, "%5c");
// greater than
s1 = s1.replace(/\x3c/g, "%3c");
// less than
s1 = s1.replace(/\x3e/g, "%3e");
s = s1;
}
return s;
}
... is shortened to ...
function encodeEscapeURI(s)
{
if (s == undefined)
return "";
return encodeURIComponent(s);
}
In function Global, this:
this.logo = urlEncode(this.logo);
... becomes ...
this.logo = urlEncodeUTF8(this.logo);
Changes to global.np
The function htmlEncode(s) gains some annotation but is functionally unchanged
This function:
function encodeEscapeURI(s)
{
if (s == undefined)
{
s = "";
}
else
{
var s1 = new String(s);
s1 = encodeURI(s1);
// Single quote
s1 = s1.replace(/\x27/g, "%27");
// Double quote
s1 = s1.replace(/\x22/g, "%22");
// Ampersand
s1 = s1.replace(/\x26/g, "%26");
// backslash
s1 = s1.replace(/\x5c/g, "%5c");
// greater than
s1 = s1.replace(/\x3c/g, "%3c");
// less than
s1 = s1.replace(/\x3e/g, "%3e");
s = s1;
}
return s;
}
... is shortened to ...
function encodeEscapeURI(s)
{
if (s == undefined)
return "";
return encodeURIComponent(s);
}
This function:
function LocalizeFieldValue( FieldValue )
{
var Retval = FieldValue;
if ( isDate(FieldValue) )
{
var aDateFormatter = new DateFormatter(FieldValue);
Retval = aDateFormatter.format("yyyy-mmm-dd hh:mm:ss");
}
else
{
Retval = FieldValue;
}
return Retval;
}
... becomes ...
function LocalizeFieldValue( fieldValue )
{
if ( isDate(fieldValue) )
{
var retval = new String();
//var aDateFormatter = new DateFormatter(fieldValue);
//return aDateFormatter.format("dd/mmm/yyyy hh:mm:ss");
// Does this make a difference regarding performance?
var dd = new String(fieldValue.getDate());
if (dd[0] == '0')
dd = dd.substr(1, 1);
retval = dd + '/' + (fieldValue.getMonth() + 1) + '/' + fieldValue.getFullYear();
retval += ' ' + fieldValue.getHours() + ':';
var mm = new String(fieldValue.getMinutes() );
if (mm.length == 1)
mm = "0" + mm; //pad if single digit
var ss = new String( fieldValue.getSeconds() );
if (ss.length == 1)
ss = "0" + ss; //pad if single digit
retval += mm + ':' + ss;
return retval;
}
return fieldValue;
}
Changes to global_strings
The function strings() loses these lines:
this.Prefix = "";
this.Suffix = "";
...and all references to them in the individual string settings.
3 new strings are added:
this.Global_83_InternetExplorer = "Microsoft Internet Explorer";
... and ...
this.Join_And = "and";
this.Join_Or = "or";
[End of changes]
The files in v8.5 are exactly the same as v8.0/v8.1.
Keywords (to assist indexing/searching):
Question: Changes in NP/static web pages v7/v8/v8.5 [FAQ00374.htm]
Last Update:- 09 August 2011
Site and articles © Mark Anderson 2001-2007 - Visit my home page