BN_IT_Support

Hi,
I don't have the answer, but...
I find it interesting that you would use your own editor on a Theme hook. I would agree that using your own editor on a Code hook is far more convenient than using adminCP editor, but for a Theme hook ??? Personally, I find the adminCP editor more convenient as it sorts out all the escapes (among other things). What motivates you to use your own editor?
Secondly, if this used to work before 4.7.16 and if you have NOT made any changes to your editor (either configuration or version update) then I can understand your point of view - that it should not have been broken.
That said, the Invision comments say "do not remove" and that implies "do not modify, either" and your editor has clearly modified the lines - what was '/*comment*/' is changed by your editor to '//comment' which is not the same thing.
John

As a general opinion on "Pages DB"...
They are not really "databases" in SQL terms -- but SQL "tables" in the Invision database.
When you are considering which sort of SQL table to use (within Invision) you have two choices:
"Pages DB" (as you have mentioned) SQL tables as defined under the 'Database Schema' tab for an Application Pages DB works well for:
Where you only need a single table for all your data - for example, in the classic database design if you only need a "products" table then it will work well. If you actually need a "products" table and a "suppliers" table with cross references then it does not work so well - and in any case you would need two Pages DB (one for products and one for suppliers)
  Where the solution involves a human adding and editing records it works well - for example, where you have a human adding products (descriptions, part numbers, prices, etc.) to a product table. We probably use between 5 and 10 Pages DB for various unrelated things such as "news articles", "places to go" and so on.
  Using Pages DB automatically gives you various widgets such as "Database filters" which is good.
  I would strongly recommend that you use the standard display templates wherever possible. If you create your own display templates based on the standard display templates then that effectively bases your template on a snapshot of the standard template - you don't benefit from future improvements and bug fixes to the standard. We have some of our own templates from 6 or 8 years ago and regret not putting more effort into display formatting for individual fields. With some clever display formats you can combine fields to produce complex output (for example, latitude and longitude fields to display a map) and if you need to do conditional display of some fields dependent upon the contents of others then you can add a dummy field (with a non-blank default value so it triggers display) and you can write custom code to display the contents of several other fields according to the rules that you want to apply. Do the fancy stuff in a field display rather than a template wherever possible.
  When you write a scheduled task (for example) to update the data in a Pages DB there are a couple of (minor) extra steps that you need to take in order to write the data. Firstly, you need to know the classname that will be used to write to the correct table and this will be something like \IPS\cms|\Records23 where 23 is the database number. So, you have to look up the database number from your database key (I recommend against hard coding the 23 😉 ). Secondly, if you have fields for name, address, region, country, phone, etc. then the names in the table will be something like field_91, field_92, field_93, field_94, etc so you have to 'map' from the field key to the real field name in the database. Not difficult, but that's what you have to do.
  Pages DB will work OK where you have a scheduled task to update the data once per day (for example - it could obviously be much more frequently if you wanted). A scheduled task will work fine where nearly all the data items/records are accessed every day - but what about a scenario where only 5% of records are accessed each day? Doing a daily scheduled update of all records means that 95% of what you retrieve is not going to be used in the next 24 hours. I rather liked Nathan's suggestion of retrieving data on demand (i.e. every record has a lifetime field that you add so if you want the record but the lifetime has expired then you retrieve the data through the API). That would mean that you would not waste resources retrieving data that is not being used. Unfortunately, "retrieval on demand" would be extremely difficult or impossible to implement using Pages DB - unless you write your own very fancy templates and in that case you could do better to write an Application to do the entire job. Updating Pages DB from a scheduled job would work easily. Application tables will work well for:
You need several tables with relationships between them (e.g. products and suppliers)
  You need an application that does a lot of processing of records (rather than simple human entry of records as indicated previously)
  Access to records is more intuitive - field names are what you want to call them rather than being 'mapped'. Also, access to the correct table is very simple as you need to create a sub-class of \IPS\Patterns\ActiveRecord that will get you to the correct table plus a whole load more stuff.
  If you have hierarchical data (for example, categories and records) then you should consider using the Node/Model/Item/Content model although that gets a lot more complicated it does give you access to many of the features that you see time and again in Invision.
  You have complete control so retrieving data on demand is much more simple than it would be using Pages DB. Regards,
John
 

As a general opinion on "Pages DB"...
They are not really "databases" in SQL terms -- but SQL "tables" in the Invision database.
When you are considering which sort of SQL table to use (within Invision) you have two choices:
"Pages DB" (as you have mentioned) SQL tables as defined under the 'Database Schema' tab for an Application Pages DB works well for:
Where you only need a single table for all your data - for example, in the classic database design if you only need a "products" table then it will work well. If you actually need a "products" table and a "suppliers" table with cross references then it does not work so well - and in any case you would need two Pages DB (one for products and one for suppliers)
  Where the solution involves a human adding and editing records it works well - for example, where you have a human adding products (descriptions, part numbers, prices, etc.) to a product table. We probably use between 5 and 10 Pages DB for various unrelated things such as "news articles", "places to go" and so on.
  Using Pages DB automatically gives you various widgets such as "Database filters" which is good.
  I would strongly recommend that you use the standard display templates wherever possible. If you create your own display templates based on the standard display templates then that effectively bases your template on a snapshot of the standard template - you don't benefit from future improvements and bug fixes to the standard. We have some of our own templates from 6 or 8 years ago and regret not putting more effort into display formatting for individual fields. With some clever display formats you can combine fields to produce complex output (for example, latitude and longitude fields to display a map) and if you need to do conditional display of some fields dependent upon the contents of others then you can add a dummy field (with a non-blank default value so it triggers display) and you can write custom code to display the contents of several other fields according to the rules that you want to apply. Do the fancy stuff in a field display rather than a template wherever possible.
  When you write a scheduled task (for example) to update the data in a Pages DB there are a couple of (minor) extra steps that you need to take in order to write the data. Firstly, you need to know the classname that will be used to write to the correct table and this will be something like \IPS\cms|\Records23 where 23 is the database number. So, you have to look up the database number from your database key (I recommend against hard coding the 23 😉 ). Secondly, if you have fields for name, address, region, country, phone, etc. then the names in the table will be something like field_91, field_92, field_93, field_94, etc so you have to 'map' from the field key to the real field name in the database. Not difficult, but that's what you have to do.
  Pages DB will work OK where you have a scheduled task to update the data once per day (for example - it could obviously be much more frequently if you wanted). A scheduled task will work fine where nearly all the data items/records are accessed every day - but what about a scenario where only 5% of records are accessed each day? Doing a daily scheduled update of all records means that 95% of what you retrieve is not going to be used in the next 24 hours. I rather liked Nathan's suggestion of retrieving data on demand (i.e. every record has a lifetime field that you add so if you want the record but the lifetime has expired then you retrieve the data through the API). That would mean that you would not waste resources retrieving data that is not being used. Unfortunately, "retrieval on demand" would be extremely difficult or impossible to implement using Pages DB - unless you write your own very fancy templates and in that case you could do better to write an Application to do the entire job. Updating Pages DB from a scheduled job would work easily. Application tables will work well for:
You need several tables with relationships between them (e.g. products and suppliers)
  You need an application that does a lot of processing of records (rather than simple human entry of records as indicated previously)
  Access to records is more intuitive - field names are what you want to call them rather than being 'mapped'. Also, access to the correct table is very simple as you need to create a sub-class of \IPS\Patterns\ActiveRecord that will get you to the correct table plus a whole load more stuff.
  If you have hierarchical data (for example, categories and records) then you should consider using the Node/Model/Item/Content model although that gets a lot more complicated it does give you access to many of the features that you see time and again in Invision.
  You have complete control so retrieving data on demand is much more simple than it would be using Pages DB. Regards,
John
 

Would I be correct in deducing that you're referring to this (on a custom block)?

If so, no, it would be the data that would be cached so you would lose control of how and when it would be refreshed.
Certainly, you could use a custom block, but just make sure that you leave 'Cache this block' set to 'No' and then do your own caching.
The way that Nathan Explosion suggests is by far the best way...
Firstly, there is "how/when you retrieve the data":
Scheduled polling would collect all the items even if some have not been updated. Daily polling would work OK if all items are updated every day but if only half the items are updated each day (for example) then you would be retrieving twice as many items as required. If you need the most up to date data for each item then you really need webhooks to notify you of changes - in the absence of webhooks you either set a very short scheduling interval or else use Nathan's solution with a short cache lifetime. You have now told us that you don't mind data which is not completely up to date (say - one day out of date) so webhooks are not essential. Nathan's solution where you load the cache on demand (i.e. only retrieve an item is it is not in your cache OR it is in the cache and already expired) - set the cache timeout to 12 hours or 24 hours or whatever depending how far out of date is OK. If the rate limiting still causes problems then you might want to (need to) randomise the cache lifetime a bit. For example, with a fixed cache lifetime of 1 day if you start with an empty cache and if the users demand all data in a very short time then you might exceed the rate limit. (Not likely, but possible?) With a fixed cache timeout the same thing will happen the next day as all items will expire at the same time. Randomise the cache time with +-60 minutes and lookups will be distributed over time very quickly.
Secondly, there is "how/where to cache the data":
If you only need a single lookup key per item (e.g. a name OR an id) then Nathan's suggestion of using the data store is the best way to go. (I've used it where I only need one key per item and it works very well.) If you need multiple lookup keys per item (e.g. name AND id so you sometimes retrieve from cache by name and sometimes by id) then the data store does not have that flexibility so you would probably need an SQL table with multiple keys - unless you double your storage usage by saving each item under both the name key and the id key. (I have multiple tables with multiple keys which is why I think that way 😉 ) John

If you're going to go down this path then I would be inclined to use a 'task' within your Invision Application - that way you can use the API to pull data directly into your application rather than pull the data with Zapier or a separate cron script and then post it into your application.
An important question - how far out of date can you allow the data to be? If the data must be up to date within 5 minutes then your script will have to run every 5 minutes and if your application does not display all the data frequently then you may well generate more activity pulling data on a schedule than you would pulling it on demand.
Is there a way (in the API) to detect data that has been updated - so that you don't have to pull all the data periodically?
The most useful thing would probably be if the API includes webhooks that will fire and notify your application if a data item/record is created and when one is updated -- i.e. you then use your webhook to pull data that has changed and don't bother to pull data that has not changed.
If there are no webhooks in the API as an alternative will the API let you 'list all records that have been updated in last 10 minutes' (for example) - that way you would use the list of recent updates to select which records to pull (i.e. only those that have been updated since last pull).
Finally, I would be inclined to store the data in your own database (i.e. table defined by your application). Effectively, the database table acts as your cache and if your cache is only updated on data change (webhook or whatever) then it would probably be far more efficient than trying to use the Invision cache (which will have its own timeouts that are not necessarily in sync with updates to the data...)
John

Hello,
Version 4.7.15
compileFullEmail attempts to fold long headers by using the wordwrap function - but this does not work correctly as whitespace gets 'swallowed' and the extension line does not start with white space. The rule for Long Headers (those that exceed 998 bytes) is that they should be split so that the next part starts with white space -- i.e. crlf ma#y be inserted before the whitespace and NOT as a replacement for the whitespace. "unfolding" only works correctly if the follow on lines start with white space -- i.e. "Unfolding is accomplished by simply removing any CRLF that is immediately followed by WSP."
Our particular failure scenario was when using our application to send to approximately 100 recipients as the $to field then exceeded 1,000 bytes and the To: header was split incorrectly. This then messed up the mail server processing resulting in failures to deliver. Quite probably different mail servers mess up in different ways - in our particular case the mail server put the extension line in the Subject: field and decided that there was no From: header.
Regards,
John

Marc,
Thanks for all replies. Will run the checker as advised.
John

Thank you for your time and information on this. I have tagged this to a developer to help review what you have mentioned here and plan our next steps.

IPS style header block for displaying messages and links across the the top of your board. Use either the built in message formats or set you own custom formatting.
Settings
Show/Hide Message. Select which groups can see the message. 4 built in message formats. Custom message format including; icon, text colour and alignment, background colour.  

Displays an advert or heading message on selected Commerce pages.  Can be used for promotional offers etc.
Use built in advert (single image upload, linked image or HMTL), IPS formatted message or plain text. Group Selector Page Selector: index, category, product. It's free, so support is as and when I have the time and it's only tested on the default skin.

Hello,
There is a minor problem when running SuperGrid templates 3.1.0 and SuperHelp templates 1.4.0 on Invision 4.4.7. The problem arises because in one of the releases Invision changed the default namespace so that references to the 'count' function no longer default to the PHP function (in the root namespace '\') but default to the relevant IPS namespace. The solution is to force all references to the PHP count function to be the root namespace by using '\count' instead of 'count'.
When using IN_DEV mode any access to SuperGrid or SuperHelp pages results in an exception and the message that for performance reasons references to 'count' should be replaced with references to '\count'. This means that I cannot test any of the SuperGrid or SuperHelp pages on my test system except by switching in and out of IN_DEV mode.
  When running in 'normal' mode the software appears to run correctly. But, presumably there is a performance hit. That is, in normal mode references to 'count' are still not going directly to the PHP function but are being caught by an Invision function which then calls the PHP function by forcing a reference to the root namespace. Thanks and regards,
John

Adriano,
Thanks -- seems to fix the problem. Nice!
John

Martin,
Thanks very much for the quick fix!
John

Hi Martin,
The 3.5.2 Membermap Zip will not open on Windows 10.

Thanks very much...
 

Immediately below the message format selector where it says 'Select one of the standard message formats or use 'custom' to select your own formatting options below.'

I think so.

Hi there. I'll re-work some things in this app and this one of them... it's on my to-do list (there a few first). In the meantime, you can apply a template edit. cjcontact -> front -> contact -> departmentsDescription. Find:
{$desc} Change to:
<span style='white-space:normal;'>{$desc}</span> Will looks like this:

IPS style header block for displaying messages and links across the the top of your board. Use either the built in message formats or set you own custom formatting.
Settings
Show/Hide Message. Select which groups can see the message. 4 built in message formats. Custom message format including; icon, text colour and alignment, background colour.  

IPS style header block for displaying messages and links across the the top of your board. Use either the built in message formats or set you own custom formatting.
Settings
Show/Hide Message. Select which groups can see the message. 4 built in message formats. Custom message format including; icon, text colour and alignment, background colour.  

V 1.0.8: Just done a quick update to add a couple of settings so that you can set a start and end date for the message to display.

Doing multiple messages in a nice flexible way would take a bit of work but I might have a look once 4.2 is out.

Just wanted to say thank you to Martin who fixed this very swiftly via PM

The next update will fix this.

That's fixed it thanks.

A rebuild have just been uploaded, @Edward Shephard.