Michael

I agree, reporting this in the tracker doesn't seem like the best plan. It's clearly something that has just occurred at some point in the day today, I'm sure from just something IPS was messing about with and can be quickly fixed once they see this topic.

Is there any plan at some point to allow third party developers the opportunity to have the error code information for their resources made somewhere publicly accessible, like here on the IPS site? I know Mark's been working on this to track all of IP.Board's error codes, but it'd be great if we could add our own error codes into this too. I can include the Excel file of these error codes I created for my app in a documentation folder for it, but that's really only good for the site owner, not the members who might see these errors too.

Yeah, that's true.

I wish there were a way to change the messages being displayed about bots doing things like that.

Something along the lines of "Google is being told to bugger off". ;)

Always remember, if you see a search engine spider doing something that you don't think they have permission to do, it typically means they are actually indexing an error page telling them they don't have permission to do whatever it was they were doing.

Just use the Help system, or an announcement, to create an article for your privacy policy, then skin a link to it wherever you need it to show.

Probably this:

http://community.invisionpower.com/topic/293073-error-accessing-company-forums/

on his forum

Registered as a member of these forums? Or for the software you purchased?

No. No, there is not.

ok, no worries. I would call that a furl, but no matter.

If they did something like this, then some folks would complain that they should be included in the group. Should a person who created one really big nice mod be in the group? Or should a person who created 10 small mods that don't really work be in the group? It's too hard to come up with reliable guidelines that they can set as the group requirement, and IPS has enough on their plate as it is.

You can re-enable their PM access via the ACP. Even if you do this, or there was a way to force the PM through like what you suggested, there's no way to prevent them from simply ignoring the PM.

This is a known bug, there are multiple reports of this in the Bug Tracker.

We have some plans in place for cleaning stuff up in there. The searching thing is a pain, I mentioned this in our plans as well. :)

I'm all for stronger passwords... just as long as the feature is suggestive, like a color coded meter showing how strong the password is. I HATE sites that force you to have at least 8 characters, contain 1 number and letter, and/or change your password every X amount of time.

I hope so too, I'm tired of having to tell people to re-import the hooks. :(

As it says in the fixed issue sunrisecc linked to, this issue will be fixed going forward after the 3.0.3 upgrade.

The issue is easily reproducible using the hooks mentioned that have this issue. The tracker ticket sunrisecc linked to above shows where this was reported as an issue with the 3.0.1 -> 3.0.2 upgrade. If the issue is with my hooks, I'll gladly fix them if I knew what the problem was.

EDIT: It only seems to affect hooks that add templates to skin_global, not other groups like skin_boards, as hooks like Group Name Indicator and Members Online Today are unaffected by this issue. This leads me to believe the problem is not with the hooks themselves, but with how skin_global is being handled by IP.Board.

Does't do it at my site, or here, you should open a ticket for support or post in the peer-to-peer forums.

Curse you, Charles. Curse you! :devil:

I'd really love to see a skin differences report as well as a diff of the CSS between 3.0.2 and 3.0.3. :)

..Al

Simple, perhaps stupid question: How will this update affect plugin blocks created in CCS on 3.0.2?

Will they still work or will I have to create the blocks again in order to keep it working? Since plugins are created from source of board..that might be changed by this update...

Thanks for explanation

Elanor

Okay. Been speaking with him, should have got it sorted now. Despite the fact that the IPB guide says cache etc should be 777, they work fine on 755. Someone please tell me why we're asked to chmod to 777 when 755 works fine?

When will we start getting update packs rather then having to download everything again?

you say upload all fiels for the upgrade from 3.0.2 to 3.0.3 ?

If I do this surly I would lose lots of modifications right ?