BN_IT_Support

Marc, Would you move the bug report over for me? (Or do I need to re-post in the correct place?) Thanks. John

Hello, As a preamble to this bug report, I’m somewhat confused about where I am supposed to report bugs. The “Beta Discussion” in the IC5 Beta Testing club says “Got a bug? Please post it in our tracker.“ but that takes me to a no-access page. The “New public bug tracker” topic takes me to the “feedback” forum where there appear to be a lot of V4 issues? I’ll try here and see whether it gets moved ;-) I previously reported a bug where Loader::onFinish() does not get called for “database pages”. That is still the case. This report is for additional (possibly related) issues. When using the Page Editor on a simple single column page there are three widget areas - top, middle and bottom. It appears that Loader::onFinish() ONLY gets the content of the “middle” area so that the content of any widgets in the top or bottom areas does NOT get passed to Loader::onFinish(). If that is intended behaviour then it needs to be clearly documented The workaround is relatively simple (for non-database pages) → just drag and drop the widgets into the middle area and test again The next problem is for “database pages”. When a database is created under IC5 a new page is automatically created and the database widget is placed in the middle area. The issue is that the middle area is greyed out in the editor so it is NOT possible to drag and drop any other widgets into the middle area. Thus, the only option for additional widgets is to put them in the top or bottom areas but in those cases they will not appear in Loader::onFinish(). Thanks. John

Hello, This seems more complicated under V5 than under V4 and it feels like there is a bug (or at least a deficiency) here - but I'm not sure so I'm starting this as a discussion rather than a bug report... Under V4 this all seemed to work simply. I could run my test system with IN_DEV enabled and if I created a custom Database Template (e.g. type = Category List - first page when viewing a database) then it would work whether IN_DEV was enabled or not. Under V5 it appears that custom templates created this way only work when IN_DEV is disabled. As soon as IN_DEV is enabled then accessing the database gives a "NO_TEMPLATE" exception because when IN_DEV is enabled under V5 the system expects to find the template files in applications/cms/dev/html/front/databases/etc... and the files are not there. Just the fact that it used to work simply under V4 leads me to feel this is a retrograde step that should be logged as a bug. It is possible to work around the above problem by creating files in the appropriate directory. Of course, most of the file content is a straight copy-and-paste from the template file as viewed in the ACP. But, in addition to that content it is also necessary to insert the line at the top ... something like "<ips:template parameters="$category"/>". What is the expected workflow? The easy way to create templates as the starting point for customisation is in the ACP. But as described above, there is no obvious way to output the templates to files so the workaround is copy and paste with the insertion of he additional header line. The alternative would seem to be to hand-craft the files in the relevant folders and then use the "Import Developer Templates" button to upload all files as templates. That's a nice idea except there is no really easy way to create the starting point! When using the Developer Center to modify one of our applications it is possible to use the Front-End Pages Templates option to select templates to be included with the application. How does that play with the previous comments? Does this option save from the template/dev files or from the information held within Invision tables? Thanks very much. John

While I agree that it would be really great to have the V5 developer documentation "sooner rather than later", you really don't have to wait for the V5 documentation before you start some development. Use the V4 developer documentation PLUS the V5 developer blogs (https://invisioncommunity.com/developers/devblog/). The really big thing is that in V5 it is NOT POSSIBLE to use V4 style 'HOOKS'. If you read the documentation and conclude that you need a V4 HOOK then you are going down the wrong path - read the Dev Blogs and work out how to do it under V5. There are a few useful things that have been added since the V5 Dev Blogs were written and they're not documented yet. But, if you're only just starting to do your development then you're 99% OK if you (1) Use the V4 docs, plus (2) AVOID V4 HOOKS and (3) use the V5 Dev Blogs. Finally, there are people in the forum who will give you pointers if you get stuck on V5 development. John

Well, if you did not delete ALL old DEV files first -- i.e. before copying the latest dev files to your system then I strongly recommend that you check the file dates on all your dev files. (It's a lot easier and quicker to clear out the dev folders first as checking file dates of thousands of files takes time...) You're partly correct that the upgrade of a dev system will go OK. That is, it should be fine as long as you stay OUT of dev mode. If you switch to dev mode and if you did not clear out all the old dev files then there is a strong possibility that some old dev files (CSS and/or JS) will get loaded -- it's just the way that loading CSS and JS works -- it does not load individual CSS or JS files but bundles them so if the old/stale file has a name that matches one of the bundles then it will get picked up and loaded even though you don't want it. When I had stale CSS and JS files in dev mode then pretty much everything worked -- except a few things like some things did not look quite right and I ended up submitting bug reports for things that were just stale files. So, in particular, if you intend to log bug reports I suggest you make sure you don't have stale files hanging around. John

Just a warning for those thinking of upgrading from V4... I suspect that if your system was relatively recently installed (as V4) for the first time then all may well be OK. But, if your system was initially installed as V4 some time around 4th October 2019 or earlier then expect problems... If you can log in then the pages will display as blank. The issue is the following files: applications\core\extensions\core\FrontNavigation\Promoted applications\nexus\extensions\core\FrontNavigation\NetworkStatus applications\nexus\extensions\core\FrontNavigation\Referrals The above files do not exist in V5 but were present in some very old version of V4 (possibly 4.4.7 or older, but I'm not sure). The way the system loads menus is it searches for files in those folders and attempts to load them but as the files have not been converted to V5 then PHP crashes and you end up with blank pages. The 'fix' is to delete the files and your pages will automagically reappear when you refresh your browser. This has previously been reported as a bug - but the answer at that time was that the upgrade would not delete any files. Fair enough - I don't care because I know what to do. If you don't know what to do then expect to trip up 😉 I have a feeling that when I enable IN_DEV mode then I'll run into lots of problems with CSS and JS files being out of date and maybe some others. I think the best advice at this point is to delete ALL dev folders before you install the dev kit John Yes - I can confirm it works (with the warning described above). Download the V5 ZIP Unpack the ZIP Copy the folders over the top of the existing folders Browser /admin/upgrade and log in with your normal adminCP credentials (NOT you invision community credentials) Basically, follow the Installation manual "Manual Install" section. John

Hi Matt, I need an installable kit so I can start converting our many applications and plugins. I guess that probably means that I'll have to wait for beta? But the sooner that I can have an installable kit and start converting plugins and applications the better... Thanks. John

Hi, I have spent a number of days reading your IC5 development blogs and reviewing our plugins and applications to see what problems may arise and how we might solve them. Some changes are easy under your new system but others appear to have no obvious solution - and that will be a major problem for us. adminCP reports that we have 62 hooks in our applications and plugins - that is "hook files" and as some of our hook files actually contain a number of hooks (e.g. one of our Theme hook files actually hooks into 13 different places) we could have around 150 actual functional hooks. Many of the problems that we will face with IC5 appear to be because we cannot use hooks to remove functionality from the system. The following is a summary of some of the issues: Need to remove author (and any other personal information) from content displayed to certain groups. Our website is for a member organisation but also part of the website is visible to Guests (and a few other non-member groups) - and for security reasons we must conceal all personal information from Guests and non-member groups but allow it to be seen by members. We have 11 code hook files and 2 theme hook files to hide author information (replacing it with Guest information) as well as hiding the jsonLD information. Besides generic 'hide the author' it also took application specific hooks to hide download data, CMS data and calendar data - which also included RSVP sections of the calendar (no point in showing the RSVP if all the details are hidden). Hide "follow" buttons for Guests and all non-member groups. Hide comments and reviews from Guests and non-member groups. It is a member organisation so members can read content and post comments and reviews that can be seen by other members. Although we have content that can be viewed by Guests and other non-members we do not want the non-members to be able to see comments or reviews posted by members - there are two obvious reasons: (1) that some members post derogatory comments that are tolerated for viewing by other members but are not appropriate to show to non-members (2) part of the added value of being a member is that comments and reviews are visible as well as being able to post one's own comments and reviews. Disallow upload of attachments in various places - in particular, cannot add images to album descriptions, image descriptions, image comments, blog comments etc... Disallowing attachments is selective, so for example attachments can be added to forum topics and posts. Enforcement of "gallery rules". Simplistically, the gallery rule is that all uploaded images must have a meaningful and unique title and a similarly unique and meaningful description. Currently, this is enforced when uploaded images are submitted - the hook checks that suitable titles and descriptions have been entered and reports an error if the checks fail. Resizing (shrinking) images on upload. The standard IPS image size limits don't really work the way we need. File size (kB or MB) does not really relate to resolution (H and W in pixels) and in any case setting a limit gives a bad user experience as they don't know how to reduce image size to meet whatever limit we set. Our solution is to accept pretty much any image size and then reduce it to the size (HxW) that we want. This is selective according to where the image is to be stored so different resolutions are set for gallery, blogs, forum, profile, status updates, etc. Displaying maps - two actions: (1) filtering who can see maps (only member groups can) and (2) caching maps. The issue is that Google Maps started charging for use of the maps API - there is a free allowance every month but if we didn't take the above actions then we would massively exceed the monthly allowances and it would cost us a lot. Firstly, it is a member organisation so allowing non-members to run up costs (by viewing calendar maps) would not be acceptable so non-members cannot view maps - instead they are presented with a standard outline and a message stating that members can view the maps. Secondly, each event tends to be viewed multiple times by different members and if we did not take action then every view would generate a Google Maps API call which would cost us. We cache map lookups using the coordinates as the key and this reduces our costs. (This applies to other maps such as images and CMS/database maps as well.) Remove all references to the IPS newsletters and bulk mailing as we have an alternative system. (Our newsletters are managed through our membership system in conjunction with Mailchimp.) We have hooks to remove the standard newsletter widget and replace it with our own and another hook to remove notifications relating to newsletters/bulkmail. Add additional information to members displayed in the staff directory. Specifically, the hook adds the member's organisation email address (rather than their personal email address). Selectively hide poll results from SOME members for SOME polls. Specifically, forum polls are used for voting on AGM motions and it is believed that showing the current voting levels could influence voters so the results are hidden from all members (except the people collating the votes). Other polls (i.e. not AGM voting) behave normally. There are some that I have missed out that also don't have obvious solutions. Obviously, I've missed out all the hooks for which I believe there may be a solution (based on your blogs). How can I solve the above? Thanks. John

Hi, Thanks for that... What is the actual sequence for converting a V4 application to V5? Take the following as an outline... Starting with my V4 development system with IN_DEV Disable IN_DEV (as I cannot upgrade with it set) Install V5 (IPS database is converted, etc...) Presumably my application is disabled by the upgrade as it is not compatible? Enable IN_DEV What do I have to do so that I can re-enable the application and start testing file by file? I don't believe that updating all files before I can test anything is practical. In many cases I'll have to play around and test various alternatives before I find something that might work under V5. What happens to all the hooks? Do they just get deleted by the upgrade to V5? (Obviously, I could retrieve them from my other V4 development system and use them as the basis for working out what to do under V5.) What happens to the MemberSync extension(s)? Do they just get deleted by the upgrade - so I just retrieve the code from my other V4 development system and insert it into a Listener? Are all me database tables preserved by the upgrade? Similarly, what happens to a customer/live system that runs my application and upgrades from V4 to V5? Starting with live system running my application on V4 IPS is upgraded from V4 to V5. Presumably my application is disabled by the upgrade as it is not compatible? 'Customer' installs the V5 compatible version of my application -- is all now OK with no loss of data? Thanks very much. John