Renaming the name of the controlClass attribute for form fields#32645
Closed
korenevskiy wants to merge 17 commits intojoomla:4.2-devfrom
Closed
Renaming the name of the controlClass attribute for form fields#32645korenevskiy wants to merge 17 commits intojoomla:4.2-devfrom
korenevskiy wants to merge 17 commits intojoomla:4.2-devfrom
Conversation
Replace parentclass to controlclass. This is necessary for a more understandable associative purpose of this attribute.
Quy
reviewed
Mar 11, 2021
Contributor
Not exactly true 😄 ... I just said I wasn't going to apply your suggestion to a PR that had already gone to RTC. |
Contributor
Author
but you put a thumbs-up emoji there. 👍 |
Contributor
|
I have tested this item ✅ successfully on 6901dbc This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/32645. |
Contributor
|
I think if you dislike the |
Contributor
Author
@dgrammatiko |
**`<jdoc:include type="modules" name="top" style="default" class="grid-child" />`**
and
**`<jdoc:include type="modules" name="bottom" style="default" class="grid-child" />`**
Friends, please consider the offer to add 2 more positions to the template.
What is it for?
Answer: These fields will have little value for users who use the Cassiopeia template as it is.
BUT!, While a lot of developers use the Cassiopeia template as a basis for redefining new styles. I do it myself.
The fact is that the Bootstrap is already built into Cassiopeia, the grid, controlls, margins, and overrides of default styles are already configured. You don't need to do anything about it. Therefore, it is logical for any templates to use a ready-made Cassiopeia template to redefine its styles.
This is to add a background image, change the color. Simple as that.
But at the same time, you need to have your entire position without the parent tag.
so that you can place as many modules as you want in this position, each of which will have its own grid for mobile screens.
```
<?php if ($this->countModules('bottom-b')): ? >
<div class="grid-child container-bottom-b">
<jdoc:include type="modules" name="bottom-b" style="card" />
</div>
<?php endif; ?>
```
The container-bottom-b class and any other container class have their own built-in grid. What causes problems when the grid is not needed at all in the container class.
`<jdoc:include type="modules" name="bottom" style="default" class="grid-child" />`
**`full-width`** or **`containier-full`** (for old template as 'protostar') of **`wrapper-fluid`**
In addition, I suggest that you be able to use your own class in `<jdoc:include type="modules" name="bottom" style= "default" css="grid-child"/>`.
Thus, the position will be automatically placed in the template grid in the center of the content.
However, if the class prefix is added by the user, I suggest excluding the position class altogether. This will allow the user to add the full-grid class themselves, or to add the `grid` class or `card` class themselves.
for example, you need to make a map at the bottom of the site in the full width of the site with the route. But how to do this if the container is bounded by the central column of the grid.
This reverts commit ba46c53.
**`<jdoc:include type="modules" name="top" style="default" class="grid-child" />`**
and
**`<jdoc:include type="modules" name="bottom" style="default" class="grid-child" />`**
Friends, please consider the offer to add 2 more positions to the template.
What is it for?
Answer: These fields will have little value for users who use the Cassiopeia template as it is.
BUT!, While a lot of developers use the Cassiopeia template as a basis for redefining new styles. I do it myself.
The fact is that the Bootstrap is already built into Cassiopeia, the grid, controlls, margins, and overrides of default styles are already configured. You don't need to do anything about it. Therefore, it is logical for any templates to use a ready-made Cassiopeia template to redefine its styles.
This is to add a background image, change the color. Simple as that.
But at the same time, you need to have your entire position without the parent tag.
so that you can place as many modules as you want in this position, each of which will have its own grid for mobile screens.
```
<?php if ($this->countModules('bottom-b')): ? >
<div class="grid-child container-bottom-b">
<jdoc:include type="modules" name="bottom-b" style="card" />
</div>
<?php endif; ?>
```
The container-bottom-b class and any other container class have their own built-in grid. What causes problems when the grid is not needed at all in the container class.
`<jdoc:include type="modules" name="bottom" style="default" class="grid-child" />`
**`full-width`** or **`containier-full`** (for old template as 'protostar') of **`wrapper-fluid`**
In addition, I suggest that you be able to use your own class in `<jdoc:include type="modules" name="bottom" style= "default" css="grid-child"/>`.
Thus, the position will be automatically placed in the template grid in the center of the content.
However, if the class prefix is added by the user, I suggest excluding the position class altogether. This will allow the user to add the full-grid class themselves, or to add the `grid` class or `card` class themselves.
for example, you need to make a map at the bottom of the site in the full width of the site with the route. But how to do this if the container is bounded by the central column of the grid.
  In the Article settings. The RECORD HITS field is disabled. But this value is displayed on the site. The fact is that the disabled RECORD HITS field hides another HITS field. I believe that it should be like this: - Either the RECORD HITS field will not hide the HITS field. - Either disabling the RECORD HITS field will automatically deactivate the HITS field. 
  In the Article settings. The RECORD HITS field is disabled. But this value is displayed on the site. The fact is that the disabled RECORD HITS field hides another HITS field. I believe that it should be like this: - Either the RECORD HITS field will not hide the HITS field. - Either disabling the RECORD HITS field will automatically deactivate the HITS field.  Pull Request for Issue # .
Member
|
This pull request has automatically rebased to 4.2-dev. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I apologize.
I believe that the name of the newly added attribute for the fields is not quite correct.
Calling it the parent class. This is logical, but it is not clear which parent it refers to.
At first glance, you might think that this is the parent of the field. But this is not the case.
After thinking about it, you might think that this is the parent of the control, but this is also not the case. Since the control itself is the target.
#32488
The author @ciar4n of the attribute agreed to replace the attribute name.