Robert Angle

So we have a Private Forum setup where a member can only see Topics that they themselves have started. Of course, the Staff can see them all. We have a situation where Member A posted a topic in this private area, but then random Member B got a notification that said "Member A posted a topic in Private Forum: Topic Title". When Member B clicked on it, he got the message that he didn't have permission to see the post. Fortunately, the Title/Subject itself didn't contain any sensitive information. But still, a random general member should not have had such a notification.

Turns out the problem was an old 3rd party plugin "Go to top" or "To the top" or something like that, which would put a little up arrow in the bottom corner of the screen which would send you back up to the top of the page when you clicked on it. It's gone, and now I just get to wait and see how long it takes for someone to complain about it missing, lol.

Okay. This is working and I am making some progress. I should be able to troubleshoot now that I am in. Thank you very much @Randy Calvert

Okay. Everything checked out, and I manually ran the updater. The upgrade is complete. But now the AdminCP is "unavailable" and the forum side throws a 500 error

Well this is lovely. I have completely crashed at the beginning of the upgrade process (500 Internal Server Error).

Actually, I am still on 4.7.0 I will upgrade to the latest version and see if that fixes it.

I upgraded to PHP 8.1 in preparation for the next IPS release. Now I occasionally see this error... Error: Call to undefined method DateTime::getDateInformation() (0) #0 /home/jwtalk/public_html/applications/calendar/sources/Event/Event.php(363): IPS\calendar\_Event::_findOccurances(Object(IPS\calendar\Date), Object(IPS\calendar\Date), Object(IPS\calendar\Date), Object(IPS\calendar\Date), Array) #1 /home/jwtalk/public_html/applications/calendar/sources/Event/Event.php(2127): IPS\calendar\_Event->findOccurrences(Object(IPS\calendar\Date), Object(IPS\calendar\Date)) #2 /home/jwtalk/public_html/applications/calendar/widgets/upcomingEvents.php(153): IPS\calendar\_Event::retrieveEvents(Object(IPS\calendar\Date), Object(IPS\calendar\Date), NULL, 5, false) #3 /home/jwtalk/public_html/system/Widget/Widget.php(833): IPS\calendar\widgets\_upcomingEvents->render() #4 /home/jwtalk/public_html/system/Widget/Widget.php(888): IPS\_Widget->_render() #5 /home/jwtalk/public_html/uploads/template_41_94a9d7649fb9cdbfc784d3516e61a717_global.php(18464): IPS\_Widget->__toString() #6 /home/jwtalk/public_html/system/Theme/SandboxedTemplate.php(61): IPS\Theme\Cache\class_core_front_global->widgetContainer('sidebar', 'vertical') #7 /home/jwtalk/public_html/uploads/template_41_94a9d7649fb9cdbfc784d3516e61a717_global.php(15713): IPS\Theme\_SandboxedTemplate->__call('widgetContainer', Array) #8 /home/jwtalk/public_html/system/Theme/SandboxedTemplate.php(61): IPS\Theme\Cache\class_core_front_global->sidebar('right') #9 /home/jwtalk/public_html/uploads/template_41_94a9d7649fb9cdbfc784d3516e61a717_global.php(6771): IPS\Theme\_SandboxedTemplate->__call('sidebar', Array) #10 /home/jwtalk/public_html/system/Theme/SandboxedTemplate.php(61): IPS\Theme\Cache\class_core_front_global->globalTemplate('JWTalk - Jehova...', '\n\n<div class='i...', Array) #11 /home/jwtalk/public_html/system/Dispatcher/Dispatcher.php(173): IPS\Theme\_SandboxedTemplate->__call('globalTemplate', Array) #12 /home/jwtalk/public_html/system/Dispatcher/Standard.php(113): IPS\_Dispatcher->finish() #13 /home/jwtalk/public_html/system/Dispatcher/Front.php(625): IPS\Dispatcher\_Standard->finish() #14 /home/jwtalk/public_html/system/Dispatcher/Dispatcher.php(155): IPS\Dispatcher\_Front->finish() #15 /home/jwtalk/public_html/index.php(13): IPS\_Dispatcher->run() #16 {main} What could be causing it?

AdminCP -> System -> Posting -> Links & Email Addresses

Themes don't have this setup. You're probably thinking of Applications and Plugins. To disable a theme: 1) Select the theme you want to be the default for everybody. Click the Pencil Icon (Edit) and flip the switch for "Default Front-end Theme?" and click SAVE. 2) On the same theme, click the Down Arrow Icon and select "Set as Members Theme" to force everyone to use this theme. 3) Go to the theme you want to disable, click the Pencil icon to Edit it, and then make it available to no membergroups at all. To delete a theme: Follow steps 1 and 2 above to set a new default theme. 3) Go to the theme you want to delete, click the Down Arrow Icon and select "Delete"

Well this is beyond me. I do have a couple more ideas probably not worth their salt. Maybe the Invision guys would caution against this, but maybe.... 1) rename Db.php to Db-OLD.php and then FTP the fresh Db.php file over to the server. When you see them both in the directory then you will know without a doubt it's the real deal. 2) start the upgrade process over again. None of this should actually matter, but I know when I'm grasping at straws I will try anything. Then in an attempt to at least get back online you should be able to re-upload the old version and restore your backed up database. You'll be back to 4.6.? but at least it'll be functioning. If all else fails then kiss GoDaddy goodbye, lol

I've been following this and it seems very bizarre. The screencap of your FTP client looks fine. The file is there and it's permissions are 0644 which is what it should be. My owner/group numbers are different but it looks like they may vary from person to person and they should match each other and be identical to all the other files in the directory. The file size is accurate at 80,514. It all looks good. Line 120 of my Db.php file is.... 'host' => $host ?? ini_get("mysqli.default_host"), ... which I'm sure yours is too since or else our file sizes would be off. What is the permission of the /system/ and the /system/Db/ directories? For me they are set to 0755 When you FTP'ed ALL the 4.7 package files to your server, overwriting everything, did you log any failed transfers? These are just some things I would be checking if it were happening to me.

Anytime I change anything it usually updates on the front end after a few refreshes or clicks around the site. Whenever I load a site that gets displayed like that to me, oftentimes a refresh will fix it. In the past when I was having display issues, I would have to manually delete the cache with my FTP client. I am assuming that button takes care of this for us now. IPS software has come a long way and most things can be addressed from within the software itself.

You might try going to the Support section of your AdminCP and under "Tools & Diagnostics" click the button that says "Clear System Caches".

I had previously renamed the /admin/ directory to something else and made that notation in the constants.php file. It's been this way for years. I don't recall ever changing the init.php file. Since it's in the root directory, it has now been overwritten by me manually FTPing 4.7 to my server, so I don't have the previous init.php file for comparison. But again, I don't recall every messing with this. Besides the constants.php file, I only ever mess with template code from within the AdminCP's Theme Editor. I usually update from within the AdminCP also. Unless the internal upgrade mechanism is different from FTPing the whole package (for example, maybe upgrading only imports the actual files that have changed??) I would assume init.php is overwritten with every upgrade. Somehow I missed the memo on this. I managed to fill myself in over at TAZ. I had seen the prices go up a few months back but didn't really care about that. I understand this now. And as long as this Help forum is consistently and actively monitored and responses are timely when a crisis like this arises, I'm fine with it. The missing ticket system simply came as a shock while we were already in a state of despair.

I just wanted to say that the current version still works fine with 4.7

After upgrading my test installation without a hitch, I assumed it was safe to upgrade our main community. I backed up my database to my local computer and began the installation process, which FAILED when I hit the button at the bottom of the page that showed me all the applications that would be upgrading from 4.6.12.1 to 4.7. I received an error message that said my site could not be reached. Backing up and trying again just resulted in the same message. So I did what I haven't had to do in years, and logged into the Client Area with the intent to submit a Support Ticket. But lo and behold the Support Ticket system is now non-existent and I am greeted with a message that says my plan doesn't include email support. Like, what the actual hell? I thought part of the exorbitant fees were so I had access to tech support. In the past, they would even log into my community and troubleshoot and apply fixes. Now I as a paying customer can't contact someone for help or submit a ticket anymore? Anyway.... I visited the Invision forums and did a search for "upgrade failed" and found a ton of posts from others experiencing similar issues. Apparently the problem/bug comes down to having set up a custom admin directory, like so.... mydomain.com/admin <--- this works and is acceptable mydomain.com/SecretAdminDirectory <---is gonna screw you up big time. The common answer from Invision devs is that manually visiting the upgrade URL is the solution (i.e. /admin/upgrade/ OR /SecretAdminDirectory/upgrade/). Sadly, this did not work. Now my Staff and I are having cardiac arrest at the thought of the community being down for at least the entire night. The next attempt was to do a manual upgrade. I downloaded the .zip file for 4.7 from the Client Area, unzipped it, and uploaded and overwritten all the files on the server. I also changed my constants.php file to just point to the default admin directory. Once all 7500+ files had uploaded, I pointed my browser once again to the upgrade path, /admin/upgrade/ I was taken to the AdminCP, already logged in, but I was only given an error message that said "Upgrading relies in PHP Sessions, but PHP is not configured properly on your server. You will need to contact your host to fix the issue." So I began the process of submitting a ticket to my host when I decided I would first research what a PHP session is. In brief, it's data stored on the server and not on a local machine like a cookie is. So I figured I need something from the previous URL string when my upgrade had failed, so I when through my browser history until I found the key from my very first upgrade attempt which looked like this... mydomain.com/SecretAdminDirectory/upgrade/?controller=systemcheck&key=Th15Rand0mString0fL3tt3rsAndNumb3rs And I then manually entered the URL to the upgrade path with that previous key as follows.... mydomain.com/admin/upgrade/?controller=systemcheck&key=Th15Rand0mString0fL3tt3rsAndNumb3rs This launched the Upgrader and then all the steps went as they are supposed to, updating tables, themes, etc, and then completing the upgrade and presenting me with the option to go to the AdminCP or the community. So, to recap, after the internal automatic upgrade failed, I had to take the following steps.... Download 4.7 from the Client Area Unzip it on my local drive FTP it to the server, overwriting everything Edit constants.php so that it points to the default /admin/ directory Find the previous PHP session key from my browser history Manually visit the upgrade path with the variable string/session key included Complete the upgrade Tonight was a nightmare, but I figured out a fix, and I simply wanted to share what I did to get back up and running because it's clear this is happening to others as well.

This has been our experience too. We enabled Clubs when it first came out. Initially there was a lot of buzz and several members created their own Clubs, but then it petered out. We disabled Club Forums from appearing on the main index page because with so many it ended up being a ton of clutter, so we feature them on a subsequent page and in sidebar blocks as well as with a prominent link in the masthead but by and large they are dead. We're in the process of removing the deadest of dead Clubs. When we see what is left, we're probably going to convert them to subforums and just turn the Clubs feature Off.

This is definitely a much needed feature. My Staff would love the ability to schedule posts in advance. Seems like it would be an easy implementation. Swap it out with that scheduled unlock feature which I can't fathom ever having a use for.

Awesome. I always forget about that section. I'll go test it out.

I was wondering if it is possible in the AdminCP or through a 3rd party plugin to control Club visibility/permissions on the MemberGroup level. In other words, if I have a MemberGroup called "Basic Access Members" and another group called "Premium Access Subscribers", can I make it so that those in the "Basic Access Members" cannot See, Read, Join, Post, or Reply in Clubs while the other MemberGroup(s) can? We use MemberGroups to control permissions rather than adjusting the permissions or restrictions of individual members just to keep things clean and tidy. But there seems to be a loophole here where we cannot stop a member from viewing, joining, or commenting in Clubs.

What would this entail, if I didn't want to lose any posts, members, data, etc. I am assuming a license purchase and installation, and then a Support Ticket asking for a copy of the MySQL database along with that databases login credentials to put in my Config File and in CPanel. Or is it simpler or trickier than that? Could I use WHM to copy everything from Invision's server to my own? - Bob

Thank you. The patch seems to be working. It replaces the topic titles/links they don't have permission to view with the words "content deleted". It would be nicer if it just skipped it altogether, but this is definitely better than it was.

Security Issue! I have 2 groups that are part of my staff, the Moderators and the Administrators. Both these groups have permission to see who read topics and to see the corresponding tab on a users profile. However, the list of viewed topics on an persons profile isn't filtered by who can view a certain forum. For example, I have a private forum for Administrators that Moderators cannot see, read, or even see the topic listing. Most of them don't even know it exists. However, when a moderator looks at the "Recently Viewed" tab on an Administrators profile, they can see the titles of topics recently visited that are in the Admin-ONLY forum. Now, of course, they don't have permission to read the topic, but they now know the private admin only forum exists and can see the topic title. This could be particularly embarrassing if we had a thread titled "Moderator Ed and Moderator Suzy are crazy and should be fired". The normal function of Invision software is to only display links to topics that a person has permission to read. When you visit a profile and see a list of someone's activity, what they reacted to or what they replied to, you are only seeing reactions and replies to what you yourself can read. Your application does not filter in the same way that the Invision Power Suite does by default. This is a major problem, imo. My fix for now is to exempt Administrators from having their viewed topics logged. But if a moderator notices that admins don't have anything listed in their Recently Viewed tab on their profile page, it might look like we're hiding something and sow some discord among the staff. I hope I explained this clear enough. When a group who has permission to see the tab on profiles looks at that tab, they should only see the topic titles of topics from forums they can access, just like the default behaviour of Invision software.

Yeah, I'm just referring to the text at the top of the page in the masthead. I don't want to switch to a logo, but might end up doing so. Perfect! The article you link to is very helpful. I can display one DIV with the a title in the masthead for PC, and another DIV with a shortened title in the masthead on mobile. It looks like the very examples in the article are the very code I need to implement.

In the template, is there a way that I can have a different site title display based on whether it's being viewed on a PC or on a mobile device? My site title is really long, and on a mobile device, it bleeds over the menu and navigation bars as a result. I would like to manually edit the templates to reflect logic sort of like this.... {IF SCREENSIZE=mobile} Amazing Community {ELSE} The Wonderfully Amazing Community For Various Discussions {ENDIF} Seems like this was more straightforward in 4.4 but deciphering the templates in 4.5 is a little trickier... so far.