Robert Angle

I think that may be it!
Found the setting. Took a screen shot of an example post that required approval and a shot of the area of the menu.
"If link is posted"
I changed the option to allow.
This issue has plagued me for a long while. Thank you very much.

I blame it being Friday, personally 😄 
This appears to have already been deleted. Please let us know if you have any further issues of course

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"
 

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

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.

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.

Our auto-upgrader in the ACP, does only track what is changed version to version and applies that in the upgrade. However, you would receive an alert to any manually modified files during the upgrade or in the Support tab of the ACP. 
The notice should have gone out last year. It may be worth double checking the email address on file in the Client Area for your account just to ensure. This way you can get your information "straight from the horses mouth" 🙂 .

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

Could I ask how you have your admin directory set up? Have you by any chance changed the init.php file to do this? If so, this may well be what is causing your issue. Please could you clarify that first of all? If you have any issues going forward on these, please do let us know before you continue so that we can take a look. 
We have simply moved where we do support. We are still here (Hi! 🙂 ) dont worry. This forum is now fully staffed, and if anything does need to be escalated we can get it to a ticket from here and get it to our devs. We can access your details are normal too. Its simply a change in how we issue support, not a removal of support

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.
 
 
 
 
 

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.
 
 
 
 
 

From my own experience it depends on the setup.
There's probably no usage if you're ONLY using forums, but once you use also other content types, it can really help a lot to "categorize" all the different stuff.
I'm also not a fan of allowing people to create their own clubs, instead they can request one which is a just a custom form with a title, description and "internal explanation" field and  it's an administrator/moderator privilege, to control this which really helps to avoid the mess.
 

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.

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.

Thank you Robert this is gold dust! Following those steps anonymous users to my forum cannot simply guess profile URLs and lookup my members photos, avatars, usernames and so on. User have to authenticate before they can see individual member details. Such an important privacy feature which needs more prominence in the getting started guide by Invision Community...

You can control who has access to the clubs app here ...

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.

There is a chance I'll be pushing this to an application, and that's going to mean almost certainly, a re-buy (no way to sync with the new ACP Marketplace). If I have to do that, I'll be leaving the purchase price at like $10 for a month or two to ease the pain.
Why? Standards are up considerably with marketplace code reviews and there is a nominal chance, possibly reported once before but most sites using this plugin never usually hit this, that a deleted/merged member causes problems... and I can't handle those problems with a plugin - only apps have the capability to deal correctly with these hitches (well, the way IPS wants them dealt with anyways. I can get around it easily enough but I doubt it would pass review...)
On the plus side, you'll be getting more options, ACP previews, a name-only table popup option (vs. avatar display) and I think I'll throw a super wide table view option on that as well for those that are using this more for mod purposes (that might have to wait for the version after though). Yes, old data would be retained of course (database table copied over, then the plugin removed after the app is installed automatically).
I was 85% through the re-write for 4.5 when I saw my old note about this hitch and was like... yeah...
EDIT: You know what? This plugin does work fine as-is with 4.5 so all y'all are safe, it's just not going to be in the ACP Marketplace. I'm pushing this to an app, and I'm going to roll it all in: Forums, Blogs, Gallery, calendar I guess. Downloads, Commerce and Pages will be low-priority, but Forums out of the gate and then the others.

This is in-progress right now. 

So we have this problem in our community where we developed a "dark mode" template for members who just prefer things that way, whether it is easy on the eyes or to save battery on their mobile devices. However, we've run into this conundrum and cannot seem to fix it....
We have "Paste behavior" set to Rich Text with giving the members the option to paste as Plan Text instead. If a member copies text that was originally designated as black and pastes it into the his post, the black text color attribute carries over into the post as part of that Rich Text. Members who use our dark mode template, in which the content area is black, will not see any quoted text, because it matches the background.
Obviously, we could change "Past as Rich Text" always to "Paste as Plain Text" always, and we did that, then got a fair amount of complaints, so we switched it back. It's now an issue of a small amount of dark theme lovers vs the small amount of paste-as-rich-text lovers. If we could retain the Rich Text but strip away the text color attribute that would be perfect. We just need all text to be "default" so that it shows up dark on the white background and as light on the dark background.
It there a way to make this happen by modifying something in the Invision code or the CK Editor code?

This is interesting. I too think it would be beneficial to have push notifications. I would think that a simple app that could display push notifications and then open links in a browser would be fairly easy to accomplish. However, I have never got my feet wet with Android or iOS.

Do you have a link to check your website? 
And do you have any kind of custom blocks? with html, js...etc codes in it? 
No one reported something like that and im personally using the advanced footer with most of the app feeds, no problems at all.
also, the gallery feed block are not full sized images in footer block, you can check them out. 
 
--
Sorry for the late reply, Please mention my name when post somethin in my topics because i do not get any notifications unless my name is mentioned or quoted 

What's New in Version 1.1.0:
Compatibility with Post Before Registering. IPS 4.4 only!