Jump to content

Mark

Clients
  • Posts

    36,205
  • Joined

  • Last visited

  • Days Won

    113

 Content Type 

Profiles

Downloads

IPS4 Providers

Release Notes

IPS4 Guides

IPS4 Developer Documentation

Invision Community Blog

Forums

Store

Entry Comments posted by Mark

  1. Wouldn't it make more sense if the system was working based off calls to the spam service from one single DOMAIN instead of one single IP? That would easily solve the dynamic IP issues... Instead of unnecessarily charging an extra100$ for it...

     

    You can't detect from a HTTP request which domain it originates from. That's not how TCP/IP works.

  2. Can someone explain how this could be accomplished in the new system

     

    I have a custom bbcode that goes to a php file that stores an array and looks up some data based on the option/content passed in.

     

    So using the option and content I get 4 or 5 pieces of data and then return something like:

    <a href="DATA1" class="popup" data-more="DATA2" data-stillmore="DATA3">CONTENT OPTION DATA4</a>

    then I have a prototypejs or jQuery function watching which adds the ability to hover over the link and show the data.

     

    Is something like this possible in the new system?

     

    The simplest way would be to make a CKEditor plugin that makes an AJAX request to that PHP file :)

  3. All the blogs never spoken about copy and pasteing from something like Word. Current when I post something from work it looks good in the pasteing part but then after it post the data it look totally different from what it was.

     

    It works.

     

     

     

    I love you LOL

     

    We love you too :wub:

     

     

    With the new editor and all the plugin capabilities, is it possible for a developer (not me) to create functionality similar to word commenting (right boxes with comments tagging specific part of text)? thanks

     

    Yes.

  4. I am guessing that part 4 will answer this.  All I need to know is that you will be able to create Tables through the editor in forum, blog and content areas. Please tell me that will be possible without have to do super duper special HTML stuff that will break if you switch back to the editor :smile:

     

     

    Yes. There is a CKEditor plugin for tables - you can add it just like I added the "symbol" plugin in the example :)

     

    So, does that mean items that are available in the default installation of CKEditor can be turned on? (Tables, horizontal rules, for example)

     

     

    We won't ship with them, but yes, you can download them from CKEditor and drop them in :)

     

     

     

     

    Okay, so from my understanding:

     

    1.  bbcode is essentially going to be reduced to a programmer-only plugin deal

    2.  bbcode html CANNOT be updated for all posts if you need to make changes to the bbcode html.. that is if you update the plugin it will only impact NEW posts

    3.  If you use bbcode you cannot edit the posts unless all the embedded html is whitelisted

    4.  If you use this editor for an article in IP.Content or a blog and include bbcode.. you better nail it on the first try

     

    My money is that you are going to upset a number of existing clients with this..  Is the editor pluggable at least?  I know you are clearly proud of your CKEditor adaptation but this solution doesn't work.   In fact, it's worse than the current editor (not entirely, but at least for bbcode).

     

    I just hope that I'm mistaken here.

     

    You're mistaken. If you could give an example of what scenario you're thinking of (if you have a custom BBCode that is required for your community, let me know what it does) I'll try to explain better how that scenario will work in 4.0 :)

  5. Well, I have two things to say in regards to spoilers, the latter of which I'm guessing you didn't consider based on the screenshot and the former of which I guess I have to "wait and see" but might as well say it anyway.

     

    In many communities spoiler tags are used as a means of collapsing content. In the blog entry it says you will click the box and the box will fade away revealing the text underneath. This implies that the box is going to be the size of the content that it's supposed to be hiding. I do have my doubts that that's true, but in case it is I just want to put it out there that that's not what people will be wanting to see. I'm expecting that it will just be a 10px box or something...and I hope there's some way to tell apart the spoilered content from unspoilered content after clicking the box.

     

    The other thing is that it's helpful to be able to describe what the spoiler is. Would be great if the spoiler button instead opened a popup with a content box for the spoiler and another box for a description. Then the box will have the description which will fade away with the box once its clicked. This feature has been requested before and it's something that communities converting from vbulletin expect to see.

     

    Sorry I should have been clearer, it is indeed collapsed - the black box is always a set height.

  6. Looks good. Especially as it will auto fall back to legacy methods (ie flash etc) if it cannot use HTML5. :smile:

     

    Can't wait to test it. Pity I can't grab that IPS4.zip from your video :turned: j/k

     

    The editor looks a bit odd seeing its toolbar in mono though (I realise this is the ACP and its probably not been skinned so not a concern really.

     

     

    Yeah, it'll look more appropriate when you see what everything else looks like :)

     

    I'm more concerned that I've never heard of Google Gears :tongue:

     

    It was Google's attempt to make stuff on the web work well before Google Chrome and has been discontinued, but the library we're using for uploads still supports it, just in case you have it installed, because it still works of course.

  7. ._.

     

    I expected much much more praise then this... where are all those people hating on the lack of emoteicon organization in 3.x?

     

    I'm impressed(and a tear may have been shed). Love the emoteicon improvements, love the fact you're using CSS3 for quote. Loved the... well... whole blog.

     

    One question though... I noticed the absence of a 'source mode' button... it's coming.... right?

     

    Thanks! :wub:

     

    Part 4 will cover special features like source mode :)

  8. I bet that the upload procedure of the emoticons on the first video (drag n drop), will be a part of the new way we could upload attachments :-)

     

    ;)

     

     

     

    veryyyy good

     

    Something about security? More security?

     

    We're using HTMLPurifier on the back-end to clean the submitted code which has proven reliable and will continue to do so.

     

     

    Awesome!

    It might be a tad bit helpful on my anxiety (and maybe others' too) if at least the titles of what each update on the editor would be called, so we know whether to voice concerns or wait. I know my heart won't be so heavy once I hear more about skinning the editor (that is...if there is any good news about skinning the editor).

     

    • Content
    • Uploads
    • Customisation and BBCode
    • Special features

    Skinning comes under customisation.

     

    To give you a quick answer though: it's just CSS ;)

  9. I would ask IPS to consider using this simplified editor format/display even for quick reply in the forums.  By doing so, most people can instantly see that there are features which to this day are hidden under the description of 'More Reply Options' which to me, the simple end user, is not at all clear.

     

    Yeah, there'll be no more "More Reply Options" button.

  10. I think the term feature rich is a bit over used these days, my eyes start glazing over when I read the term being used in the first sentence. It's an editor!

     

    I will be content if this one works correctly. Sick of copying and pasting stuff in to the editor and then posting only to find the formatting and line breaks are all broken. Not truly "what you see is what you get"...

     

    Ted.

     

    You will be content :)


  11. I noticed that the 'search' feature is available there too.  Nice indeed for those sites that have a lot of areas to make use of.  Also allowing the user to do multiple values.  Could be useful for something like AIM/Yahoo if it allows the user to "Add another" entry of that type.  Only thing I don't get is whether or not they can edit via the UCP.  Does that mean they can edit it in the profile page directly?

     

    Don't suppose there will be a way to handle formatting for profile viewing?  I see the ability to configure how it appears next to a members content, but I'm guessing that's outside of the profile view.

     

     

    The options field only shows because it's a select box. For text fields like AIM, that won't show.

    The other options are the same as they are in 3.x, the wording my have changed slightly though. The blog entry was really more about trees in general than profile fields, which are pretty much unchanged (so far).

  12. Looking good but I have a question: is there any way to display more than a title and the buttons for the row? For example I'd like to add a column with a on/off image to enable/disable the field without clicking edit and changing the value from the form. A shortcut basically, but it could be anything else.

     

    Enable/disable toggles are also supported, though I didn't show them in this example.

  13. Will these 'types' be extensible like the extensions(as in could I as the developer add a base 'template' for a section file to reduce rehashing it time and again)?

     

    Not presently but that's not set in stone at all. Once you get your hands on 4.0, I'd be really interested to hear about anything you think could make development easier.

     

     


    Hook settings? Where do we display configurations for hooks? Manually? Where are these displayed and how if no central settings panel exists?

    If I get this right, we have more control for apps but require more code for hooks? Not to mention without any standard for getting to settings globally, you know as well as I do configuration for the user becomes a nightmare as developers litter the landscape with their own settings display for x mod at x url. This is seriously NOT going to be easy on the user, you went from some fair consistency to completely free-form url and display-wise. Every app/hook is going to now have a learning curve for finding 'settings'?

    You went from an effortless thing to do settings to mancode to display them? Not being accusatory, just not understanding why you add more boilerplate here in something currently so dead simple to implement. I really don't want to end up with it being like WordPress, where you have to code the settings display before you can even use them. It adds much bulk to the code-base. Where hooks are concerned, this single item, needing a setting, is a kiss of death for it staying a hook with it like this.

    The way you present it, why should I as the developer even bother with 'settings'? Why not use rows from my own table/cache? Functionally, it is now the same amount of code?

    Worse, it takes MORE code for an app to display it's 'settings' page? This was a 6-liner. Again, why would the dev even bother with 'settings' at all if we have to manually display and save them?

     

     

    Trust me, it's so much better :smile: This way you can have upload fields, fields which show/hide in dependance on other settings, custom validation and so much more. You do have to type out the code, but the code for one setting is one line (literally one line, it's definitely not the same amount of code as having your own table by a long shot) - it's much quicker to type it out than it is currently to add a setting, put them in the right order and export. Especially when you start thinking about how difficult it is to delete a setting now - you'll quickly realise the new way is so much faster. After all, we wouldn't make a development change which made our lives more difficult ;)

     

    We'll post a separate blog entry about hooks specifically soon, but I assure you it's much easier to find settings in the new layout - in fact, one of the reasons that prompted this change is we kept hearing about people who installed a hook and then complained it didn't work because they hadn't realised the hook has an on/off setting. Just wait until you see it :smile:

     

     

    So you now have the ability to edit and change around the ACP menu, what about the frontend? Is it possible to change that from the core instead of a module?

     
    We'll have more details about the front-end soon :)
  14. What about the only point OF ajax modules?

    I do not want the user 'active' somewhere they are not just because these were removed?

     

    The session class won't update the location on an AJAX call. As I say, you can detect if a request is AJAX using IPSRequest::i()->isAjax() (which examine's the HTTP Request headers) - it's quite handy ;)

     

    Wait....

    All of this will still be able to be done manually outside the ACP.... right?

     

    Yes of course. Though why one would would be a mystery to me :p

×
×
  • Create New...