No, you can either use one of them. I experienced that you don’t need reCAPTCHA if you use simple questions. Best spam blocking mechanism for me so far.
Posts by Black Rider
-
-
Ah okay, it just occurs if you reload the browser window in smartphone sizes. It seems that there is some Cloudflare extension enabled that adds and removes custom inline styles and thus breaks the layout. I don’t know much about Cloudflare so I think it would be better to create a ticket at the ticket support since Alexander Ebert knows the filters and functions of Cloudflare quite well.
-
Hm, I cannot reproduce the issue. At least not in Safari, Chrome and Firefox.
-
Do you have a link to the page where the problem occurs?
-
You could edit the template headInclude and remove the following line:
<meta name="viewport" content="width=device-width, initial-scale=1">
And tada, the mobile style is gone.
-
Is it really marked as error or just as info? I know at least one plugin that creates this kind of message but as the notice itself says: it just aborts. Nothing to worry here.
Is it even possible that you enabled the debug mode and that this message only occurs within the debug mode?
-
As far as I know, there is no such setting for users.
-
The easiest way would be in using different file names for different headers to force the cache to be reloaded.
-
You need to purchase an update first, as WoltLab Blog 2.1 won’t run with Burning Board 5.0 or WoltLab Suite Core 3.0.
-
I don’t think there is any possibility to do that right now out of the box. And as far as I know, there is neither a plugin for it, currently.
-
Yes, you can set it in your style settings in the administration control panel.
-
What do you mean by saying “isn’t displaying correctly”? What exactly isn’t as it should be?
-
Actually, everything should run smoothly if you just use the internal upgrade process. It may be that plugins you’ve installed are incompatible and must be uninstalled first (best case would be trying first in a test installation).
-
Actually, FontAwesome icons are also displayed on mobile devices because they will be downloaded first.
-
No, there isn’t. Except you import a backup from before these actions – however, then you will lose every new content from the time of the backup until now.
-
As long as there is no checkbox checked, the overall user group permission are responsible for the permissions. That said, as long as a user is in a user group that has these permissions, he can do these things.
-
This is no fix, this will break functionality of the software because it relies on working foreign keys. You need to add all foreign keys again and make sure that any operation that would have been done by working foreign keys is done manually before.
That’s definitely a huge amount of work. The alternative would be to setup a second WoltLab Suite and use the import to transfer your data from the broken database to the new one – which should have working foreign keys.
-
Every design that is available from us here is usable in both WoltLab Suite Core 3 and Community Framework 2:
-
To me it sounds like a problem with a too greedy security extension/rule by your hoster like mod_security.
Maybe you can find some logs in your web servers logfile.
-
Just use the selector .messageSidebar.
