AdvancedContent

[davemof]

Hi jack4ya,

Thanks for the reply. I'm sorry to sound thick, but where exactly do you mean set the content type - do you mean:



in the page template or should I be looking somewhere else entirely.

Many thanks

Dave



Ignore the above comment I figured it out - there is a content type for each page within the admin panel. However, it would be useful to ensure that clients don't have to do that everytime - is there a way of setting it as default from the template.

Once again many thanks

Dave

[NaN]

EDIT: link removed since it is implemented in official release version 0.4: http://dev.cmsmadesimple.org/project/files/836

[Foaly*]

BTW: I haven't updated your module for a while.. the new features really rock!

Your patch works fine.

Annotation:

MLE
Content_en is automatically converted to "Content" in correspondant label, but not Content_de.

In general
Type image should (optionally) ignore thumb_* files.

I really take my hat off to you!

[NaN]

Thanks for your feedback.
This will be fixed soon.
I just forgot to check for 'content_[selected language here]' instead of just 'content_en' when translating the label of the main content block because translation of labels is also on my ToDo list.
I'm planning to add a new param where you can define if the values of the params will be taken as is or if they will be translated using a user defined language file placed in your uploads folder. So you're able to translate your hardcoded labels (or values).
E.g:

Code: Select all

{content block="items" type="dropdown" items="knife,fork,scissors,flame, ..." values="1,2,3,4,..." label="selectitem" tranlsate_labels="true"}

In the backend it will result in a content block labeled in the selected backend language.
So if you select german it will show a block of type dropdown with label "Wählen sie etwas aus:" and items "Messer, Gabel, Schere, Licht, ..."

All you need to do is to add these elements to the modules language file(s) - or use module_custom folder:

Code: Select all

$lang['knife'] = "Messer";
$lang['fork'] = "Gabel";
$lang['scissors'] = "Schere";
$lang['flame'] = "Licht";

What do you think of that?
It is quite rare that you need a multi language backend.
But just in case that you have two editors with different language that like to have everything labeled in their own language.

Type image should (optionally) ignore thumb_* files.

I'm confused.
It should ignore thumb_* files by default.
Or do you mean the file dropdown?
I never used it and since the filepicker is ready i never will

I really take my hat off to you!

Hey, come on it was you who set the ball rolling starting a question about custom fields when editing a page
I should have named the Module FoalyContent

[Foaly*]

Hey,

I agree with you that the multilanguage backend is rarely needed.

I was speaking of the file dropdown.


FoalyContent sounds really good and nearly speaks for itself as much as AdvancedContent does

Generally I'm wondering if you need help.. you're doing all work alone and you do it very well, but what's about collaboration on the module with GIT?

EDIT: E.g.: I'd like to add boolean param clock and alphanumeric param format for type date. Also nice would be type page (dropdown).

[NaN]

I was speaking of the file dropdown.

Is fixed in SVN.

EDIT: E.g.: I'd like to add boolean param clock and alphanumeric param format for type date.

And i'll bet the next discussion is about enabling/disabling the time dropdown by default or not...  :P

Param clock to enable/disable the time dropdown? Ja mei, Wenn's denn sein muss...

Format param? What for?

Also nice would be type page (dropdown).

No way!
The next one wants a products dropdown, or a news dropdown or a GCB dropdown or ...
As i stated some while ago i don't want to add new block types. It will never come to an end if you once start to create blocks with certain module functions.

You can do all these things without an additional block type.
We have smarty in backend now and thus we have all the power of the whole CMS in the edit panel.
If you need a page dropdown use this:

Code: Select all

{content type="dropdown" values=":::menu template='myMenuTemplateWithContentAliasesOnly':::" items=":::menu template='myMenuTemplateWithMenuTextOnly':::" smarty="true"}

Create two menu templates. One that just displays the content aliases and the other one that just displays the menu texts. Separate in both templates the menuitems by a pipe.

You can create a news category dropdown using the news module and a custom news template. You can use products module stuff or UDTs, plugins etc ... whatever you need. And all this without a specific extra module function block type stuff.

As long as we have modules and module templates that already do what we want, we don't need further block types since we have smarty in backend now (thanks again to Jeremy for that great idea).

EDIT: Anyway i'm looking forward for CMSms 1.8 to see the {content_module} tag in action. Maybe the devs found a better way to integrate certain module functions to the edit panel.

Generally I'm wondering if you need help.. you're doing all work alone and you do it very well, but what's about collaboration on the module with GIT?

Thanks but i don't know GIT (i currently try to get into SVN).
I'm working on an old (but still awesome running) Mac where GIT cannot be installed that easy. And since i'm no command line geek i dropped GIT for now. But finally i think i won't have any choice and need to get into GIT anyway.

But any help is always appreciated.
Even just testing and error reporting (is one of the most important things to me).

If you know the SVN basics and have some PHP programming skills feel free to join.

[Foaly*]

Format param? What for?

It returns timestamp. Formatting is only possible after assigning.

No way! [...]

I agree.

Code: Select all

{content type="dropdown" values=":::menu template='myMenuTemplateWithContentAliasesOnly':::" items=":::menu template='myMenuTemplateWithMenuTextOnly':::" smarty="true"}

Smartytags in strings? That works how? Oo Possible since when? Sorry, didn't now that.

As long as we have modules and module templates that already do what we want, we don't need further block types since we have smarty in backend now (thanks again to Jeremy for that great idea).

What exactly are you speaking about?

Even just testing and error reporting (is one of the most important things to me).

If you know the SVN basics and have some PHP programming skills feel free to join.

Yep.. Doing a bit code refactoring is never bad and git is compatible to svn.

[NaN]

Format param? What for?

It returns timestamp. Formatting is only possible after assigning.

Hm... not a must have. But okay to have

Code: Select all

{content type="dropdown" values=":::menu template='myMenuTemplateWithContentAliasesOnly':::" items=":::menu template='myMenuTemplateWithMenuTextOnly':::" smarty="true"}

Smartytags in strings? That works how? Oo Possible since when? Sorry, didn't now that.

It was introduced by JeremyBass some while ago in the single file content type before the project was officially started. (see some earlier post of that topic)
That means if you set the param smarty=true all values will be processed by the smarty engine. So you can use the output of plugins, UDTs or even modules as param values.

But because you cannot use the default smarty delimiters '{' and '}' since it causes errors in frontend you need to use the colons as delimiters. If smarty is set to true the AdvancedContent module checks for each param if it contains a ':::'. If so it will be replaced by the smarty delimiters and processed by the template engine using the CMSms module API.

So the example above will have as dropdown values the result of the MenuManager.
It is like using this as values:

Code: Select all

{menu template="yourSpecialVaulesTemplateHere"}

But it only will be processed in backend when displaying the content blocks.
It is not processed in frontend (since it is not needed here).

As long as we have modules and module templates that already do what we want, we don't need further block types since we have smarty in backend now (thanks again to Jeremy for that great idea).

What exactly are you speaking about?

I just mean that you can use the same functions in backend in the edit page area that are initially meant for frontend to fill the param values of your content block. And as long as you can realise your content block using the output of a module, UDT or plugin you don't need to add any new functions to the AdvancedContent module.

E.g.: There is no module that creates sortable multiple select lists. So i had to add a function to realise this. But there is a module that lists pages. So i don't need to create a new block type for that. Just see the MenuManager example. You can do the same to create a news category dropdown or whatever.

As long as you can use the output of a module, UDT or plugin that you can also call in your content/template using smarty syntax {cms_module module="SomeModule"} or {yourAwesomeUDTPlugin} to fill your param values of the content block you don't need a special block type.

Anyway what additional fields are needed anymore? You have textarea (with or without WYSIWYG), textinput, checkbox, dropdown, select multiple (even sortbale) and some special fields like file- and datepicker.
You don't need radio buttons because they do the same like a dropdown.
You also don't need password fields because it doesn't make any sense to me.
So you have almost everything you need to customize your edit panel.

The only interesting thing is how to fill the fields with dynamic values without hardcoding them in the template.
So if you need to fill the fields with values that relates to some certain modules (or just can be done in any way by them), use the certain module itself to fill it.
And even if there is no module for your purposes (e.g. list all GCBs to create a GCB dropdown) just create a UDT or plugin that does the job, assign it as param value to the block using the ':::' delimiters and tell the AdvancedContent module to process the value using the smarty engine (param smarty=true) before displaying it.

[NaN]

AdvancedContent 0.4 can be downloaded from the forge now: http://dev.cmsmadesimple.org/project/files/836

Notice: the param "type" is changed to "block_type" since it interferes with {content_module} tag.
Read the changelogs and the documentation for further changes.

Please report any issues.

[trastevere]

Is there a way to convert {content}  content to {AdvancedContent} ? Otherwise all the content disappears, and at sites with lots of content this may be a problem. I've tried directly from DB, but not with great success.

[NaN]

Yes there is.
Go to "Extensions->AdvancedContent" and click the link that says "Change all pages of type content to AdvancedContent".

(And vise versa there is an option to reset all pages of type AdvancedContent to type content again or even just delete them when uninstalling the module)

But you can also still use the default {content} plugin so no content will disappear in frontend.
Only if you want to use some certain module functions in frontend (like feu access, date format etc.) you need to use the {AdvancedContent} plugin.

You can also use the default {content_image} and {content_module} plugins.
AdvancedContent should be compatible to the default stuff.

[NikNak]

Hi NaN

I want to keep my client's secretary away from the file manager and image manager (out of harms way). Thus I have not given her the 'modify files' permission.

In Advanced content I can allow uploading of images into a specified directory (v cool) and even for those without 'modify files' permission - using the upload=true parameter.

However, it would be doubly cool if I could allow the deletion of files too, based on a parameter, in the same way. With this, the secretary would only be able to affect the single directory specified.

It's just a feature request, to a module that is great already. Is it possible?

Kind regards

Nik

[NaN]

This could be possible by just adding an additional param like delete_files="true" (or whatever). I will think about that.

I like the idea to grant certain functions for certain blocks to users that actually don't have the apropriate permissions in general by just adding some params in the template.

So a delete option is no bad idea.

Regards,
NaN.

[applejack]

Hi Nan

So re permissions for different users. How about a notes block where an admin can add a note in a content block which cannot be edited by other users and of course does not show in the front end and shows as html text rather than in a textarea. Ideally as a link using jquery lightbox with scroll but that may be pushing it I know.

[NaN]

There already is a param "description": {content description="enter some note here"}
It will be displayed in backend only before the input field as raw text.

Using lightbox ... well, erm ... the description indeed doesn't look very nice atm. I will think about a nice styling and toggeling or overlay stuff but definitely not lightbox