Add 'subfields' custom field type #22446
Conversation
First commit which integrates the subform custom field type. This is the commit message joomla#2: Rename manifest file for plg_fields_subform This is the commit message joomla#3: plg_fields_subform: Improve code comments and made the subform field type optionally non-repeatable. This is the commit message joomla#4: Fix not being able to change the type of a subfield. This is the commit message joomla#5: Implement a small in-memory renderCache for subform custom fields This is the commit message joomla#6: Prepare to load the subfields into a subform custom field directly via their own xml definition. This is the commit message joomla#7: After merge with PR joomla#17552 we can now successfully show the subforms options for the different types. This is the commit message joomla#8: The subform custom field type doesnt need a default value. This is the commit message joomla#9: Implement an option for a subform customfield to disable rendering the field values. This is the commit message joomla#10: Remove unused code and set hidden fields to not-required. Signed-off-by: Rene Pasing <[email protected]>
continga
force-pushed
the
fields-subform-3.10
branch
2 times, most recently
from
249dab9 to
af81e22
Compare
continga
force-pushed
the
fields-subform-3.10
branch
from
af81e22 to
bcb2601
Compare
| } | ||
| echo '</ul>'; | ||
|
|
||
| /** |
There was a problem hiding this comment.
Should I really remove it? I added this on purpose, including the comment above, to help other developers, especially designers which are creating layout overrides, to create better templates
There was a problem hiding this comment.
The code is not a documentation source. This belongs in the documentation as an example or as an alternate layout, but not as a full blown commented code block.
There was a problem hiding this comment.
True though. By the way, how would the workflow be for creating decent documentation for this feature? Should I create a new page in the docs wiki and link it in this PR?
|
What is the difference to #20243? For me it looks like it has a similar functionality. |
|
Any chance I could convince you guys to rename this? My subform field plugin has been in the JED since Apr 26 2018 and will not be installable when this is merged. |
|
@stutteringp0et The concept of adding a subform goes back much further than this pr see #17552 |
|
I hate to sound like I'm coming across as a jerk here too, but "subform" is what we call it in core and as annoying as it has to be for you it'd be equally as awkward to have a custom fields plugin in core named something completely different to avoid the naming collision with your plugin. |
|
The second guy to cross the finish line doesn't get the first place trophy. They talked about it in #17552, the difference is that I actually did it. core-subform maybe? I worked on mine for a long time too and it's not like I can get the JED to rename my extension, I have to re-submit. My users will probably not want to give up features to use the core version. |
|
Well that's what happens when you work on something for yourself instead of contributing to help everyone benefit - sorry you're not going to get any sympathy from me |
|
56 extensions in the JED, more than 80% of them are free, but I'm not helping anyone. Gotcha |
By this same logic, it could easily be argued that any feature implemented by an extension couldn't be added to core because it will conflict with or completely disable/destroy an existing extension. Yes, it sucks for those who have those extensions and come into those conflicts. No, I don't think it's appropriate to rename a core feature to some other name to deconflict with an extension that used the same name. |
|
I hope you recognize what this attitude does to morale for us lowly 3rd party developers. This isn't the first time, it's the 5th (for me). I have a hard time being enthused about releasing any new extensions in this environment. My comments on issue #11905 were deleted by the Joomla user, so it's not like there wasn't prior knowledge that my extension existed. No sympathy? Yes, that's quite clear. |
|
iirc i deleted the comment because they were an advert for your extension which is not appropriate here (but my memory might be failing) however that was in aug 2018 |
|
Well, I don't have those email notifications anymore, but if the comment was perceived as an advertisement for an extension then it would be rightfully deleted. "Subform" is the form field type in core, therefore a plugin adding support for it to custom fields should carry the same name. We should not have to prefix everything with "core-foo" or "joomla-foo". Again, yes, it totally sucks if you are the person who put out an extension with that exact name. But I don't think it's worthy of us renaming things in core to create even more confusion (if someone's on a site with your "Fields - Subform" plugin and someone updates core to get a new "Fields - Core Subform" plugin, how is that not confusing to users?) or making everything in core follow a |
|
My comment was deleted August 2018, but I made it sometime around March or April in reply to pepperstreet who mentioned me in a comment on 3/30 (I still have the emails). How confusing is it going to be for a user who upgrades Joomla and finds their subforms no longer work because they've been overwritten by a new core field of the same name? That's the kind of support call I'm going to get. I seriously doubt you would ever consider naming a core extension com_comprofiler. Beat is a big fish, and I'm just a small fish. |
|
@HLeithner ITs a new feature so it can only go into 3.10 |
|
Perfectly. As a new feature, it has to ship with the next subversion... being 3.10 But would it be possible to provide this Custom Field as an installable plugin (since Custom Fields are "just" plugins) ? |
|
There is way more done in this PR than just a new plugin. There are many modifications/tweaks done to other core files in order for this to be supported. So it's just not a new installable plugin. However, anybody can download the changed files and overwrite them on their set up, if you need. Or just apply the patch via the patch tester. And if you do, please test and confirm if it works fine for you, more tests are welcomed. |
|
3.10 will not be a feature release and is only for compat to 4.0, in this case please make directly a PR against 4.0 and close this one. |
|
and that is where the plan is fatally flawed. this great new feature will not be seen for a year |
|
That's the decision and you reminded me, thx. |
|
wait, you are saying this now, 4 months after this PR has been opened and several feedback-cycles have been made, and after we finally reached the RTC status? Feels bad, man. I have to say, this really is a bad atmosphere for open source contributions. Why didn't this topic come of earlier? Why isn't everyone aware of this? But this probably shouldn't be discussed in this PR. No hard feelings, how should we now continue with this PR to not lot it rot multiple months? |
|
+1 vote for exception to merge in 3.9.4. Jokes aside, you could easily move plans for the current 3.10 into a 3.11 instead, and allow features like this into an intermediary 3.10. |
|
No offense meant to the work put in here, but this PR alone isn't enough to justify a new feature release and all of the effort that goes into one. Plus, the project's roadmap already looks like a pin-the-tail-on-the-donkey board with how many times it has been said "3.x LTS will be here, 4.0 release will be here" and sooner or later someone needs to either come up with a realistic timeline for both releases or admit the project has bitten off more than it can chew and downscale to do what it can support and accomplish (which, it seems like saying no more 3.x feature releases so effort can focus on shipping 4.0 this decade has started to do because clearly trying to put out "big" feature releases and concurrently work on a new major version isn't working). |
|
So, from Joomla blog post:
So I guess this would need to be retargeted to 4. But what I'm afraid of is that 4 might take even more than a year for a reason or another, so this would have to wait forever. I don't know. This PR alone might not be enough to justify a new release in-between, but I'm sure there are some other cool new features PR as well. Consciously planning to not release any feature at all until Joomla 4 is ready (who knows when) is a scary thought. |
|
these are from milestone Joomla 3.10.0 |
|
and surely some more can be included if got more tests |
Consider the alternative, which is in effect the current status quo. 4.0 development has been ongoing in some form since the middle of 2015 and still hasn't reached a beta milestone. Since the first try at a 4.0 release, everything from 3.5 up has been shipped. That's 5 "big" feature releases concurrent with 4.0 being in development (in all of its incarnations, and every major change in direction that has slowed down the current iteration (i.e. the push for yet another admin redesign over a year after the initial template had been committed)). Clearly, continuing to ship "big" feature releases for 3.x while continuing to develop on 4.0 (which has consistently been 5-6 patch releases behind 3.x's stable releases; right now 3.9 still hasn't merged forward) is not working and there is in essence a split community with people working on one or the other and not that much overlap, and it's now getting to the point where bug fixes are going into 4.0 without consideration of whether those same bugs exist in 3.x. So either feature work needs to slow down massively and/or stop in full on 3.x, or 4.0 needs to be abandoned; the resources aren't there to work on features for both and keep both branches synchronized in a sane manner. |
|
that's true, but we cannot see only 0 or 1, even with low resources, |
|
Which begs the question:
Why did (and does) nobody jump in when efforts on new features for J3 start
(like this one). And say:
"Hey, there is a feature freeze on Joomla 3. If you want to create a new
feature, do it for Joomla 4!
So no need to spend months of your life investing in this for nothing."
…On Mon, Feb 25, 2019, 20:12 Nicola Galgano ***@***.***> wrote:
that's true, but we cannot see only 0 or 1, even with low resources,
we need to have one foot on two shoes anyway.... to survive
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#22446 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AM7OWpXqRe1G2j356KBGbGQm4e1xrJpRks5vRDVegaJpZM4XDBkg>
.
|
|
There is a blog post on https://developer.joomla.org/news/764-joomla-3-10-and-joomla-4-0.html about this. To understand the problem why there should be no new features in < 4.0 is because merging a 3.x commit in to 4.0 could take up to 10 minutes, it heavily depends on the commit how long it really takes. |
|
@regularlabs I gave up asking for someone to review the existing pr and make that comment |
|
@HLeithner that's from 24 January 2019 , there are more acient pr's to consume before 2019 |
|
just think some gsoc related pr's , for example 😄 |
|
So, should I create a new PR against staging to get this into a patch-release of 3.9, or what? Does anybody object, is it worth the work? Or what do we do now? The more general discussion regarding 4.0 vs 3.10 is very interesting, but this PR is not the place to discuss that. Are there other places we could do that? |
|
The PR is a (great) new feature and as long as the production department doesn't say anything new it have to go into 4.0. So please rebase the PR on 4.0 branch and we can merge it. |
ghost
added
the
|
I have created a new PR #24711 that is based on this PR, but targets 4.0-dev, as it seems like we will not get this feature into 3.x Please everybody involved in this discussion: Please take a look at #24711 and test it and let us know the results in that new PR! If we all work together I think we will be able to finally get this feature into the Joomla! core soon ;) Thank you all for your help in advance. I will close this PR. Please let us take all discussions to the new PR. |
|
@continga thx for your work |
17 participants
Summary of Changes
This pull request adds the possibility to create custom fields of a new type
subfields.Before this PR, it was only possible to add "basic" types as custom fields to articles, contacts etc, whereas "basic" types would be "text", "media", "integer", etc.
This PR adds the possibility to add a
subfieldscustom field to an article, contact etc., whereby the idea behindsubfieldsis that a user can create a list of sub fields that his custom field should contain, and those sub fields will then be presented to the user in the backend as a possibly repeatable list.Testing Instructions
Install the patch, go in the backend to e.g.
Content->Fields->New, selectType=Subfields, setTitle=test123, underFieldsadd a simpleTextfield with name and labeltest1, and another simpleTextfield with name and labeltest2. Save & close the custom field.Go to
Content->Articles->New, switch to tabFields, and check whether the newsubfieldscustom field is working as it should (so displaying a repeatable version of the configured fields). Insert an Article Title and something in the custom field, and save & close the article. Afterwards go to the frontend and check whether the article and its content is being displayed correctly.Expected result
Custom field type
subfieldscan be edited correctly, its content can be added correctly in the backend when editing/creating an article/contact/etc, and the custom field values will be correctly displayed in the frontend.Documentation Changes Required
I have written a small documentation which mainly targets developers and describes the needed actions to make a layout override for the rendering of the
subfieldsvalue. This documentation can be enhanced by everyone interested to describe the main functionality. https://docs.joomla.org/Custom_fields_type:_SubfieldsAdditional information
This PR is based on #17552
I created this PR against the 3.10-dev branch, also because I would like to have enough time to work on possible feedback coming in (not against staging, but directly against 3.10). But can we all please work together so this really ends up in 3.10, and also in 4.0? I am very willing to put much work into this, but I am dependent on you guys' feedback. So please, tell me! 🙂