Extended Properties feature request
-
- Regular
- Posts: 3652
- Joined: Mon Feb 13, 2006 2:40 am
- Location: Chicago, IL, USA
- Contact:
Extended Properties feature request
Template config's often have an option for image insertion, such as in the header. When a media item is inserted, and saved, a preview of the image is shown.
Extended properties have the media insert button too. However, no preview is shown if the value of that extended property is an image.. just a path is shown.
So, seems pretty easy to me.... if the value is an image, <img src="extended-property-value"...>
Yes? No?
On a related note, A portion of the extended property output uses ID's... one that particularly comes to mind is serendipity_customfields. Please style this as a class. The reason is: templates can create custom property fields. I can duplicate the entire html structure of the extended properties fieldset, but that one item in particular uses an ID, and IDs should be unique on a page.
Extended properties have the media insert button too. However, no preview is shown if the value of that extended property is an image.. just a path is shown.
So, seems pretty easy to me.... if the value is an image, <img src="extended-property-value"...>
Yes? No?
On a related note, A portion of the extended property output uses ID's... one that particularly comes to mind is serendipity_customfields. Please style this as a class. The reason is: templates can create custom property fields. I can duplicate the entire html structure of the extended properties fieldset, but that one item in particular uses an ID, and IDs should be unique on a page.
=Don=
-
- Regular
- Posts: 3652
- Joined: Mon Feb 13, 2006 2:40 am
- Location: Chicago, IL, USA
- Contact:
Re: Extended Properties feature request
I think I might be able to add this functionality myself.. Let me try.
=Don=
-
- Regular
- Posts: 3652
- Joined: Mon Feb 13, 2006 2:40 am
- Location: Chicago, IL, USA
- Contact:
Re: Extended Properties feature request
I could use some help. In serendipity_event_entryproperties.php, after line 481 (which displays the media button) I added this:
It kind of works, but I don't think that is the way the theme configuration page works. First of all, the moment an image is selected, and before theme options are saved, the image preview is shown. Makes me think the image preview is built using js? In my example above, the image is only shown after an entry is saved.
Second, in my example above, a wide image breaks through the entryproperty <fieldset> container. There is this in the stylesheet:
But that max-width is not containing the image and I'm not familiar enough yet with the admin backend to understand why just yet. Anyone want to help?
Code: Select all
<?php if (preg_match('/(\.jpg|\.png|\.bmp)$/', $value)) {
echo '<figure id="' . $fieldname . '">';
echo '<figcaption>' . PREVIEW . '</figcaption>';
echo '<img alt="" src="' . $value . '">';
echo '</figure>';
}?>
Second, in my example above, a wide image breaks through the entryproperty <fieldset> container. There is this in the stylesheet:
Code: Select all
embed, object, audio, video, img {
max-width: 100%;
}
=Don=
Re: Extended Properties feature request
Yes. For example, in the theme options for 2k11, you can pick the header img. The input element for that has the class .change_preview and a data-*-attribute called data-configitem. The value of data-configitem is the id of the figure which contains the img to be updated, but without the _img suffix.Don Chambers wrote:Makes me think the image preview is built using js?
Example here: data-configitem="header_img". That changes the img element contained by a figure (or a div, doesn't matter) with the id="header_img_preview". I suppose the .change_preview and data-configitem would work on textarea as well as input elements, but I don't think we have that case in the current backend.
I have tried to replicate that in backend but (given that I understand what you do and how you do it) can not replicate it. Where are you emitting the figure element in the entryproperties fieldset exactly?Don Chambers wrote:Second, in my example above, a wide image breaks through the entryproperty <fieldset> container.
YL
-
- Regular
- Posts: 3652
- Joined: Mon Feb 13, 2006 2:40 am
- Location: Chicago, IL, USA
- Contact:
-
- Regular
- Posts: 3652
- Joined: Mon Feb 13, 2006 2:40 am
- Location: Chicago, IL, USA
- Contact:
Re: Extended Properties feature request
Committed. I hope I did that correctly - I haven't committed anything in a very long time.
Now that the preview works, going to need to work on the backend css to get wide images contained in entryproperties like they are in theme config. YL?
Also, recall this:
Now that the preview works, going to need to work on the backend css to get wide images contained in entryproperties like they are in theme config. YL?
Also, recall this:
Don Chambers wrote:On a related note, A portion of the extended property output uses ID's... one that particularly comes to mind is serendipity_customfields. Please style this as a class. The reason is: templates can create custom property fields. I can duplicate the entire html structure of the extended properties fieldset, but that one item in particular uses an ID, and IDs should be unique on a page.
=Don=
Re: Extended Properties feature request
Worked just fine, it seems like.Don Chambers wrote:Committed. I hope I did that correctly - I haven't committed anything in a very long time.
Next time you want to address an issue in s9y, please create an issue for it (if there is none yet) and assign labels, a milestone and yourself as the assignee first. Makes it a lot easier to sort those issues and find them later. You can then references the issue in your commit by adding i.e. “References #<ISSUE-NUMBER>” in the commit message which “assigns” your commit to the issue.
As for the actual code, works just fine for me. I think you could actually only emit the img element on preg_match. That way, the JS preview should switch to the proper image even one step earlier without saving (I hope, haven't tested it. It's late over here.)
Erm, all the images I tested are contained. Largest image I tested was 3264x2448px, sooo …Don Chambers wrote:Now that the preview works, going to need to work on the backend css to get wide images contained in entryproperties like they are in theme config. YL?
![Confused :?](./images/smilies/icon_confused.gif)
Which browser are you using? Is this in a test installation running a recent git checkout? What images are you using to reproduce this (dimensions, filesize, file type)?
Might be because it's Friday night, but I don't understand this. Can you give me a more hands-on example, please? What would one do to create duplicate ids here?Don Chambers wrote:The reason is: templates can create custom property fields. I can duplicate the entire html structure of the extended properties fieldset, but that one item in particular uses an ID, and IDs should be unique on a page.
YL
-
- Regular
- Posts: 3652
- Joined: Mon Feb 13, 2006 2:40 am
- Location: Chicago, IL, USA
- Contact:
Re: Extended Properties feature request
sure thingyellowled wrote:Next time you want to address an issue in s9y, please create an issue for it (if there is none yet) and assign labels, a milestone and yourself as the assignee first. Makes it a lot easier to sort those issues and find them later. You can then references the issue in your commit by adding i.e. “References #<ISSUE-NUMBER>” in the commit message which “assigns” your commit to the issue.
Nope - I tried that. First I removed the conditional test completely, then I found a better solution. I thought I committed those shortly after the initial commit, but I just returned to my computer and realized I had not. The <img> has to exist even when the src is blank because the js is replacing the src for the ID specified in that data-configitem.yellowled wrote:I think you could actually only emit the img element on preg_match. That way, the JS preview should switch to the proper image even one step earlier without saving (I hope, haven't tested it. It's late over here.)
Don Chambers wrote:Now that the preview works, going to need to work on the backend css to get wide images contained in entryproperties like they are in theme config. YL?
Its a browser thing. Looks ok in IE, Opera Chrome and Safari. The image breaks the container for a really wide image. My image test is jpg and is 1900px wide.yellowled wrote:Erm, all the images I tested are contained. Largest image I tested was 3264x2448px, sooo …
Which browser are you using? Is this in a test installation running a recent git checkout? What images are you using to reproduce this (dimensions, filesize, file type)?
That's just it - I don't want to create duplicate IDs. A theme can create entry properties just like what you see emitted by the extended properties plugin. When creating/editing an entry, those theme-specific entry properties appear directly above the extended properties. It makes perfect sense to structure these theme-specific properties just like the extended property options, which uses a fieldset. The admin styles for the extended property <textarea>'s is styled as: #serendipity_customfields textarea. The only way for me to inherit that style in a different fieldset, is to use a duplicate ID, which is a no-no. Ideally, all styles within the extended property output would be classes, so they could be re-used in output generated by a theme. Using what already exists, changing anything presently styled as #serendipity_customfields textarea to .entryproperties_customfields textarea should work (though I've not tested it).yellowled wrote:Might be because it's Friday night, but I don't understand this. Can you give me a more hands-on example, please? What would one do to create duplicate ids here?
=Don=
Re: Extended Properties feature request
So it's Firefox only? I can't really test right now because all my test stages are remote and I have network issues.Don Chambers wrote:Looks ok in IE, Opera Chrome and Safari. The image breaks the container for a really wide image. My image test is jpg and is 1900px wide.
I would just change id="serendipity_customfields" to a class and all occurrences of #serendipity_customfields to .serendipity_customfields. That should work.Don Chambers wrote:Using what already exists, changing anything presently styled as #serendipity_customfields textarea to .entryproperties_customfields textarea should work (though I've not tested it).
YL
Re: Extended Properties feature request
Interesting. Scaling images really does not work in FF in this context. I'm not sure why yet, especially since it does work in FF in i.e. the theme options (which is basically the same markup environment).yellowled wrote:So it's Firefox only? I can't really test right now because all my test stages are remote and I have network issues.
YL
Re: Extended Properties feature request
Responsive images using max-width: 100%; height: auto; won't work inside fieldsets (in FF only) due to a bug in FF. That's a bummer because the only option seems to be to additionally set width: 100%; on those images, which means smaller images would be scaled up to the width of the container. That is clearly not an option here.yellowled wrote:I'm not sure why yet, especially since it does work in FF in i.e. the theme options (which is basically the same markup environment).
I have yet to investigate if it works if we replace the <fieldset> with a <div>. That needs a bit more work.
In any case, all this should not be backported in the 2.0 branch any time soon, it clearly needs more testing.
YL
Re: Extended Properties feature request
It does. <fieldset class="entryproperties"> needs to be a div or be wrapped in a div. Unfortunately, that screws up the whole CSS for that section. I think I can fix that, however it's going to take some time because the layout CSS here is kind of complicated.yellowled wrote:I have yet to investigate if it works if we replace the <fieldset> with a <div>. That needs a bit more work.
YL
Re: Extended Properties feature request
Phew. Not a picnic.yellowled wrote:I think I can fix that, however it's going to take some time because the layout CSS here is kind of complicated.
The three commits leading up to and including this one should fix this in Firefox.
Again, this should not be backported to 2.0 any time soon since the markup and CSS changes I needed to make were quite intrusive, and 2.0 currently is for 2.0.x, so bugfixes only. Frankly, this should have been done with a proper issue and in a feature branch.
Yup, you'll have to get used to the GitHub workflow from now on.
![Wink :wink:](./images/smilies/icon_wink.gif)
YL
-
- Regular
- Posts: 3652
- Joined: Mon Feb 13, 2006 2:40 am
- Location: Chicago, IL, USA
- Contact:
Re: Extended Properties feature request
Do you ever sleep??!!
I have no idea how to commit to a specific branch. I'm using github for windows. I'll have to research it.
I'll go fetch the latest files and report back.
![Wink :wink:](./images/smilies/icon_wink.gif)
I'll go fetch the latest files and report back.
=Don=
Re: Extended Properties feature request
I actually had a good night's sleep, thanks.Don Chambers wrote:Do you ever sleep??!!
![Smile :)](./images/smilies/icon_smile.gif)
Can't really help with that, I only use the command line git on a Mac.Don Chambers wrote:I have no idea how to commit to a specific branch. I'm using github for windows.
While you're at it, you should also look up how to cherry-pick in GitHub for Windows. Makes backporting things from master to 2.0 a whole lot easier.
YL