• Content count

  • Joined

  • Last visited

  1. Still no "Only search in titles" option

    I can give an example from ten seconds ago on this forum. The word "constants.php" appears in about ten zillion discussion topics. I am only interested in discussions that are specifically about constants.php, not just places where it is mentioned incidentally, even if it's mentioned incidentally a lot! A search by topic title is like saying "I want topics about this specific thing", as opposed to "I want topics where this thing came up from time to time".Our forum is about food, so another example that comes up a lot is ingredients. If I do a search for "king arthur flour" and let it search topic text, I get a bazillion hits where KAF gets mentioned, often repeatedly, but aren't actually about the flour, it's just in an ingredient list. If I do a title-only search I get topics that are entirely devoted to a discussion of that specific flour brand.Now, maybe the new search engine has some crazy voodoo under the hood and the titles are weighted heavily, etc. But at least in the case of my search here for constants.php I came up empty-handed.
  2. 4.0: Quick Translating

    Fantastic idea, this will make customization *so* much faster.
  3. Resize images using the editor

    I don't think that has to be mutually exclusive: the forums can continue to auto-resize large images, and members can make the images smaller than that if they want to. I know it's hard to understand the utility for this, since basically by construction everyone at the Invision forums is tech-savy, but I have a LOT of members who are not, and have no idea how to resize their images using an image editor. The same is true (probably even MORE so) for rotate and crop.
  4. Resize images using the editor

    ...some might refer to it as the "easy, convenient" route instead. I'd love to see resize, crop, and rotate (in 90° increments) as core features in the editor, though presumably this is something CKEditor would handle, rather than Invision. I think they already have rudimentary support for resize, so perhaps this is already on their radar.
  5. IPB, BBCode, and concerns about it's future

    Because if you left it unlocked you would gain all sorts of benefits? OK, OK, the analogy breaks down here :smile: . Enabling HTML posting would have resolved the original poster's issue, I think, allowing CKEditor to do its thing and properly format the pasted content, right?
  6. IPB, BBCode, and concerns about it's future

    I believe this is true as well, but Invision continues to recommend only enabling HTML for "trusted" groups (which basically means mods and admins).
  7. IPB, BBCode, and concerns about it's future

    Absolutely true: my suggestion is that Invision basically make a "clean break" with the past by retaining their old parsing method for old posts (so nothing breaks) but adds a flag to each post in the DB indicating which method to use. Admins who were dependent on custom BBCodes and wanted to continue using them could keep using the legacy editor, but those who didn't need them going forward could switch to a clean, full-featured version of CKEditor without breaking anything already in the database. I'm not familiar enough with CKEditor's backend to know what sort of alternative we could provide for custom BBCodes, but I think ideally just allowing admins to create new buttons in the toolbar that executed whatever JS they wanted (pop up a dialog with some option boxes, etc.) and returned an HTML string as a result would do the trick, right?
  8. IPB, BBCode, and concerns about it's future

    This is an interesting discussion to read, in part due to the particular types of forums which are having problems. On a board for tech-savy users, being able to post in raw BBCode, or raw HTML, can be a useful thing. This has historically certainly been true of the HTML option, since there are things that you simply cannot do in Invision's BBCode implementation (tables, for example). If you wanted a table you HAD to enable ALL HTML for that member group, and expose yourself to all the potential problems that entails. On a non-tech board like mine, however, I'd love an alternate solution: ONLY the RTE, with no ability to edit the raw code at all, but full support for any of the HTML the editor can deal with. This would mean that my members couldn't insert arbitrary Javascript, or forget to close a tag, since they'd never see anything but a normal WYSIWYG word processor. There would be no way for a bad post to mess up the formatting of the page, or for it to inject malicious JS, etc. Pasting formatted text into the editor would "just work" (at least, the same way it "just works" in MS Word, or in a Huddler board: maybe not 100% perfect, but a far cry better than what we've got now). This is analogous to using MS Word to create a document instead of LaTeX: yes, you have no direct access to the formatting, but it's a LOT easier for non-tech members to use, and it would just let CKEditor do what it is good at. I guess under the hood what you'd need is something like a "legacy" field attached to each post, and an option on the ACP to disable raw editing (which would automatically enable HTML). The legacy field indicates to the board which method to use when rendering a post: posts made before the switch have it set to true and use the current scheme, and new posts have legacy=false and just display the post however CKEditor has stored it.
  9. Why is posting an image a 3-step process?

    I think that part of the dissension in this topic is because of the differing audiences of our various forums: some of us run forums with tech-savy members who have no trouble understanding why clicking the "attach image" button doesn't put the image into the post, while others have members who expect the button to behave like the "Insert Image" button in MS Word and its ilk and get frustrated when it doesn't. This difference is why any single solution is problematic for some subset of forums. Personally, the less my members have to worry about the fact that they are working "in the cloud" the better: I'd like to see an editor that more-or-less mimics the standard word processor as much as possible: when they click the 'Insert Image' button I'd prefer that it upload the image, attach it, and insert it into the post at the cursor location, all in one fell swoop. This does mean a change in workflow though, for those who (like Aiwa) prefer to think of it in terms of the two-step "Upload, then Insert" mentality of the current system; if your connection is slow I can definitely see how that would be annoying.
  10. Suggestion: Better Tagging

    I agree that better support for editing tags would be great: in the meantime, however, check out We use both of them on our site and it makes the process of managing tags much less painful.
  11. Feedback on Mobile Solutions

    We went with Tapatalk at the request of several members who wanted to post images from their devices. Someday we'll be able to do that on iDevices from a normal website, but until we can, I think that an app is the only viable solution for posting. We've also got the mobile skin enabled, but not auto-selected (since I got too many complaints). I don't have any idea if anyone actually turns it on.
  12. I love that Invision has added such simple Mandrill integration to their suite. One suggestion I have is to extend the use of tags to the built-in non-bulk e-mailing when using Mandrill for all mails. I'd love to have a "Registration", "Password change", "Digest", "Notification", etc. set of tags automatically added. Maybe use the custom SMTP "X-MC-Tags" header and just add them to all outgoing mails without worrying about whether you're using Mandrill or not? Also, it would be great if we had a simple way to temporarily disable ALL e-mails to an outdated address (something that is bouncing in Mandrill) and ask that user to update their address next time they log into the board. This would help with Mandrill reputation issues, allowing us to catch the problem on the first send, and then not keep getting rejected on every subsequent send.
  13. In the ACP, when to set up a custom profile field, make sure to fill in the "Topic View Format?" field. Also ensure that you are allowing the board to run that query (I think that's in the optimization settings).
  14. Mobile Apps Status

    I applaud this decision: it takes guts to stand up and announce that something you tried didn't work, even though the reality is that it happens all the time in software development.