BN_IT_Support
-
Posts
1,808 -
Joined
-
Last visited
-
Days Won
3
5 Followers
Recent Profile Visitors
27,604 profile views
BN_IT_Support's Achievements
-
Hello, Adding image to Album description gets stuck "Uploading Attachment"... Yes, I think I remember that we should not be able to add images to the Album description in V5, but that's not the point. The point is all about "user experience" and this is bad. If you create an album and put text into the description and then either drag-and-drop an image file into the description or copy the file from Windows Explorer (^C on the file) and paste it into the description (^V) then the popup gets stuck at "Uploading Attachment" If you leave it long enough (screen display does not change to give you any clue) then the button will take you to the image upload page and you can submit an image. The image has not been uploaded and the description still shows the "Uploading Attachment" text: This is poor user experience and (presuming that I should not be able to add an image to the Album description) there should be an error message stating that images cannot be uploaded. Thanks. John
-
Hello, There is no way to edit any settings of an Album other than the title - in particular, it would be useful to be able to edit the description. Other fields, such as privacy also cannot be edited. From a gallery category=>Add Images=>Create new album Fill in title and whatever else you want - description, ownership, privacy, features, click 'Create Album' Upload one simple image From Album's main page select 'Action' dropdown and choose 'edit' or 'edit album' (it doesn't seem to make any difference) You can then change the title but not the description and not any of the other settings. Thanks, John
-
Hello, Adding a cover photo to a Blog changes the blog record and it is a user action so it really ought to trigger some sort of method/event in the UINode Blog extension -- but nothing is triggered so any changes to cover photo sneak through 'silently'. Thanks, John
-
Hello, Editing a blog description does not work. Create a new blog (simple description says "John's Blog"; category 'general') Manage Blog=>Edit Blog There are three issues! Button is wrong on 'Blog Settings' tab - it says 'Add New Category' when it should be something like 'Save' Editing description to add string 'Editing...' and then clicking the button does not appear to do anything Drag and drop of an image file into the description results in 'pluploaderr_-200' and the system log shows: ErrorException: An 200 response is being sent however the CSRF key is present in the requested URL. CSRF keys should be sent via POST or the request should be redirected to a URL not containing a CSRF key once finished. (256) #0 [internal function]: IPS\IPS::errorHandler(256, 'An 200 response...', '/home/bn2468/pu...', 1043) #1 /home/bn2468/public_html/system/Output/Output.php(1043): trigger_error('An 200 response...', 256) #2 /home/bn2468/public_html/system/Output/Output.php(1387): IPS\Output->sendOutput('{"error":"An 20...', 200, 'application/jso...', Array) #3 /home/bn2468/public_html/system/Helpers/Form/Upload.php(397): IPS\Output->json(Array) #4 /home/bn2468/public_html/system/Helpers/Form/Editor.php(695): IPS\Helpers\Form\Upload->__construct('blog_desc_uploa...', Array, false, Array) #5 /home/bn2468/public_html/system/Helpers/Form/Editor.php(215): IPS\Helpers\Form\Editor->getUploader('blog_desc') #6 /home/bn2468/public_html/applications/blog/sources/Blog/Blog.php(480): IPS\Helpers\Form\Editor->__construct('blog_desc', '<p>John's Blog<...', false, Array, NULL, NULL, NULL, 'blog_desc_wrap') #7 /home/bn2468/public_html/applications/blog/modules/front/blogs/view.php(281): IPS\blog\Blog->form(Object(IPS\Helpers\Form), true) #8 /home/bn2468/public_html/system/Dispatcher/Controller.php(128): IPS\blog\modules\front\blogs\view->editBlog() #9 /home/bn2468/public_html/applications/blog/modules/front/blogs/view.php(91): IPS\Dispatcher\Controller->execute() #10 /home/bn2468/public_html/system/Dispatcher/Dispatcher.php(169): IPS\blog\modules\front\blogs\view->execute() #11 /home/bn2468/public_html/index.php(16): IPS\Dispatcher->run() #12 {main} Thanks, John
-
Hello, I believe this bug report to be valid 😉 We have a complex application that plays around with gallery images but I disabled it (in the ACP) before doing this test... Starting with an existing album Deleted all images Added first image Added comment to first image (comment was "Add a simple comment with no images…") Click "Submit Comment" Nothing appears to happen - comment edit box remains open. But... the ACP logs show the following error: TypeError: IPS\gallery\Category::setLastImage(): Argument #1 ($image) must be of type ?IPS\gallery\Image, IPS\gallery\Album\Item given, called in /home/bn2468/public_html/applications/gallery/sources/Category/Category.php on line 627 (0) #0 /home/bn2468/public_html/applications/gallery/sources/Category/Category.php(627): IPS\gallery\Category->setLastImage(Object(IPS\gallery\Album\Item)) #1 /home/bn2468/public_html/system/Node/Model.php(1197): IPS\gallery\Category->_setLastComment(Object(IPS\gallery\Album\Comment), Object(IPS\gallery\Album\Item)) #2 /home/bn2468/public_html/system/Content/Comment.php(490): IPS\Node\Model->setLastComment(Object(IPS\gallery\Album\Comment), Object(IPS\gallery\Album\Item)) #3 /home/bn2468/public_html/applications/gallery/sources/Album/Comment.php(151): IPS\Content\Comment->postCreate() #4 /home/bn2468/public_html/system/Content/Comment.php(336): IPS\gallery\Album\Comment->postCreate() #5 /home/bn2468/public_html/system/Content/Item.php(4943): IPS\Content\Comment::create(Object(IPS\gallery\Album\Item), '<p>Add a simple...', false, NULL, NULL, Object(IPS\Member), NULL, NULL, NULL, NULL) #6 /home/bn2468/public_html/system/Content/Item.php(4560): IPS\Content\Item->processCommentForm(Array) #7 /home/bn2468/public_html/system/Theme/Theme.php(3706) : eval()'d code(169): IPS\Content\Item->commentForm() #8 /home/bn2468/public_html/system/Theme/Dev/Template.php(151): IPS\Theme\theme_gallery_front_browse_albumComments(Object(IPS\gallery\Album\Item)) #9 /home/bn2468/public_html/applications/gallery/sources/Album/Item.php(598): IPS\Theme\Dev\Template->__call('albumComments', Array) #10 /home/bn2468/public_html/applications/gallery/modules/front/gallery/browse.php(453): IPS\gallery\Album\Item->commentReviews('comments') #11 /home/bn2468/public_html/applications/gallery/modules/front/gallery/browse.php(178): IPS\gallery\modules\front\gallery\browse->_album(Object(IPS\gallery\Album)) #12 /home/bn2468/public_html/system/Dispatcher/Controller.php(139): IPS\gallery\modules\front\gallery\browse->manage() #13 /home/bn2468/public_html/system/Content/Controller.php(124): IPS\Dispatcher\Controller->execute() #14 /home/bn2468/public_html/applications/gallery/modules/front/gallery/browse.php(81): IPS\Content\Controller->execute() #15 /home/bn2468/public_html/system/Dispatcher/Dispatcher.php(169): IPS\gallery\modules\front\gallery\browse->execute() #16 /home/bn2468/public_html/index.php(16): IPS\Dispatcher->run() #17 {main} Thanks, John
-
Hello, This bug was mentioned in https://invisioncommunity.com/ic5bugs/bugs/beta4-badmethodcallexception-no_template_file-wrong-case-for-template-file-name-r290/ but is a separate bug in its own right so it is being logged separately here... What I have done to reproduce this problem: Copied the files/folders under applications/cms/dev/html/database/display to display_test_weir In the ACP clicked 'Import Developer Templates' - this imported the template but as Esther has said it does not offer it when you attempt to select a template under the ACP edit database. The issue is that importing the templates as above does not set the 'template_original_group' to one of the allowed values (category_index, listing, display, form) so when you edit a database the ACP does not know where to offer the new template group. The workaround is to use SQL to: update `cms_templates` set template_original_group = 'display' where template_original_group = 'display_test_weir'; to work around the above bug and make the template group visible in the ACP. At that point I was able to set the template Thanks. John
-
Hello, This bug was mentioned in https://invisioncommunity.com/ic5bugs/bugs/beta4-badmethodcallexception-no_template_file-wrong-case-for-template-file-name-r290/ but is a separate bug in its own right so it is being logged separately here... There are scenarios where editing a template (in the ACP) can lose template_original_group from the record in cms_templates. When this happens the option to 'compare with default' no longer works. I have done three tests and only one of these failed: OK: Edit a single line in 'reviews' and save -> compare with default works OK OK: Delete all content from 'comment' and save -> compare with default works OK Fail: Copy all content from 'reviews' and paste into 'recordEditLine' and save -> compare with default shows the default as empty (i.e. not the original). There is also another symptom that is almost certainly related... Under Beta4 when the above occurred the template would show up as 'Custom' (letter 'C' on yellow disc) instead of 'Modified' (letter 'M' on red disc). I think that one of the developers must have tweaked cms between Beta4 and Beta5 but in my opinion they got it wrong. They 'concealed' the loss of 'template_original_group' by always display the 'M' on red disc - what they should have done is fix the bug that loses 'template_original_group'. So now when you fix the bug that loses 'template_oroginal_group' you will also need to reverse the change that was done between Beta4 and Beta5 so that genuinely custom templates show up as 'C' on yellow disc. Thanks very much. John
-
Hi Esther, Thanks very much for your response. Argh! I made the report under Beta4 and am now running Beta5. Also, I cannot remember precisely what I did under Beta4 -- at the time it appeared to me to be an entirely normal sequence (nothing strange like zapping the database directly, for example), but it is entirely likely that when I imported the template it actually updated an existing template. In short, "something has changed" -- either a change between Beta4 and 5 or else the sequence being used to reproduce the problem. My thought is to move forward from where we are rather than worry about something that I can no longer reproduce. What I have done... Copied the files/folders under applications/cms/dev/html/database/display to display_test_weir In the ACP clicked 'Import Developer Templates' - this imported the template but as you said it does not offer it when you attempt to select a template under the ACP edit database. The issue is that importing the templates as above does not set the 'template_original_group' to one of the allowed values (category_index, listing, display, form) so when you edit a database the ACP does not know where to offer the new template group. This is a bug in its own right. I'd be happy to log a separate bug report if required, but you seem to be onto this one anyway! SQL: update `cms_templates` set template_original_group = 'display' where template_original_group = 'display_test_weir'; to work around the above bug and make the template group visible in the ACP. At that point I was able to set the template but display worked OK so the original problem could not be reproduced. There is an additional bug that showed up while I was poking around to investigate this problem - please let me know if you want me to log a new bug (or will you just pick it up from here?)... There are scenarios where editing a template (in the ACP) can lose template_original_group from the record in cms_templates. When this happens the option to 'compare with default' no longer works. I have done three tests and only one of these failed: OK: Edit a single line in 'reviews' and save -> compare with default works OK OK: Delete all content from 'comment' and save -> compare with default works OK Fail: Copy all content from 'reviews' and paste into 'recordEditLine' and save -> compare with default shows the default as empty (i.e. not the original) Thanks very much. John
-
Hello, I was in the front-end (not ACP) and selected a record that I wanted to feature. I clicked 'feature' and received the following error: TypeError: IPS\File::get(): Argument #2 ($url) must be of type IPS\Http\Url|string, null given, called in /home/bn2468/public_html/applications/cms/sources/Records/Records.php on line 1659 (0) #0 /home/bn2468/public_html/applications/cms/sources/Records/Records.php(1659): IPS\File::get() #1 /home/bn2468/public_html/system/Content/Controller.php(4635): IPS\cms\Records->contentImages() #2 /home/bn2468/public_html/system/Dispatcher/Controller.php(128): IPS\Content\Controller->feature() #3 /home/bn2468/public_html/system/Content/Controller.php(125): IPS\Dispatcher\Controller->execute() #4 /home/bn2468/public_html/applications/cms/sources/Databases/Dispatcher.php(372): IPS\Content\Controller->execute() #5 /home/bn2468/public_html/applications/cms/modules/front/pages/page.php(234): IPS\cms\Databases\Dispatcher->run() #6 /home/bn2468/public_html/system/Dispatcher/Controller.php(128): IPS\cms\modules\front\pages\page->__call() #7 /home/bn2468/public_html/system/Dispatcher/Dispatcher.php(169): IPS\Dispatcher\Controller->execute() #8 /home/bn2468/public_html/index.php(16): IPS\Dispatcher->run() #9 {main} A little bit of diagnosis shows that the problem field is the following: As you can see, the field is NOT required. I had not uploaded an image to the record and this resulted in the exception described above. I then uploaded an image to the record/field and was then able to 'feature' the record - pretty much proving that the bug is to do with missing image/upload contents for fields that are NOT required. Thanks. John
-
Hello, Running in IN_DEV=true mode... I created a database template in the following folder: /home/bn2468/public_html/applications/cms/dev/html/database/holiday_featured_records I then clicked "Import Developer Templates" and this created a template within the ACP that I could view with name "Holiday Featured Records" (that is replacing all underscore with spaces and uppercasing the capital letters). I then attempted to use the template with a database and when viewing the index page received the error: BadMethodCallException: NO_TEMPLATE_FILE - /home/bn2468/public_html/applications/cms/dev/html/database/Holiday_Featured_Records/index.phtml As you can see from the above, the changes to the name implemented by the "Import Developer Templates" button was not correctly reversed when using the template in IN_DEV mode. The spaces in "Holiday Featured Records" were correctly replaced with underscores. But, the uppercase capital letters were not lowercased as they should have been... Thanks. John
-
Sorry -- ignore that!! I've just realised that it is a Firefox issue, not an issue with Invision. I was using Edge with V4 and the colour box allows entry of the colour code. But for V5 I was using Firefox and the Firefox picker does not allow entry of the colour code. I'm not sure whether there is any workaround that you could implement - but I suspect not. I'll just have to remember to use Edge when I need precise colour codes. Sorry! John
-
Hello, With reference to the following, when editing a Calendar: Under V4 it was possible to set the colour by overtyping the value in the Color box with something else - for example #c0c0c0. This is important when a precise colour must be specified. Under V5 Beta4 this is not possible and the only way to set the colour is by using the colour picker. This is tedious and error prone when the precise colour code is already known. Thanks. John
-
Hello, I get an OutOfRangeException in ACP when using 'Page Editor' (wizard). The OutOfRangeException is not the issue (!!) - I have a RawHTML widget and included "{{$record = $record_class::load(4);}}" when record number 4 does not exist -- so I know what I did and it's all my fault. The issue is the way the ACP handles the error. I know what I need/want to do -- I want to go back in and edit the RawHTML widget to include a valid record number but I cannot do that because the ACP displays the OutOfRangeException where the RawHTML widget should be and I cannot do anything at that point - I cannot delete the widget and start again and I cannot edit the widget contents. What should happen is that the widget should catch the error and display it but should allow the widget to be deleted and/or edited to fix the problem. On this particular occasion, I'm not that worried about how I'll work around the problem. I know what I did and can easily create a record to resolve the issue (or can zap the widget in the database or whatever) -- I am more concerned about the way the ACP is behaving and the fact that it does not handle this scenario in a way to make it easy for other administrators to dig their way out of the hole. Thanks. John OutOfRangeException: (0) #0 /home/bn2468/public_html/applications/cms/sources/Databases/Databases.php(294): IPS\Patterns\ActiveRecord::load() #1 /home/bn2468/public_html/system/Theme/Theme.php(3678) : eval()'d code(9): IPS\cms\Databases::load() #2 /home/bn2468/public_html/applications/cms/widgets/Codemirror.php(140): IPS\Theme\content_widget_39e47d() #3 /home/bn2468/public_html/system/Widget/Widget.php(1291): IPS\cms\widgets\Codemirror->render() #4 /home/bn2468/public_html/system/Widget/Widget.php(1391): IPS\Widget->_render() #5 /home/bn2468/public_html/system/Widget/Area.php(914): IPS\Widget->__toString() #6 /home/bn2468/public_html/system/Theme/Theme.php(3678) : eval()'d code(186): IPS\Widget\Area->getWidgetContent() #7 /home/bn2468/public_html/system/Theme/Dev/Template.php(151): IPS\Theme\theme_core_front_global_widgetArea() #8 /home/bn2468/public_html/system/Widget/Area.php(273): IPS\Theme\Dev\Template->__call() #9 /home/bn2468/public_html/system/Theme/Theme.php(3678) : eval()'d code(115): IPS\Widget\Area->__toString() #10 /home/bn2468/public_html/system/Theme/Dev/Template.php(151): IPS\Theme\theme_core_front_global_widgetArea() #11 /home/bn2468/public_html/system/Widget/Area.php(273): IPS\Theme\Dev\Template->__call() #12 /home/bn2468/public_html/applications/cms/sources/Pages/Page.php(2177): IPS\Widget\Area->__toString() #13 /home/bn2468/public_html/applications/cms/sources/Pages/Page.php(2071): IPS\cms\Pages\Page->getPageContent() #14 /home/bn2468/public_html/applications/cms/modules/front/pages/page.php(122): IPS\cms\Pages\Page->output() #15 /home/bn2468/public_html/applications/cms/modules/front/pages/page.php(49): IPS\cms\modules\front\pages\page->view() #16 /home/bn2468/public_html/system/Dispatcher/Controller.php(139): IPS\cms\modules\front\pages\page->manage() #17 /home/bn2468/public_html/system/Dispatcher/Dispatcher.php(169): IPS\Dispatcher\Controller->execute() #18 /home/bn2468/public_html/index.php(16): IPS\Dispatcher->run() #19 {main}
-
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
-
BN_IT_Support reacted to a comment:
[Beta3] Database imported from V4 has broken category information...
-
BN_IT_Support reacted to a comment:
[Beta3] Database imported from V4 has broken category information...
-
Hello, When configuring (in ACP) Pages->Blocks->Plugin->Categories it lists all the categories, not just the relevant ones. For example, I am configuring a feed from our Regional News database - we only have 7 regions so there are only 7 categories in the database and these would be the relevant categories. The dropdown for Categories in the ACP lists all categories for all databases -- which might be 100 or so (I did not have the energy to count - I just know that it took a lot of scrolling to find the categories that I wanted). Thanks, John
