Developers, is Dolphin U awesome? - part 3

Well by the sounds of a lot of dolphins here.... just one version is to much. Personally i think D7.1.4 is very stable and is good. So before i have tooooooo much criticism i'll wait until i have seen a working Du.

Keep in mind that ... internet usage -  changes a lot in the last 2-3 years. 

mobile traffic - social signups and total domination of facebook changes everything. 

so i absolutely agree with a overhauled system like dolphin U. 

cant wait to see.

I think the key question is "Can Boonex & the Developers support both products?" If they are two completely separate products it isn't easy to focus on the development or problems in hand. Yes as someone pointed out in this thread two products isn't a lot to offer but generally you would have two separate teams working on each product so focus can be maintained on the respective products.

I think it won't be long before Developers soon realize they cannot support both Classic & U & will need to make a choice between the two. Can Boonex maintain the two as separate entities? All this work being done on U now for instance, would I be right in saying nobody is working on Classic right now? If not, that could mean no further action on Classic for up to 12 months, maybe longer by the time initial problems with U are ironed out. It's okay saying the two will be separately maintained products but just how practical is that?

hi..will dolphin U comes with file manager for tiny mce ??

For any unannounced features, you'll need to wait and see. Sorry.

is  it going to be adjusted with bidi language (RTL) ?

any progress...its like it taking forever..

Yep, progressing nicely. Developers bring in a lot of feedback and we're working on it. Some people started making test modules as well. More details soon.

Maybe Boonex can use the free  TinyMCE Images Upload  from http://justboil.me/ or http://www.responsivefilemanager.com/index.php

 RE:

 I'd prefer Moxiemanager, but would settle for RFM.  Client side image resizing for photo uploads would be another ++

I doubt if Andrew is going to spring to include Moxiemanager when it is stated that developers may have to pay to get the privilege of having their module tested for Dolphin U.

RFM licensing may mean that Boonex could not include it:

Responsive FileManager is licensed under a Creative Commons Attribution-NonCommercial 3.0 Unported License.

You are free to use Responsive Filemanager for your personal or non-profit website projects.
You can get the author's permission to use Responsive Filemanager for commercial websites by making a free donation on below paypal button

Boonex has no way of controlling how Dolphin is used, or knowing ahead of time before the creation of any site.  In this case, Boonex could include an integration of RFM without including the file manager leaving it to the individuals to obtain RFM and to make sure they are properly using the file manager under the RFM licensing.

 RE:

 Things like that are always negotiable, but Moxiemanager would be the easiest in terms of licensing. 

Every time this issue is raised with Boonex, they take the position that they'd rather create their own product, and that would be fine if they'd just do it.

Devil is in details...

It's not an issue of paying for the Moxiecode license or fiddling with any other 3rd-party manager. The problem is that none of them actually suit the variety of file management scenarios on Dolphin U without modification. And, as you know, modifying 3rd party software always leads to upgrade nightmare in the future.

For example, things like mobile-friendly interface, high-resolution photos support, integration with Dolphin's language files (Moxie is using their own languages), integration of configuration interface into Studio, etc, etc. 

Integrations are always super-tempting. It costs us x100 times more to develop our own components than integrate 3rd-party ones with "Enterprise" licenses. In long term, however, they present a massive drag on support, updates, installation, configuration, documentation, testing and fixing processes. So, every time we think about some shiny new forum, messenger or file-manager we could integrate we remember all those not-so-little hurdles and realise that whatever we need, we should recreate ourselves.

On the other hand, this may be a great thing for someone (even ourselves) to work on as an alternative module, that integrates with some of the software components (say, TinyMce, but not all other upload interfaces) and clearly refers to Moxiecode as a source of documentation, bug-tracking, configuration, etc. 

 RE:

 You're over-analyzing this.  A lot of people want on-the-fly image upload when creating TinyMCE posts.  Since TinyMCE already uses its own language system, a plugin like moximanager doesn't really complicate things any further than they already are.

File management is a non-issue.  We're talking about inserting images into TinyMCE posts.... not uploading photos to albums.  No one here cares if images placed within TinyMCE are managed or stored like normal photo album images... that would be dumb, pointless, useless, a waste of time, so don't even think about it.

I expect Moxiemanager is no different than the previous product, ImageManager, in that is can be integrated with only a few lines of code.  Moxiemanager makes it really easy... trust me on this one.

Integration goes something like this:

The first time a user inserts/uploads an image with TinyMCE/moxie manager, a sub folder is created on the server that corresponds to the logged in user id, ie /media/moxiemanager/images/1  Then every image that user uploads, is stored in that folder.  You don't need to resize it, hash it, rename it, or any of that..... just create a folder if it doesn't exist for the user, and store the image.  That's it.  Moxie manager will do the rest.  Nothing complicated... no image resizing... no sequential image names, no database file management.... just store them all in a directory structure.

Files can be added the same way in their own folder: /media/moxiemanager/files/1 

Furthermore, moxiemanager works as a standalone, do it does not need tinyMCE.  That means that each user can have a Moxiemanager block on their account page, and upload photos and files for use in any post made with TinyMCE.

There's really no good technical reason to not do this.  Why reinvent the wheel, when you can use someone elses wheel?

 is this mean we are getting one file manager or image manager of some kind ??...btw any file manager will work for me..but i really need one..

I believe that we discussed this before.

We will really try to consider to integrate MoxieManager into TinyMCE for Dolphin 7.x (Dolphin Classic), but it means that we have to considerable increase minimal requirements and maybe other side affects.

Dolphin U already has build-in photos attachment to posts and comments also new Dolphin has different universal files storage system which can make integrating such plugins problematic.

Oh?  I would like to hear more on this.

http://www.boonex.com/n/dolphin-8-storage-objects

 RE:

 For instance??

 RE:

This is a fundamental mistake.  Why should images be attached to a post?  If you use Moxiemanager, images used in posts would be uploaded to a user folder on the server, and just inserted in the tinMCE post via url.  Attachments are something entirely different... attachments are files that are attached to a post and are meant for user download.  The Boonex way seems like a pretty awkward way to add images to a tinyMCE post.

What's wrong with storing media used in TinyMCE posts in its own folder structure?  ie...

    $sMoxiemanagerFiles = BX_DIRECTORY_PATH_ROOT . 'media/images/Moxiemanager/' . $iLoggedId . '/';

    if (! file_exists($sMoxiemanagerFiles)) {
        @mkdir($sMoxiemanagerFiles, 0777);
    }

Then each users TinyMCE media is stored in their own unique sub folder eg. /media/images/Moxiemanager/1

Image in post will be: <img src="/media/images/Moxiemanager/1/someFileName.jpg" />

If all you did was upgrade 7.1.5 to use TinyMCE 4, I'd be happy.  Moxiemanager integration is easy.

HOWEVER.. Dolphin U uploading images as attachments > insert into post is a really clumsy way to do things, and it's going to look really ugly when people want to create a doc with a large number of images.  What.... are we going to have 20 attachments cluttering up the post?   You need to give a lot more thought to the Dolphin U method.

HL is correct on this.

I am guessing this is the same as the attachment in Dolphin 7.1; which I don't like.  Some of my members have used it but to see the image one has to click on the thumb.  Most users like the file manager way that I have integrated in TinyMCE for inserting images directly into their posts.  They can have a full image or float the image to the left or right and have text flow around the image.

There are plenty of open source file managers on the market that are open to being forked and one could be developed for Dolphin with little code work by the Dolphin team.

Images in Dolphin U are not like attachments at all. There are upload buttons for multiple or simple upload which results in images "added" to the posting page, each with an option to include into the post and/or use as the post thumbnail. If none of the options is selected the image stays visible only in Edit mode. This is a basic system, but it does the job and is understandable for most users.

File manager becomes needed when you want to be able to reuse media in different posts or edit it on server. That's fine, but is merely a more  advanced set of functionality, which will be added in time. Perhaps in a from of an extra button along with upload buttons. 

So, my point is that there is nothing that prevents webmasters from integrating Moxiemanager to TinyMCE or useing any other combination of editor and manager. We should, however, make sure that Dolphin U has a native file management system that is completely integrated, doesn't depend on any particular editor and is developed by Boonex, so that we could seamlessly update and support it. 

Give me the copy of Dolphin U , I must start translating everything on my language ...I'm joking but I'm impatient and I can't wait to see new Dolphin. It is hard to read only about this new Boonex product ...

PHP 5.3

 Alex, did you mean to say PHP 5.4?

I believe he meant to say that is now the minimum requirement. I am running a test copy on php 5.3.3 without any issues. I really don't think they can go higher than that as a minimum. To many hosting companies are still running 5.3. It is still the default in many distros. Centos just barely went to php 5.4 in centos 7 release only last month. So it's to early to drop support for php 5.3

OK, I thought Dolphin 7 required 5.3 but going to the HELP and checking I see the current requirements are 5.2.0; so yes, min of 5.3 is an increase.

@AlexT  RE: http://www.boonex.com/trac/dolphin/ticket/3434

Thanks.  For Dolphin 7, it really is a good idea to do this.  It makes the core product more attractive.

 RE:

I'll have to see how things develop within DU. I reserve the right to bitch about this more at a future date.

So if I want to use an entirely different editor in DU, like webodf, it wouldn't be a nightmare to implement?

Something that has been asked for in Dolphin 7 by different users over the years.

http://www.boonex.com/forums/topic/CKEditor.htm#207098

Actually D.U. have another build-in HTML editor, but it will likely be removed before the release.

Yes, 5.2 is still widely used, around %25 of all sites, so we will try to support it as much as possible. 

Any Updates on the Development Progress ?

 there must be some page to see the progress..