CMS Made Simple Forums

this seems to work well for me!  :-)
Thanks so much for adding the delete=true function  -  this totally removes the need for my client to go near the file manager or image manager.

One minor point - in the filepicker where you have allowed an upload, it gives you a width and height parameter to rescale the image on upload. As far as I can tell - it ignores the height box and scales to the width only.

EDIT: Can you give an example of the syntax to use the "note" block_type?

Kind regards

nik

NikNak wrote: One minor point - in the filepicker where you have allowed an upload, it gives you a width and height parameter to rescale the image on upload. As far as I can tell - it ignores the height box and scales to the width only.

Yes you're right. Image transform stuff is kinda buggy yet.
It also ignores your input if you only use one param.
I did not write these functions. I just grabbed them from TinyMCE filepicker and tried to adapt it to fit my needs. But i think i need to completely replace this by an own function. I will fix this soon.

NikNak wrote: EDIT: Can you give an example of the syntax to use the "note" block_type?

Ah sorry, its not in the doc yet.
Just use this code:
This will print out just text.
No input fields.
So you can create your own help section using a page tab "Help" where you put in some notes to your editors.

But anyway i think of removing it in further releases because this has nothing to do in a frontend template.
Maybe i create a backend function where you can assign notes to pages or templates that will be stored in the database.

Hi NaN

The image picker doesn't work in IE7 (but does in IE6 and IE8) - you can open the file list and see the pics and select one, but the selected image does not appear once the filepicker is closed, and no image reference is stored. Trust my client to be using IE7 when I did a demo!!

Thanks

Nik

@NikNak:
Please try the latest SVN version or download from this link again.
I think i fixed the image scaling issues and even that damn IE7 issue.

Hi NaN

Actually, I have found out what the true issue was - the earlier post may be a red herring.
If you try and select an image with a space in the filename, it gets all mixed up.
It works fine on the other tested images.

I should think this won't be a big issue to solve

Kind regards

Nik

@NikNak:
Actually it were two issues
IE7 does not reaload the preview image if the source attribute is changed.
But if you completely remove the preview image from the dom and insert it again with the new src attribute it works well in IE7, FF and Safari (did not test other IEs yet)

The other issue was that the filename was used as a CSS id. I did not convert the filename to a proper value that can be used as an ID.

It is fixed in SVN as well as in the linked file.



At the moment i think about to extract the filepicker from AdvancedContent and make it a standalone module that can be used by other modules.
(It is almost ready to go now)
When thinking of that i had the idea to add the capability to create content blocks to the filepicker. (the new CMSms core function that comes with the {content_module} tag)
So content images or other files can be done this way: {content_module block="Image" module="FilePicker" params...}

That said i had another idea to use this capability also to provide the AdvancedContent input controls by using the {content_module} tag.
So {AdvancedContent block="some name" block_type="checkbox"} can also be realized by {content_module module="AdvancedContent" block="some name" type="checkbox"}.
That means you can use the default content type but with some functions of the AdvancedContent module. (Such as sortable multiple select lists, smarty processing of values etc.)
Atm i'm not sure how to realize the tabs with the {content_module} tag but all other functions could be done that way.
So you won't get in (big) trouble on updates and for me it is much more easy to maintain because i don't need to maintain the whole modified content type.
What do you guys think of that?

Hi NaN

Well, it now sort of works - you can select the image (even with a space). However, on submitting the page, when you return to the selector, no preview image shows, so you have no indicator of what has been chosen.

I'm not too familiar with the {content_module} thing yet, so cannot really comment - at the moment I only use advanced content functions that will still work if advanced content is removed. 

Kind regards

Nik

I know this issue. I recently uploaded a new release candidate to SVN and to Dropbox.
Please tell me that this is finally fixed 

Hi NaN

It still doesnt work for me - looking at the source, once an image is selected, it doesn't show the "/uploads/images/" part of the image src.

{content block="pic1" assign="pic1" block_tab="Image 1" label='$pic1' block_type="image"  mode="filepicker" dir=""  urlonly=1  page_tab="Body images"  upload=true show_subdirs=true }

Hope that helps

Nik

Ah okay, found it.
Just download again.

Images are stored relative to the image_uploads_path.
To print out the image or the full image url use the {AdvancedContent} plugin.
{content_image} tag does not work properly in frontend with AdvancedContent pages at the moment.

Yep - works now

*phew!*

Hope thats all with the file/image picker stuff.



@all:

I need some input here

I wonder if it is really a good idea to use the image uploads dir for blocks of type image. (currently this is the case in AdvancedContent)
The default content type uses for {content_image}-blocks the uploads dir.
So the module is not compatible to the standard content type.

Here an example why that makes me think:

Let's say the uploads path is "uploads" and the image uploads path is "uploads/images".
In your template you have With the default content type it will search in "uploads/banners" for any images.
If you save it "uploads/banners/myImage" will be stored in the db.

If you change that page to AdvancedContent it will search for the same block in "uploads/images/banners" for images. But there it won't find the images that were listed before.

If you move all your pictures to the image uploads dir to be able to select them in backend you will have two problems. 1st it will not list the images anymore for pages that are of type content (since it searches in another folder). 2nd in frontend all pages of type AdvancedContent won't show any images because AdvancedContent does not store "uploads/images/banners/myImage" but only "banners/myImage". But the {content_image} tag does not prepend the current upload dirs to the stored value.

The {AdvancedContent} tag does this but this is not that important now. It is just about the compatibility to the {content_image} tag. I want to switch between the two content types without any problems.

So that means AdvancedContent stores the path of images relative to the image uploads dir.

You might wonder why i not just adapt the module to be compatible to the default core stuff.
The answer is easy: I think it is an issue that the default content type stores the pathes - as mentioned above - relative to the root dir.
If you change for whatever reason the uploads folder in the config.php, with the {content_image} tag no images will be shown in frontend anymore. You need to re-edit all pages and set the content image again. If you have large projects this is a pain.

Using the {AdvancedContent} tag you won't get in trouble if upload folders changes.
But you cannot use the same folder and not the same template for that page.
You always need to remember what content type is used, where your images are stored and what templates needs to be used.

E.g. one template for default content types: and one for AdvancedContent: or But i want to be able to use the same folders and templates with both content types.

I just wonder if i should adapt the AdvancedContent module to be compatible to the default content type (what means to revert the latest changes and always just use the uploads dir - regardless if type ist set to image or to file and maybe loose the feature of dynamic folders) or if it might be better to file a feature request to the core to also use the image uploads dir and to store pathes relative to the image uploads dir.

What would you prefer?
Use the image uploads folder for all your images by default or be able to define the image dir individually by yourself?
(In case of the last one i really wonder what the image_uploads_path actually is for?)

edit: I filed a feature request to store the pathes relative to the (image) uploads dir in the default content type and prepend the (image) uploads dir to the stored path in the {content_image} tag.
If this is accepted it is up to your votes and to the developers choice if image uploads dir or just the uploads dir will be used. (i don't care about that but i just need to know what is the default to adapt the module)
And then we will have no compatibility problems anymore and a nice new feature

Thanks for the hard work.

I see the issue - surely it would have made sense for the content_image to use the image upload path in the first place. (I am not a programmer by trade, so I am probably not fit to judge). I look forward to seeing people's comments.

First, this is a very nice module for CMSMS!  Thank you NaN

This type of tag and functionality needs to be in the core IMO.

Silly Question:

Is there a way to control the width/height of text boxes that are not using the wysiwyg?  I know there is "oneline" but it makes a VERY TINY one line text field.  When I don't use "oneline" I get a really large text field.  I want to give my clients access to the three blocks of text on the blue area here http://test.ontario.org and was just thinking that a way to scale the entry text boxes in the admin to appropriate sizes would be nice.

Thanks

Hello literayz and welcome to the forum.

literayz wrote:
Is there a way to control the width/height of text boxes that are not using the wysiwyg?

Yes this is possible with the param size: