BN_IT_Support

Hello, Self hosted. Normally I would keep our website relatively up to date but in this case we got stuck at 4.6.12.1 because one of our other critical bits of software (FileRun) did not support PHP8/PHP8.1. I would like to be able to upgrade Invision and FileRun separately so that I don't end up with failed upgrades in both components at the same time. I am now in the situation where: My current Invision (4.6.12.1) does not work on PHP8.1 (I tried it and the Calendar died) The latest Invision (4.7.11.1) does not work on PHP7.4 (running on my system) My current FileRun does not work on PHP8.1 The latest FileRun does not work on PHP7.4 My thought is that upgrading Invision to 4.7.3 would give me an intermediate point which could run either PHP7.4 or PHP8.1 and would allow me to switch the PHP version back and forth while I sort out the FileRun issues. (Once FileRun has been upgraded and is operating OK then I would upgrade Invision to the latest, anyway...) If there is a better way to address this topic then I'd be interested to hear about it. If this is the best way then please may I have Invision 4.7.3 so that I may upgrade to that intermediate point? Thanks very much. John

Hello Support... I followed the topic at: In addition to the main problem, the guide does not properly describe the naming and creation requirements: Layout name must start with "layout_" and cannot just be any old name that you choose - as in the document. You must not just copy all the settings to the "_preview" template as the base template has a single variable ($users) whereas the "_preview" template does not have any variables. The main problem occurs when using admin to create or edit a staff directory to specify the layout. The admin utility is forced to "Theme zero (id=0)" and you cannot follow the instructions in the document to edit this theme. The result is that the admin utility cannot find your custom layouts so they never get offered when creating or editing a staff directory. That's it. If you access the database directly and insert your custom layout name into the relevant records in core_leaders_groups then when users view the staff directory it works OK and your custom layout is picked up. (If you then use admin to edit the staff directory then it loses the custom group from that particular directory because admin cannot see it.) Having wasted a lot of time following the document and trying to get it to work, I now believe that a better method for our particular scenario is to hook into the 'layout_blocks' template and add our additional fields via the hook. In our scenario that has the added benefit that when we disable/delete our application (or plugin) it will also leave the directory definitions in a clean state that will continue to work (without the additional information). Regards, John

Hello Adriano, I thought that "Contact Us" always used to work correctly (past 5 years, at least) but it now seems to be completely broken and departments appear to not work. I'm not sure exactly when the problem started but we recently upgraded Invision to 4.6.5.1 and Contact Us to 1.3.4 and that appears to have broken things. I have uninstalled Contact Us from our test system (bntest.org.uk) and reinstalled it from the marketplace but the problem seems to be just the same. When I use Contact Us it does not matter which department I select (we have 5 departments) as they all behave the same. The email is ONLY sent to Settings::i()->email_out plus the submitter if the submitter requests a copy. The email does NOT get sent to any of the members of the department. Our departments are set up with no groups selected, only one additional email for each group. Examination of the PHP indicates that groups and additional email addresses should be handled the same way. In Contact\Contact.php it seems to do the send of the email. Before the send of the email it is built by a call to buildEmail(). The function buildEmail seems to accumulate all members of the department group and of the additional emails under the variable $staff and then assign it to $this->cc. The function also accumulates Settings::i()->email_out and optionally the user email under $email and assigns this to $this->to. The email is then sent to $this->to and the $this->cc appears to be ignored. Well, I don't want the email sent to Settings::i()->email_out and I only want it sent to the list that you accumulated under $staff plus optionally the user. I thought that that was the way that it used to behave before 1.3.4. Thanks very much. John

In June and July this year we successfully used the "Elections System" for elections of our Directors and Executive Committee. Only members can vote. All members are eligible to vote for some positions whereas other positions are regional so only those members residing within that region are eligible to vote. This was so easy to set up within the Elections System! Before deciding to use the Elections System we looked at alternative products but could not find any that integrated with our membership database - let alone in such a straightforward way. Also, we approached 3rd party organisations to get quotes for the cost of running our elections. Quotes were returned upwards of £300 for one-off elections and we would have to pay the same for next year's elections and so on. (I believe the quotes were under-estimates because they did not fully understand the complexity.) Was this a cost effective solution? Go work it out for yourself! Driven by Covid-19 (and a desire to move into the 21st Century) we will also be doing online voting for our AGM Motions - but they will use the "polling" function built into the forums. Back to the Elections System and our experience. We used version 1.0.4 because that was the version that we tested before going live. I note that 1.0.9 has been released and it enhances a few things - which is really great! Previously you had to create an "Organisation" and add all nominees to an organisation - which was a pointless extra step for us as we only have one organisation (and the IPS group structure is the way to manage regional eligibility to vote). Organisations are now optional which saves that extra step. Thanks! Nominees may now attach their "manifesto" ("election address") to their avatar in the ballot so that potential voters can click on the manifestos before deciding who to vote for. Thanks! There are still a few quirks with scope for improvement, but I certainly recommend this product. Quirks: For a nominee who is not in an organisation their avatar on the ballot shows a failed image load at the lower right (they have no organisation image to load at this point) When you click on the "manifesto" link for a nominee the manifesto pops up fine (which is good) but the title shows "json--1--" It would be good if there was an option to hide the "running total of votes" during the election. Furthermore, at the end of the election only the election officials (perhaps one or more selected groups) should be able to see the results. Certainly, the election officials should see the results before the voters so that any disputes can be resolved. (We have our own plugin to hide the running totals -- so that's an easy thing to do.) Other than that - great work! Thanks John

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...

Hello - Version 1.2.0 fails (on IPS 4.3.5) - I've had to back out to 1.1.17 which still seems to work OK. The problem is somewhat strange - it seems to work once after flushing the cache and then fails repeatedly. Flush the cache and it works once and then goes back to failing repeatedly. The implication is that the cache hold something stale (either that, or the process of creating the data to go in the cache also sets up something as a side effect so that un-cached first time works). (When I say "flush the cache" I mean going into adminCP "Support" option and then selecting "Something isn't working properly".) We have the same problem on both 'test' and 'live' systems. System Log shows: ParseError: syntax error, unexpected ';' (0) #0 /var/www/vhosts/bn.org.uk/httpdocs/system/Theme/Theme.php(4291): IPS\_Theme::runProcessFunction('\tfunction email...', 'email__cjcontac...') #1 /var/www/vhosts/bn.org.uk/httpdocs/system/Email/Email.php(780): IPS\_Theme::makeProcessFunction('New Contact Us:...', 'email__cjcontac...', '$member, $name,...') #2 /var/www/vhosts/bn.org.uk/httpdocs/system/Email/Email.php(328): IPS\_Email::devProcessTemplate('email__cjcontac...', 'New Contact Us:...', Array) #3 /var/www/vhosts/bn.org.uk/httpdocs/system/Email/Outgoing/Php.php(41): IPS\_Email->compileSubject(Object(IPS\Member)) #4 /var/www/vhosts/bn.org.uk/httpdocs/system/Email/Email.php(518): IPS\Email\Outgoing\_PHP->_send(Array, Array, Array, NULL, NULL, Array) #5 /var/www/vhosts/bn.org.uk/httpdocs/applications/cjcontact/sources/Contact/Contact.php(108): IPS\_Email->send(Array) #6 /var/www/vhosts/bn.org.uk/httpdocs/applications/cjcontact/sources/Contact/Contact.php(85): IPS\cjcontact\_Contact->sendEmail(Array) #7 /var/www/vhosts/bn.org.uk/httpdocs/applications/cjcontact/sources/Contact/Contact.php(68): IPS\cjcontact\_Contact->sendRecord(Array) #8 /var/www/vhosts/bn.org.uk/httpdocs/applications/cjcontact/modules/front/contact/contactus.php(36): IPS\cjcontact\_Contact->form() #9 /var/www/vhosts/bn.org.uk/httpdocs/system/Dispatcher/Controller.php(96): IPS\cjcontact\modules\front\contact\_contactus->manage() #10 /var/www/vhosts/bn.org.uk/httpdocs/applications/cjcontact/modules/front/contact/contactus.php(25): IPS\Dispatcher\_Controller->execute() #11 /var/www/vhosts/bn.org.uk/httpdocs/system/Dispatcher/Dispatcher.php(146): IPS\cjcontact\modules\front\contact\_contactus->execute() #12 /var/www/vhosts/bn.org.uk/httpdocs/index.php(13): IPS\_Dispatcher->run() #13 {main} Thanks very much. John

I think so.

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.'

Are you sure you’ve selected the custom formatting option?

It definitely works on 4.2.2 so it must be a glitch with the install. You could either add the missing column manually: \IPS\Db::i()->addColumn( 'core_members', array( 'name' => 'ebsGlobalMessage_dismissed', 'type' => 'BIT', 'length' => 1, 'null' => FALSE, 'default' => 0, 'comment' => 'If 1, the user has dismissed the global message' ) ); or you could remove the drop statement from the uninstaller. Go to: yoursite/plugins/globalheadermessage/uninstall.php and remove / comment out the last line: \IPS\Db::i()->dropColumn( 'core_members', 'ebsGlobalMessage_dismissed' ); then try again to uninstall and reinstall the plugin.

Thanks. Also I have a user who is required to have all of his content approved before it appears, yet he seems to have been able to add a marker to the map without approval. Is this something that could be picked up in future versions as well please?

Would it be possible for a future version to at least have an option to show/hide the staff section, or the entire sidebar, please.

How do you change which members appear in the Staff Members sidebar please?

Yeh I looked in the logs, but you're probably correct that they have been pruned by now. Thanks.

I have a few members on my site who are showing in the admin CP as 'This member must be approved manually'. Can anyone tell me why please? I don't require administrator validation and they're not showing as spammers. Are there any other reasons for the system to ask for a manual validation? Is there any way of seeing why someone has been flagged this way? Thanks

Okay if you can't uninstall or install it as a new version I may need acp access to take a look. Can you PM me.

Immediate guess is that the DB column didn't install correctly in the first place and the system therefore can't find it to uninstall it. Have you tried reinstalling?

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.

I haven't tested it with custom themes so it will depend on how it's been modified.

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

When i try and view the profile for one of my users I get: 1S160/2 - The page you requested does not exist. If I disable Member Map it works fine but if I reenable MM the error reappears. System log says: Error: Call to a member function getTimestamp() on null (0) #0 ../httpdocs/community/applications/core/modules/front/members/profile.php(224): IPS\Content\Search\_Results->addExtraItems(Array, Object(IPS\Member)) #1 ../httpdocs/community/system/Dispatcher/Controller.php(96): IPS\core\modules\front\members\_profile->manage() #2 ../httpdocs/community/applications/core/modules/front/members/profile.php(65): IPS\Dispatcher\_Controller->execute() #3 ../httpdocs/community/system/Dispatcher/Dispatcher.php(129): IPS\core\modules\front\members\_profile->execute() #4 ../httpdocs/community/index.php(13): IPS\_Dispatcher->run() #5 {main} with a backtrace of: #0 ../httpdocs/community/init.php(511): IPS\_Log::log('Error: Call to ...', 'uncaught_except...') #1 [internal function]: IPS\IPS::exceptionHandler(Object(Error)) #2 {main} As far as I can tell from looking in ibf_membermap_markers the user doesn't currently have a marker, but the error definitely comes and goes depending on whether or not MM is enabled. Welcome some help please?