Jump to content



  • Posts

  • Joined

  • Last visited

  • Days Won


 Content Type 



IPS4 Providers

Release Notes

IPS4 Guides

IPS4 Developer Documentation

Invision Community Blog



Everything posted by Tinytimrob

  1. +1. Best option would be to make this a config setting. ​I didn't even realize that was a feature. It isn't particularly obvious. Does this work in reverse if the "paste plain text by default" is enabled?
  2. ​Thank you very kindly for the plugin Mark! It is good as a workaround, and definitely better than having to edit DateTime.php on every IPS4 update, which would be a huge pain. I wasn't expecting to just be handed a free plugin so I appreciate it! I just tried it out and it works great I didn't realize the plugin system in IPS4 was so flexible in allowing these kinds of modifications. I had a peek at the developer documentation and it seems quite easy to make these sorts of plugins so this inspires me to try writing some myself Sadly it still seems to me like a step backwards when we have to resort to making or scrounging plugins to re-implement IPB 3.x features that have been removed I think separating locale from language is a great idea and definitely one that should be implemented in 4.1, as it would solve problems like the one I described here; we would only need one language pack for English and everyone would see their preferred date format, etc. On the topic of separation in a future version (and this is outside of the context of my own site): While I really don't see anyone running a small-to-moderate size English community going to the effort of maintaining multiple slightly different English language packs, it technically could happen. In that case, I think it's important to have some sort of "best language, best locale" system, especially for visitors. For example, if a guest comes from Canada, and only US and UK language packs are installed, they might see the UK language pack by default (because the spelling matches better) but the Canadian locale settings, whereas if someone from the US arrives, they should see US language and locale. Maybe this could be configured in the language pack or in some settings screen where we can set the preferred language pack for each locale? It would be pretty cool to be able to say "the default language for all locales is English USA. override the default language for UK, Canada, Australia, etc and set it to English UK instead. override the default language for all spanish locales, set to Spanish instead", etc. Back on the topic of customization of date formats: What about in this circumstance... I understand that a 'global' date-time format configuration setting (like the one in IPB 3 that I was complaining about being removed) doesn't really make sense once you consider such wider internationalization support, as you would then be overriding specific region settings with ones that would potentially be worse, breaking one locale to fix another. In the instance above, only the Norwegian locale might have 'errors' so the changes would only be needed for that specific locale. So rather than removing the customization option altogether, maybe you could make the date-time formats customizable on a "per-locale" basis (or for now at least, a "per-language-pack" basis)? It would be nice to be able to make corrections to the default formatting for a specific locale/language in the event they don't match preference. (e.g. if i had English and French language packs installed but the French locale is wrong on my system, I could set a custom date format JUST for France) I suppose a plugin could be made for that system, because maybe it's outside of the scope of the IPS suite to have that much control over what is effectively a system configuration setting. That sort of plugin is also not needed for my case, since the global setting works fine for me. Just throwing some ideas around
  3. ​But there are no language choices to pick from, other than English USA, without installing an English UK language pack. I don't want to do this for various reasons. Still, if other countries have minor differences like this, then in the end, I have to have slight variants of the English language pack for every single country, and maintain them all !!! ​I get this, but ​US and UK format currency identically. The only difference is the actual currency type itself, which, when you are selling things, is configurable in the Commerce app (I set it to GBP and everyone sees prices in GBP) and thus not affected by locale setting, at least nowhere relevant or in regular display across the site. ​Incorrect spelling is not ambiguous, but incorrect date format is. If I put "aluminum" or "aluminium" in my discussion thread, you instantly understand what I mean, regardless of what variant of English you speak. The spelling is a non-issue here, since we are having international discussions in the forums anyway, and people spell differently; this is something you expect on a forum, especially one that tries to be locale-neutral. On the other hand, with incorrect date formatting - if I put "04/05/2015" - what is the date? Is it 4th May? 5th April? WHO KNOWS! You have absolutely no idea! This is why I want to change to "04 May 2015", because this is locale-neutral, or at least a lot more locale-neutral than 04/05/2015 vs 05/04/2015. Everyone understands the date immediately regardless of locale if the format is DD MMM YYYY. Which, again, are exactly the same for US and UK as far as I know. ​No it doesn't. If I have separate language packs, I have to maintain them all. This is a lot of extra administrative work. ​^ This ​No - if a UK language pack isn't installed, everyone sees the US format regardless of where they are (at least from my observation). As an experiment I tried changing the locale of the English language set (because only one is really needed) to "English UK" to see how long it would take before the grumbling began. Lo and behold... Having two English language packs isn't an option really for us. I wouldn't mind editing DateTime.php, but we used to have this option before... I'm complaining because we need it and you removed it I'm currently paying for this software because it's the best. Version 4 is supposed to be an improvement over version 3, but at the moment I'm concerned because a lot of useful customization options have not been re-implemented, which is making it look like a much less functional suite. This is not the only removed feature that is annoyingly removed, but this issue causes the biggest annoyance for my site and its users. The whole problem can be fixed by just adding one config setting - short date format - back in, and setting it to %x by default, meaning no default behaviour change at all as a result. And if you want, you can even make this a "customizable per locale" setting, to maintain your "locale friendly" design.
  4. I filed a bug about this before, but it was closed, since it is working as intended, so I figured I could try to make my case in a topic instead (because I think the intended behaviour is silly) On my board I have both British and American members. The balance is probably around 50/50. Currently in IPS4 the date format is fixed to be "%x" and the locale can then be adjusted in the language pack. Because "%x" date format prints DD/MM/YYYY or MM/DD/YYYY depending on locale, if I want to please both the British and American members, I have to have 2 language packs installed (because the British will hate MM/DD/YYYY and Americans will hate DD/MM/YYYY) I would rather not have two almost identical language packs installed just to set the date format, as that seems counter intuitive. I also would like to point out that if I created "English UK" language pack to fix the date formats, but then there were incorrect spellings (e.g. 'color'), then in order to make my website not be 'lying' to users by claiming to be UK language when it isn't, I would have to go and check every language string on the entire pack to make sure it was correctly localized. This seems like a huge amount of effort to me. (I suppose I could make "English US with UK dates" as a language, but to users that would seem like a really silly option) Really I just want one single "English" language pack that works for everyone. If the spellings are slightly off it's no big deal, everyone knows what it means. But if the date formats are backwards, it's ambiguous, people might not be sure what 04/05/2015 is, for example. And again, some regular users will get annoyed. So my preferred date format would be "%d %b %Y" (prints as DD MMM YYYY, e.g. 15 Jan 2015) because this isn't ambiguous, it solves the confusion and then only 1 language pack is needed. Everyone would be able to identify the date without needing 2 packs installed or having to teach people how to switch between them. Maybe it wouldn't be the preferable option for some people to see DD MM YYYY format, but at least it would not be ambiguous like a date such as "04/05/2015" is. I could previously edit the short date format to accommodate this change (very easy, just 1 setting to change in Admin CP), but unfortunately this setting was removed from IPS4. As a temporary workaround, on my test board, I edited DateTime.php and replaced %x with %d %b %Y, so now all the dates are how I want them. It looks great, with immediate and non-ambiguous understanding of dates by members of all English speaking countries, and no complaints! But that's not really the best thing to do. I am not sure why I have to edit the code to make this adjustment, when previously it was editable in the Admin CP. As it is, now every time there is IPS4 update, I have to check to see if DateTime.php is edited, and if it is, I have to repatch it. What a huge annoyance! It is really sad that these sort of features are removed from IPS4 which are important to some communities such as mine, especially one like this which allows me to make the board more "international friendly" (something which is important to me as I have a lot of users from across the pond) Maybe this isn't an important feature for most people, but I fail to see the issue with implementing an editable setting. Set it to "%x" by default, and hell, even hide it away in constants.php if you like, so the setting isn't visible to most users. But please, don't leave out this setting! It would really be a tiny amount of work to add it. And as long as the default was %x, it would continue to be changing with locale by default, which hopefully would satisfy most users. Thanks for your time
  5. I'm glad that work is finally being done on improving this area of IP.Board.
  6. On my forum, some of my members want the choice to sync their Photo, About Me, status updates, etc with Facebook. In order to allow this I must turn on Facebook Connect. However, I need people to be able to log in to their account outside of my website, in areas where Facebook Connect isn't an option for logging in (for example, they must be able to log in to a game I've written in C++, that runs on the user's computer, and uses a daemon on my web server to provide log-in access by checking user input of e-mail and password directly against the ibf_members table of my database). Because the Facebook Connect is an all-or-nothing scenario, the problem that users can then register via Facebook and then be unable to access the parts of my site/service that can't use FB Connect. Hence why I want them to be able to set a password for their forum account when logging in with Facebook. I also want people coming from Facebook to have to agree to my board's registration terms and conditions before the account can be made!
  7. Thanks, but as stated in my report, your bug isn't the same as mine. I also just discovered that on a fresh install of IP.Board 3.1.4, the Facebook Connect does in fact allow users to attach Facebook to an existing account, and does copy the e-mail address from their Facebook account to the forum now (it didn't before). This wasn't working on my board, but after disabling and re-enabling Facebook Connect it seems to have fixed. HOWEVER this doesn't excuse the fact that accepting the TOS isn't required for Facebook sign-ups, nor does it alter the fact that no account password is ever set. I know you can set one from the control panel, it's just inconvenient for members who don't understand the system, who then have to have it all explained to them.
  8. I have just discovered that, by setting the "internal login handler" to use "E-mail address" in IPB 3.1.4, that the login name option is removed from the registration form, and users log in using their e-mail address. In the event of this, the "name" field in the DB is populated with the display name. HOWEVER when a user changes their display name, the regular "name" field of the DB is then not updated, which prevents a new user from registering using that old display name. I'm assuming this is a bug so I'll report it in the tracker. I feel my other suggestions are still useful so hopefully either some work will be done on this or some mods/hooks created further down the line.
  9. I have a few ideas on improving account handling, registration, and Facebook/Twitter connect logins in IP.Board 3.2. If you could make these changes it would be really really really really useful, and would save hours of modding to fix things that shouldn't really need fixing. It all seems very obvious to me... I don't get why these things haven't already been done, especially considering the retail price of IP.Board and the fact it's used by some big organisations. - I want to be rid of login-names as they cause too much confusion with my members, due to being different from display-names. Members should really log in using their e-mail address, eliminating the need for this pointless login-name field. I know this won't be popular with EVERY admin, so here's my solution to that: --- It would be nice if a setting could be added so that users do not need to fill in a log in name when they register, and instead have the login-name DB field automatically populated with the e-mail address. Extending this, upon changing an e-mail address, the login-name database field should also automatically be populated with the new e-mail. This could potentially be extended further, with the ability to create a hook where the site can immediately connect to the other SQL user databases used for my ring of sites, and update the login fields in those SQL databases too. - Facebook Connect is poorly designed. I've had members not realise how it works, and then sign in via their not-linked-up Facebook account, only to find they now have 2 accounts. This is a rubbish design, especially since having multiple accounts is currently a TOS violation on my site, and mods end up warning the inexperienced users who don't fully understand the way IP.Board is treating Facebook connections. I can really see this being a much bigger problem on a larger site which imposes such a rule. I would prefer that when a user logs in with a Facebook account that isn't linked up, they are shown a screen which reads "This Facebook account isn't associated with a ForumNameHere account. Do you want to register a new forum account, or would you like to link this Facebook account to an existing forum account?". If they then have to register a new forum account, the system should force them to input their display-name, e-mail, password, etc, so that they will 100% definitely be able to log in WITHOUT Facebook from that point onwards, without requiring any extra effort on anyone's part. (This is necessary for my forum, for which I'm currently writing a server daemon that reads from my user DB directly to provide access to forum accounts within games and networking applications - but my users want Facebook integration on the main forum too, and from what I understand, Facebook Connect rules state (or did state at one point) that in order for a site to make use of Facebook features, you must be able to log in and create new accounts using Facebook... that's fine, as long as they can also log in normally in my other non-IPB applications that read from my IPB member table!). The same thing applies to any other Connect, OpenID, or other such log-in option. In the event that they do not choose either option (completing registration or attaching FB to their account), nothing should happen. No incomplete accounts need to be made, as they just get deleted by the admins in the ACP, which wastes time and is inefficient. OH, and users registering via Facebook Connect need to be shown my forum TOS (registration guidelines) too. The fact that they come from Facebook doesn't give them the right to misbehave, and it doesn't give them different rules to everyone else either. I want to enforce compulsory acceptance of the terms for all new users, before they are allowed onto the site as a proper member. - New users who've never been to a forum before don't seem to know much about profile customisation, and the mods of my site keep having to tell the new users all about the different customisation features and how to find/use them, which irritates the mods and wastes their time. To combat this, the user should be easily able to find these customisation settings, and should be prompted to customise their profile as soon as they've completed the registration process. Ideas are as follows: --- There should be a tab on the top of the board which links straight to the Account Management system for the logged in user, which might be called "Account". I'd also like a sort of 'landing page' or 'home screen' for the account manager, which shows a few basic things about the user (e-mail, number of posts, how many posts they need to make to be upgraded to the next user group (along with a graphical bar), the fact they haven't set a photo yet, etc). Hooks (or mods that don't require file editing) should be made available to add more things to this landing page, as needed by the admins of the various sites running IP.Board. --- I would like to write a short description in the ACP about each user group, so that the user has an idea of what things they're able to access on the site. This description could be displayed to the user on the said landing page. --- After clicking the e-mail validation link (or after creating a new account via the Connect function) the user should be immediately redirected to the said landing page, where they will be able to see that they have to make X posts, haven't set a photo, and all that; giving an incentive for the user to personalise their account and profile as soon as they've registered. --- There should be an ACP setting to enable a top-of-page reminder, telling the user in an irritating, in-your-face box that they haven't validated their e-mail yet, or that they still have to make X posts to get to the next user group, set their photo, or whatever, and advising them to visit the account system to fix these things. If you could sort all this out then that would be brilliant! Thanks for your time.
  10. The usability improvements in the new ACP look good so far. Unfortunately I have to side with all of the other anti-pink people here. It completely puts me off. I don't really want to have to edit the ACP every single upgrade to change the pink to some other colour; there are already a large number of edits I have to do on my board for each upgrade as it is. There are clearly a lot of users who don't like the pink so maybe you could try some alternatives? How about a nice green? Or maybe just a lighter shade of blue? Either way, both of those are a lot better than the vile, in-your-face pink that you're currently using. Please change it to something less in-your-face. Please :)
  11. This is a status update.

  • Create New...

Important Information

We use technologies, such as cookies, to customise content and advertising, to provide social media features and to analyse traffic to the site. We also share information about your use of our site with our trusted social media, advertising and analytics partners. See more about cookies and our Privacy Policy