XenForo 2.0 Discussion

[Chris D]

I think I read a while back you might lose your addon data, as Xenforo LTD migration won't know what addon tables you use.
I am likely wrong.

I vaguely remember seeing this conversation somewhere. Was it in the context of an XF to XF import or something similar? If so then that statement is true; if we do an XF to XF import, we can only import the XF content we know about which would exclude most add-on related data.

In terms of this upgrade, however, we are aiming to do a normal upgrade - just like we'd do from 1.4.x to 1.5.x or even 1.5.x to 1.5.y. In a normal upgrade we do not touch anything to do with add-on data so the data will still be there post upgrade to XF 2.0 ready for add-on developers to do whatever they need to do to their code or data to make it 2.0 ready.

 

[Arty]

On 2.0 screenshots I see some icons that look like FontAwesome stuff. Is it done via hardcoded HTML, like

<i class="fa fa-whatever" />

or with css like

.whatever:after {
  content: '\f123';
  font-family: FontAwesome;
}

or any other way?

 

[Chris D]

A mixture of both, depending on what's most appropriate.

 

[CyberAP]

On 2.0 screenshots I see some icons that look like FontAwesome stuff. Is it done via hardcoded HTML, like

<i class="fa fa-whatever" />

or with css like

.whatever:after {
  content: '\f123';
  font-family: FontAwesome;
}

or any other way?

The first way is already semantically incorrect by the way. As the spec says:

The i element represents a span of text offset from its surrounding content without conveying any extra emphasis or importance, and for which the conventional typographic presentation is italic text; for example, a taxonomic designation, a technical term, an idiomatic phrase from another language, a thought, or a ship name.

Font awesome icons do not represent text content, they only work as text elements.

 

[Arty]

Yes, its semantically correct, but I'm worried about customization.

If its added via css, its easy to replace icon with image or another glyph font. But using glyph as class name like <i class="fa fa-whatever" /> makes customizing it a bit more complex because it might require reverting all FontAwesome rules in addition to XenForo stylesheet rules and such changes might conflict with other code that uses same glyph for different purpose.

I'd prefer if class names were more semantic, like <span class="alert moderated" /> or similar code, and glyph added as pseudo element in css.

 

[DRE]

can y'all throw in a blackjack minigame for xf 2.0?
or a casino.

 

[CyberAP]

Yes, its semantically correct, but I'm worried about customization.

If its added via css, its easy to replace icon with image or another glyph font. But using glyph as class name like <i class="fa fa-whatever" /> makes customizing it a bit more complex because it might require reverting all FontAwesome rules in addition to XenForo stylesheet rules and such changes might conflict with other code that uses same glyph for different purpose.

I'd prefer if class names were more semantic, like <span class="alert moderated" /> or similar code, and glyph added as pseudo element in css.

You mean hardcoded symbols in html? Like <span>&#9824;</span>? You can change that, just set font-size to 0 and add new symbol with pseudo-element.

 

[Chris D]

I'd prefer if class names were more semantic, like <span class="alert moderated" /> or similar code, and glyph added as pseudo element in css.

They are mostly semantically named already. For example:

<button class="button button--icon button--icon--save">Save</button>

This would get you the button styling, set up the button with an icon styling and specifically add the save icon. A cut down version of the LESS:

.button
{
    &.button--icon
    {
        &--save::before { content: '\f0c7'; }
    }
}

There's certainly more of this kind of usage than using the <i /> element itself. Arguably some of the areas we've used the <i /> approach aren't essential so we may review that. It's possible that not all inline usage will disappear though. You may remember the screenshot of the Edit Navigation page:

Notice there's an icon field. For ease of use, that just expects people to type in the FA icon name there, e.g. fa-comments-o, so it's unlikely we'll remove all inline usage of icons as in some contexts it makes sense.

I agree it may make switching it out for a different font's icon more difficult, but I'm fairly sure it shouldn't be too problematic or impossible.

 

[Arty]

They are mostly semantically named already. For example:

Perfect! Thanks.

I agree it may make switching it out for a different font's icon more difficult, but I'm fairly sure it shouldn't be too problematic or impossible.

Those are entries customizable by user in admin panel, so it makes sense.

 

[tommydamic68]

On 2.0 screenshots

Where are there 2.0 screen shots?

 

[Chris D]

https://xenforo.com/community/threads/xenforo-2-0-development-updates.113262/#post-1088612

 

[Digital Doctor]

Looks like Nodes as Tabs is part of the core now.

 

[Paul B]

That has already been mentioned several times.

https://xenforo.com/community/threads/xenforo-2-0-development-updates.113262/#post-1088612

To clarify, it's not related to the nodes as tabs add-on, it's a completely separate, newly-developed interface.

 

[Wesker]

It won't be a migration, it will be an upgrade.

Thank you! Great news.

 

[Lucas]

Looking so forward to the navigation manager. To me that has got to be like the best feature. With that you you can easily build a site with the default XenForo installation.

 

[king8084]

@Chris D mate will 2.0 have an option to force a password criteria to a usergroup ? i know there is an add on for it but i hope it becomes xf core

 

[Chris D]

No plans as yet.

Such password criteria, in terms of enforcing certain types of characters, is somewhat redundant.

For example, it would just encourage people to use something like Pa55word! which is essentially useless. Or a "leet speak" version of the same password they use everywhere which actually results in the password becoming somewhat predictable.

This is especially true because if someone's usual password is Password1 they will have to do something predictable in order to help them remember it.

Ultimately it leads to passwords which are difficult to remember, but ultimately easy for computers to crack.

It's similar to enforcing routine password changes. Someone starts with Password1. What's their next password going to be? Password2 probably. Or Password10 because it's October now... Again all too predictable.

What we (as site admins) should be doing is encouraging the use of password managers which will generally force a unique password for every site (and doesn't need to be remembered, because the password manager remembers it for you) or use of long, easy to remember pass phrases.

Here's a perfect illustration of what I'm talking about:

correcthorsebatterystaple would not be allowed under most common password "complexity" requirements, yet it actually is sufficiently complex to ensure it can't be guessed very easily.

 

[king8084]

No plans as yet.

Such password criteria, in terms of enforcing certain types of characters, is somewhat redundant.

For example, it would just encourage people to use something like Pa55word! which is essentially useless. Or a "leet speak" version of the same password they use everywhere which actually results in the password becoming somewhat predictable.

This is especially true because if someone's usual password is Password1 they will have to do something predictable in order to help them remember it.

Ultimately it leads to passwords which are difficult to remember, but ultimately easy for computers to crack.

It's similar to enforcing routine password changes. Someone starts with Password1. What's their next password going to be? Password2 probably. Or Password10 because it's October now... Again all too predictable.

What we (as site admins) should be doing is encouraging the use of password managers which will generally force a unique password for every site (and doesn't need to be remembered, because the password manager remembers it for you) or use of long, easy to remember pass phrases.

Here's a perfect illustration of what I'm talking about:

correcthorsebatterystaple would not be allowed under most common password "complexity" requirements, yet it actually is sufficiently complex to ensure it can't be guessed very easily.

i agree but if only admins know what the criteria is, it wont be hackable, if only the admin knows the criteria is 2 numbers, 2 big letters, 1 special character for example...its much better than current situation

your post is informative tho

 

[Arty]

i agree but if only admins know what the criteria is, it wont be hackable, if only the admin knows the criteria is 2 numbers, 2 big letters, 1 special character for example...its much better than current situation

That's illogical. Only admins knowing criteria is not possible. Users will not be able to register if they don't know criteria, therefore users will have to know criteria, so its not a secret.

I really hate websites that have password requirements. Instead of using my own algorithm to create website specific password that I remember without writing down, I have to create something different. Remembering yet another password with stupid requirements is not possible because there are many websites, so password must be written down somewhere.

Or do you want to generate password yourself and send it to users? That's even worse - no chance to remember random gibberish, so it will be written down somewhere in plain text.

Password criteria is really really really bad security. All websites that use it should burn in web development hell.

 

[king8084]

That's illogical. Only admins knowing criteria is not possible. Users will not be able to register if they don't know criteria, therefore users will have to know criteria, so its not a secret.

I really hate websites that have password requirements. Instead of using my own algorithm to create website specific password that I remember without writing down, I have to create something different. Remembering yet another password with stupid requirements is not possible because there are many websites, so password must be written down somewhere.

Or do you want to generate password yourself and send it to users? That's even worse - no chance to remember random gibberish, so it will be written down somewhere in plain text.

Password criteria is really really really bad security. All websites that use it should burn in web development hell.

i will not enforce anything on the users, i want to apply this only to admins/mods usergroups