I'm sure there's going to be a lot more pain to come as we work on finalising this. But thank you very very much for this in advance!

Please check the language style guide available here https://joomla.github.io/user-interface-text/

You will have to adjust the doc blocks so it fits the ones we have in other places in core. Eg:

/**
 * @package     Joomla.Administrator
 * @subpackage  com_fields
 *
 * @copyright   Copyright (C) 2005 - 2016 Open Source Matters, Inc. All rights reserved.
 * @license     GNU General Public License version 2 or later; see LICENSE.txt
 */

The Mustache library needs to go into the libraries/vendor folder and managed using our composer file.
Mustache is licensed as MIT, which imho is compatible with our GPL. So that should be fine.
However I'm not convinced we need an additonal full template engine just for some custom fields. That's something for PLT to decide I guess. If we're gonna use Mustache for some things in future (eg J4) anyway, then it's fine. Otherwise I think it's gonna add a lot of bloat to the system.

The fotorama librariy is also MIT and should be fine, but its CSS and JS should also be there in uncompressed variants.

Another thing that I saw when looking over the files is that you add a class and a layout file for each supported field type. Couldn't that work from the original formfield classes? Maybe by adding some code there instead?
Don't get me wrong, for a 3rd party extension this is perfect, but for a core extension we could maybe do it simpler (we can after all modify the formfields which 3rd party can't).
I'd love to see all code related to a field in one place instead of having it spread all over the installation.

As for system plugin vs observer, I personally prefer the plugin approach.

IMO this needs to go into a branch on https://github.com/joomla-projects/joomla-cms and worked on from there. This PR is not in a state where it is ready for community testing or project review.

+1 with @mbabker as a single PR of 130+ files it is really hard to comment/review/test as it currently is. If there was a separate feature branch with this merged it would be much more practical - which means it is faster and more efficient

I agree, that it would be more practical to have the field code all in one place. How it is now, it is relatively easy, I can just iterate over the directory and do know that all the fields in there can be used as custom fields. Porting that to the real fields, would mean I have to load all classes and check if they implement a certain interface as not all fields are meant to be used as a custom field.

Would the PR still get the attention that we can bring it into 3.6 if it is moved to the joomla projects repo? I want to avoid the situation that it will get forgotten somewhere in a branch.

As release leader for 3.6, I'll make sure it isn't forgotten. :-)

This looks like something very useful.

I applied the patch on my local machine. First thing was that I had to increase the max-execution time from the standard 30 seconds to 240 seconds before the patch was applied.

When I tried to follow the instructions above, all I got was an error message saying that the component wasn't installed. :-(

@coolman01 You may have to discover-install it after applying the patch.

@coolman01 and push "fix" for database

Did it work the installation?

Couldn't that work from the original formfield classes? Maybe by adding some code there instead?

@Bakual how would you do the lookup then, because not every formfield is meant to be available as custom field? Loading all classes in that folder and checking them if they implement a certain interface?

@Bakual how would you do the lookup then, because not every formfield is meant to be available as custom field? Loading all classes in that folder and checking them if they implement a certain interface?

@laoneo That would be my first thought, yes. But depends on the ratio of available and supported field classes. Maybe instead of iterating over a folder we could also use a plugin even which returns the available fields (and class location). That way it could also be extended with custom fields.
Just writing from top of my head.

Had a discussion yesterday with @dgt41. We both think the interface approach would be enough as looping trough the list is only done when a field is edited in the back end. The the fieldpath of the form can be taken into account as well when more fields should be loaded by a 3rd party component as this is possible already with DPFields now.

my 5 cent

Loading all classes in that folder and checking them if they implement a certain interface?

I think it is a road to nowhere

I more like @Bakual idea to use a plugin event, but instead of return of "known fields" I would like to see something for "register field", like

FormHelper::registerField($name, array(
  'formPatch' => blabla, 
  'classPatch' => blabla, 
  etc ...
))

That can be used during that plugin event.

@Fedik feel free to create a PR against my repo that we can have a look how it would go then. For me the overhead of it is not worth the effort.

It really would be so much easier if this was a branch here

Why would it be easier here? I'm waiting for the permission to create a branch on the repo @mbabker suggested that we can move there.

Thats the branch i was referring to

Don't you have permissions to https://github.com/joomla-projects/custom-fields ? (I assume that's why someone created a whole new repo instead of branching permissions on the CMS repo, don't ask me why...)

As requested, development of the custom fields feature has moved to the repository https://github.com/joomla-projects/custom-fields. Please create there the issues and pull requests to improve com_fields. This PR will be closed and a new one will be opened when it is ready for community testing.

Thanks so far for feedback!

@brianteeman @wilsonge can you please remove the milestone as it is not merged into 3.6?