Please let's discuss here the new architecture ideas we want to implement in Resources 6G (or 1.6) for J!1.7
Idea #1 Change type architecture. Instead of using field plugins use standard J1.7 field elements. It means that tables jos_js_res_types, jos_js_res_fields will be deleted. If you create new type you simple create standard Joomla form XML file with different type fields. In this case we do not need type and fields tables as it will be stored in 1 XML file.
What we think would be an advantages.
- Less tables less queries
- Utilize native Joomla form generation tools and interface
- Easy to create new field
- Easy to format form display
- No need to load unused plugins. Field is called directly
Idea #2 Depreciate jos_js_res_record_values table. Not actually delete this table but change it significantly and do not use for purposes it is used right now. It will not be used to form article views either list view or full view. It will be only used AS index for filtering and sorting. All required article information will be stored in jos_js_res_record table. So actually there will be no need for processing every field before display. All fields will be processed before save record and saved with record.
Also this will make it easier to calculate filters counts.
What we think would be an advantages.
- Very big increase in speed
... 
Comments
I mean we think that it is better to have more simple fields than few complicated. We want to keep fields parameters very clear and not many.
You are going to release a "converted" Resources that runs on J! 1.7+, right ?!? I mean a compatible clone of the current 1.5.9 ?
We will not trim functionality. We not only will keep it we also will try to make it better. i am talking about simplifying UI. For example right now about 120 type parameters from will be moved to templates. This will simplify type configuration. You will set only logic, rules, behavior parameters. All display options will be moved to templates.
Good. Because your opinion is usually very strong. And very valuable of course.
You see, the current Resources architecture is the source of all unsolved problems. Especially speed problem. We cannot improve things without changing architecture. Even Resources 1.5.9 that has new speed improvement changed its architecture. But only a little not to create too many problems during update.
If we now will be able to refactor Resources it will not only make it better it will also create platform for inventing new features. Right now build upon Resources is complicated because it is already heavy. But new architecture will open possibility for extending Resources functionality.
Yes, it is true that at first we just wanted to adopt Resources as it is. But process has changed our attitude to it.
Incompatible does not means that there will not be way to migrate to new version. It only means that migration will be more complicated than simple update with SQL patches.
I think those are the 3 most important improvements for a new resources:
1. Loading time
I think loading time improvements would indeed be great as speed is a crucial factor. Have a look at this infographic for some interesting stats on how loading time affects the succes of your website.
2. SEO
Current resources is not very well SEO optimized by itself, and there are also some critical factors which make good SEO optimization very difficult. For example, for SEO it would be much better if the taber field would support the option to create a unique URL for each taber.
3. Migration from 1.5
I think a tool for a smooth migration is essential to keep us all on board
And also some more general side remarks:
4. It is very important to also keep the flexibility of the current resources product!
5. I think it would be an asset if there would be a (third?) party developing better design templates for resources frontend component, modules, filters, etc.
6. Good support for mobile templates will become more and more important
Best,
Koen
3. Migration from 1.5
I think a tool for a smooth migration is essential to keep us all on board
I agree a migration tool or even manual process is esential to keep us on board.
Recently took a quick look into Seblod 2.0 fields, they seem to use and also extend the J! elements. Maybe it is too limited for advanced field options etc. I might be totally wrong here with my limited J! API skillz Maybe an interesting source and approach to check out.
Your XML idea sounds great. Regarding your aimed multi-CMS support, maybe the right way.
By the way, where to put new feature requests for 6G ? Would you mind to open a new product/category, please?! This topic is only for the general structure.
Not possible yet. Let us release first beta and see how it looks and works and what it has. Then we start accept new features requests. Right now our plan is to transfer all current features to new version.
I still believe in you guys, and i know ME will be a best seller.
Or at least, I know you are working on it.
As explained, we want to provide you all the beautiful features of V1.5x in our next version together with a better internal concept and improved UI. But we have to create a lighter structure to handle bigger load and improve performance dramatically.
I don't want to give an exact release date, since out of experience, unexpected things always happen and we might not be able to keep our promises and this will create additional tension from the users.
We're planing also a convert utility to update existing installations to the new system. But it might happen, after we finish the new version, so that we don't waste time in always updating migrating/conversion tool while we still develop the final version.
All what i ask is some more time, since this is a much bigger step than what we experienced when we moved from V1.4.x to 1.5.
Thank you for all your patience and be assured that we working hard on the next version to provide you with the best CCK for Joomla.
I know you all are eager to know the Resources development process. So it is in progress. Although it is yet very slow as we also in progress of moving our development to other country (Philippines) but we are in progress.
I'll try to submit in the blog some information about want have been done so far.
#2 Also in place. There will be table like js_res_record_values but little bit different. And it will be used only as values index for filtering.
Actually so far I am very satisfied with this new direction.
Пока нет
Об этом думаем но тут все сложней. Очень трудно будет осуществить существующий функционал с такой архетиктурой. Потом надо будет система где надо выбрать категорию прежде чем добавить статью. Но мы об этом дамаем. Пока что это ни как не вписывается в текущий концепт. Оно как то просится или так, или так. Но нам кажется что свойства лучше оставить для типа чем для категорий.
You know, while waiting for "any" progress of Mighty Extensions, I am testing combination of component, Jomsocial, Zoo, etc..
And once again I have to say that I need an integrated component for CCK, Community, Membership and etc.
And so far, Mighty Extensions is the only complete and integrated component with ONE weakness: No Joomla 1.7 version!
So please forgive me for my inpatient.
I hope, the new version will be as complete and integrated as previous.
So if before it was slow process mainly of conceptualizing and slow development (as much as i could do it myself) now it is in full process and we can see results every day.
As i said I'll post some videos of what it looks like soon on our blog. As soon as I get more free time.
Back-end is finished all except record list.
Front-end, we are working on article submission form. And here is the list of what new features you can expect.
We understood that template is a real power. So we invented 2 new templates.
1. New "category select" template. This template actually more like form element type.It is a way to select category on submission. So it may be list of check boxes, ajax tree or sequential select. That is because there may be 10 or 100 000 categories based on our experience. And we want to provide easiest way to select correct category but not as "Only way".
2. New Markup Layout. This is layout that includes all other layouts. Right now it is default.php file. it includes filter templates, menu, record list, category index, etc.. You can ajact all those template but you cannot change their positions. With Markup Layout you will be able for example to draw filters as column on the right. And category index over or under filters or even as menu block or whatever. This template is not to style outward appearance, but rather position other templates. This wonderful feature will allow to create template sets which are not only modernly styled but specially positioned.
That was templates. More new features are coming on templates. templates will be the real feature.
One of new features also is to group fields inside the content type. This will be used later on submission form and article full view. Right now Default submission form template got 30 new parameters which will allow you to manage core fields like Create Time, Expired, Features, etc with simple access level. You can turn on and off new save buttons.
- Apply
- Save & Close
- Save & New
- Save as Copy
- Cancel
And manage labels of all all fields and buttons. I know you could manage labels even before and it is not new but new is that it is not in the template parameters rather than in type's parameters. This made type's parameters cleaner.Another option for new "default" form submission template to change group display type. If you grouped fields then you can set how you want to display it in Tabs, Sliders, Fieldsets or Pages. Then administrative fields and meta fields will be treated as separate groups.
We spent a lot of time thinking on form validation. Now we have both as server side validation as JavaScript validation of every field (where it make sense to be validated by JavaScript).
Category manager totally changed. Now it uses nested sets technique. it means no more recursive queries on categories drawing. Any category tree will be selected with single query.
I should also say about filters. Extended filters are gone. Because every fields will have filter interface. In Resources we had to build filters upon already developed system. Filters were invented in Resources 1.3. But by that time we could not change a lot of things so we have created some extended system. And core filters worked universally for every field. Now every field will have its own filter interface and for some fields even filter templates. like for example range filters may be displayed as slider.
I'll try to keep you informed on future progress.
i want to know will this customization be included in the new ver.(as you told me in the mail)
also do you expect the new version 6G to be released in one or two months
i know that you don't want to be committed to a specific release date but i am asking because i have new project an i want to do it with mighty resource at lest give us a range of time
I do not want to tell you even say 3 month and then you fail with this promise. So I do not know the answer. We will try to release it somewhere in 3 month.
But please understand. We not refactor. We completely write new Resources frontend. That means that first release may be even alpha. We of course will be quick to fix everything as soon as it is out. Also Resources will work only for new projects. Only after it is stable we will start working on Migration tool.
Yes. There will be possibility to add additional relationship properties. About relationship I have to say that it is going to be integrated into Resources. Related fields will only have params how to display parents or child lists. All relationship options will be set inside type parameters.
I know this may become a big trouble for migration from old resources to new, but here is the question.
"If we refactor everything anyway, should we sacrifice speed and usability to compatibility?"
this really help to make mind
Very very cool feature. Type independent filtering. It is not yet done but we prepared architecture of extension so filters will not be bonded to field ID but to field type and label. For example you have field Price in 2 different types and it is field type digits. Even if you have different record types in the same category list, you will have filter Price that will be applied to any records type in the category/section which has this type of field.
New filtering system is awesome. As I said there is not extended filters anymore. Every field has it is own filters. For example we created field digits. This field allow to enter only integers or floats with limited number of decimal. On the other hand this field has it's own filter which looks like 2 knobs slider
Some interesting news on new uploader we are going to use all over Resources. Please watch attached video.
Attachments:
- utf.png
watch this!Anyway thank you for the update..
I wish I could see how resource manage the page outline. Really hope to see a flexible and simple way to assign any field on a page. Customizing template is useful for expert, but if you can make it as simple as moving your mouse on screen, it would be really-really great..
And, how you manage multiple type in one category?
I am sorry. I am so human so never can say enough
Please, keep those very helpful "total nums" in filters and advanced search! Recently I had to checkout and validate all CCK solutions for search and filter capabilities. From usability point of view: Resources is second to none! Yes, there might be some performance issues... but in general I am totally addicted to this feature.
In ME Resources, users can see at once how many items has which property/value, and before they actually do their filtering! Its essential and crucial in my humble opinion.
I could not find any other Joomla (CCK) search with such a feature.
If I visit a site with a search form without any hint about the actual items... and where it makes sense to start from... I simply don´t use the the search, or I leave the whole site. Simple as that.
In old current resources we can draw filter only of one type. It means that if there are 2 or more content types in the came category we cannot show filters at all. Because imagine you have 2 types Phones and Pads
Phones has fields that are filters
- Price
- CPU
- Camera
- Color
- OS
And Pads has fields which are filters- Price
- CPU
- Camera
- Size
- OS
In current resources if you want to show filters of category with this two types it will show 11 filters. 2 Prices, 2 CPUs, 2 Cameras, 2 OSs, 1 color and 1 size. Because every filter is bond to field ID. It means when you apply filter it looks record that contain something as value where field ID = xxxIn new system this will show 6 filters. 1 Prices, 1 CPUs, 1 Cameras, 1 OSs, 1 color and 1 size. It will automatically detect that Price is the same article property and you will set only one filter for price to filter records of any type with field Price.
That means that we will not hide filters on multi type categories. We will always show filters but more filters you will apply, less filters you will see.
It also means that next Resources will be multi type native. If current Resources has only fixes to be able to use different types in one section but even then with limitations, next Resources will not have those limitations.
I am curious. When you and team develop this New Resources, what vision you have? I mean, do you plan to create "Swiss Army Knife" extension or focus into specific usage?
Of course, both have advantages and disadvantages.
Developing a "Swiss Army Knife" extension will give us unlimited option but will create a complicated and obese system which slowdown the speed and difficult to understand (because a huge parameters there)..
And if you focus your vision into a specific usage, of course we will have a limited option (and honestly I don't like that), but we will get an efficient, fast and beautiful extension and also easy to maintain.
How do you manage this dilemma? Or may be you have the answer already?
Because, I have an idea for a website and the only extension which can provide the features is Mighty Extensions (From Registration, Touch, Resource and etc). I can say that everything is possible with these. But then I face a problem with so many parameters there and customizing the template is nightmare. And suddenly I say to my self, I wish I could find a simple extension for my project but having the features as great as and as integrated as Mighty Extension.
I know it is hard to manage. People are like this. They want it simple but complex. You know like magic stick. It is extremely simple. There is no parameters at all. It simple do what you want by itself. That is what people want. And although it is not possible in real world we try to reach this level as far as possible.
Next resources will have less parameters bot more clear labels to easy understand meaning. On the other hand the same parameters will become more powerful.
Although you sometimes want very simple system you still use resources although it is complicated because it is flexible. This means that in fact you do not want more simple solution, you just want your live to be more simple (my apologize . Me too. I would like to make simple extension with 10-20 options. That would take much less time and efforts. Much easier to support and debug.
But we also use our extensions not only for our own sites but for some of our clients like UN, MCN, ... We know if we make it simple we will have to make it more flexible at the end anyway to conform request of contemporary market.
For me, the most exciting thing about Mighty Extensions is the completeness. I can build any kind of website with extensions provided by Mighty Extensions.
The problem is, it looks a bit complicated for novice user (people without programming knowledge). Actually, I am one of this novice people but keep trying to improve my knowledge to get huge benefit of Mighty Extensions.
Of course, it would be fine if your market target is experience and expert users. Then, just ignore my next comments.
So my wish is, is it visible for Mighty Extensions to have kind of Themes/Apps?
When I said Mighty Extensions, mean combination of your products.
Here is the idea:
There should be a feature in your global extensions (let say something like Mighty Assistant) to upload a Themes or Apps (what ever it called).
With this Themes or Apps, a novice user can get an instant website for a specific purpose. For example, a Themes or Apps for "Computer Store". Of course, there is prerequisite that inform user to install required Extensions such as Resources + Commerce.
Then, with only several click, a novice user will get a powerful website powered by Mighty Extensions.
Other Example, a Themes or Apps for "Social Network Website". With this Themes or Apps, a novice user only need to upload the Themes or Apps which will ask the user to Install required Extension such as Touch + Registration + Resources.
And, with several simple click, an instant social networks website created!
Benefit..
- More market target (novice user)
- Another product for sale : Themes or Apps.
- Opportunity for 3rd party to develop the Themes or Apps.
- and more..
I am not sure my English can express my idea completely.I just hope you can get the point I want to share..
Thank you..
Based on my experience, I must assume that Resources will never created for a novice user that want to create something instantly. Resources need a serious user that willing to learn with a powerful processor/server because of its complexity/resource intensive. In other words, we can't have simplicity and flexibility in Resources. Any flexible system is built on complexity.
When we have Resources 6G for Joomla 1.7 in our hands, I'm pretty sure that we must start from the beginning. I don't know about the learning curve but for what I've read from Sergey's Update, we can't depend our previous knowledge about Resources 1.5.x to use Resources 6G. We must willing to spare a lot of time/effort to learn this awesome extension. Then the famous last words will be: Are you willing to start over again?
I admire the outstanding effort/vision that ME developers have been show these years. But these days, I keep asking my self, what will happen to my website if there is no upgrade solution for Resources 1.5.x. I think I'll get stuck with Joomla 1.5 forever. Starting over again will be like a pain in the ass because I must design the system again, create its types and fields then migrate the content one by one. Are you willing to do that? I'm sure everybody will answer no.
BTW, I'm just sharing what I have in my head right now. Maybe this thought already floating around in the minds of others.
Regards,
You are right here. It will be not easy to migrate. But you do not have to. If your site is working, let it just continue work. I think when R6G is out it is more for new projects. For those who start new sites and want to base it on J1.7. But later we will make some migration that will automate process and make it less painful but still as you mentioned complicated.
All noted
Let say you set composite title style and set composite mask
[12], [25] ( <b> [11] </b> )
Where [11], [12] and [25] ids of the fields. At the end your title will looks something like this
BMW x5, 2008 ( $25 000)
This type of titles very useful in many cases.
Before we had filtering mode. In 1 - whole section, 2 - current category and 3 - category and its subcategories. There was reasons for that. I want to delete this. I want to make by default if you enable filters, it looks in whole section.
Current resources has this 3 methods because not category multi type native. Our recommendation was that even if you use multi type in section, to store at least one type per category. We had limitation of hard to list multi type records in one list. And look in category and its subcategories was reasonable.
In new resources not only 1 template (even custom) will support multi types but there also will be type filter which will allow you to switch what type of records to show in filtered search result. If in current resources you have to navigate to category with records of one type only to start filtering in new resources you can start filtering at any page.
So here is the advantages I think of
- Less options less errors/bugs
- Easy to understand with only one mode (this parameter is one of the most hard to understand)
- Start filtering on any page and get multi type results
- Much better performance
- Intuitive for end user
I think it will work this way.If there are multi type in the result we will show only common filters. I mean same filters. For example all fields has field price and color. So you will see price and color filters along with record type. But if record type is on or there is only only record type in potential result, you see all filters of this type.Example. Here are types and their filters.
Type 1: Price, Color, Size, Weight
Type 2: Price, Size, Standard
If potentially there are 2 types in result you see only Price and Size common filters. If type 1 all filters of type 1.
BTW we now use codename "Black Ice" for new resources version
Here exemple to understand this feature :
For exemple i have two different categories with differents subcategories but one or more subcategories share this two categories, i want you to add option to add cross-categories in the current category manager
this feature decrease the number of repeated categories.
I would like to see different tagging modes. Something similar to Drupals Taxomomy or K2s. I am talking of FREE tagging and PRE-DEFINED/SELECTABLE tags. The latter is ideal to keep unified terms and lower-/uppercase writing.
I also like the Resources 1.5 feature, where already existing Tags are searched and displayed... AFAIK it searched the current users tags only? Could it search in ALL Tags, CURRENT users tags, PRE-DEFINED categories, ... ?
User categories (and mixed/private mode for sections) is a great feature, I think it's underused today. Some improvements would be welcome.
(1) Menu link for users categories.
A menu link to show the users cats in a given section. Currently, we can list the user cats of a given user, not for all users.
For example, say a section in private mode is used for blogs, each blog being a user cat.
Currently, no way to list all the blogs.
We can list the articles in all blogs, the blog authors, but not the blogs themselves...
In this users-cat list, filters would be those of the section type(s) (euh filterable fields in the new type architecture), and also those of Touch userlists (I mean alphabetical by name/username, and all the rregistration fields set in Touch registration plugins).
In the given example, people would be able to filter blogs written by authors "involved in php development" , if "involved in....' is a registration field.
This requirement is not a geek wish or a customer-king's whim, it was asked by my severe teen beta-testers who are also final users. They want to see at once blogs or galleries created by everybody, or by chosen people, without having to go ten times to each people profile.
(2) Control access for users cats
Currently, user can set user cat access to Public or Registered.
It is not enough, and it's even useless: bet I, user, want to keep my blog secret to the external world.
Beta-tester said "If I set access to Registered, so, any dog with a hat (french for "really any anybody") who wants to get it just have to register and get my secret pictures...."
I asked betatesters whether the control access of groups as it exists in Touch was what she expects, and yes, it is.
Great, great: to be able to select friends and/or people having some rank. The problem above is avoided this way.
So the same access control system yet implemented in group creation should be used for user-cats access...
Furthermore, using the same mechanism would give a still better feeling of integration between Touch and Resource.
(3) Default values for user cats
To be able to set default values of some type fields when creating a user-cat would be great.
Two examples:
(3.1)In a e-bay-like site, a collector creates one user-cat per kind of items he sells.
Say a user-cat for cars.
As he is a Ferrari collector (we can dream), the cars color field would be set by default to 'red'. All this user-cat content would have this default value when creating it (needs a bit of Ajax when he fills the user-cat field in the form to set the defaults values...) Example is stupid maybe, but I'm rather sure that web designers have real world examples!
(3.2) In our blogs (user can have several blogs, each blog being a user-cat), style (I mean skin, fonts, backgrounds, layout etc) is expected by users to be the same for all articles of -this- blog.
User defines style by choosing among a set of predefined relate-parents records (or creating her style records if user is patient and savvy) its fields values being the css properties. (these records from a special section "Style")
It's not user friendly to make these choices for each blog article.
It should be done at the blog level, not article level.
Furthermore, users want to be able to modify the skin or the fonts, for example, at once for all the articles of her blog. It is not currently possible.
The only way is to have default values for these relate fields, set by user-cat editing.
I see two ways to fill this requirement.
- First is to link a "special" record to the user-cat, the field values of which would be used as default values.
- The second would be to have the default-settable fields shown in the create/edit user-cat form.
I much do prefer the second solution, because the first is not at all user-friendly, and needs explanations, which are never read by users... which make the first solution unusable in real-world of real sites filled by real users.Furthermore, all the fields don't have to be set by default (for example, for blog articles, it's rather stupid to default the main html text).
By setting a new parameter in each back-end field form (default-settable-in-user-cat, yes/no), we can choose which parameter is to be shown in front-end user-cat form.
The problem can come from user-cat using several types (berk, I don't like the idea...)
But: is it the case? What does it implies in the new fields architecture?
I cannot answer, not enough knowledge about Black Ice!
(3.3) In whatever mixed or private mode section, it would be useful. For example in galleries. I don't see any example where it would be useless.
+-+-+-+-+-+-+-+
That would make Resource greater that the greatest it is yet...
Jacques
Is it possible to add a Ajax repeat submit functionality for a field or a group of fields ?
I mean if we enable the repeat parameter for a field, then when submitting the field value we will be able to add a new repeated empty field .
Also we can have a repeat functionality for a group of fields .
first we add the repeat group field with status parameter set to start like the tabber field and then add a repeat field with status parameter set to end . now on this group field we set the repeat functionality to On . So a ( add new values for this group of fields ) will be added to the submit form using Ajax .
this functionality is good for following instances :
. repeated URL fields for Links center on a post
. having an advanced Blog ( Group of fields ) inside a post
. having unlimited number of videos on a post
,....
it is so usefull to have Ajax pagination for a group of fields in a post .
first we add a goup start and group end parameters using group field like the tabber field .
then we set the number of groups to be added on each page in the group end field parameters. so now if the number of repeated groups are more than this value a new page will be added to the post . the important note is that the pagination functionality must be Ajax , so we do not need to refresh the page since we are on the same post .
we have a paginator plugin for joomla but it is not ajax . you can see the demo here
I think it will be so better to have Ajax tabs loading the defined fields using the tabber field . so this way just the first group of fields loads with page load and when we click on another tab other fields content defined in that tab load . so this way page load time will be so small compared to the simple tabber plugin which load all the fields contents .
Will Black Ice support Multilevel of Field or Conditional Field (what ever it's named)?
I mean, condition where a user is prompted options (it can be combo-box field or others) and behind each options there are different field to fill. So, when a user select A option, the user will have to fill Y field. But when the user select B option, the user will have to fill Z field.
Thank you
Everything will be ready for those features and architecture will be created to support all that.
That is more complicated. Wee need to discuss it separately. Please add Idea here and we will discuss it more closely.
I think this will be possible to do on the level of article template. But also require additional discussion. Please add separate idea for that here.
Thank You.
Can you tell please, how will look in 6G, article multi-language input.
Joomla 1.7/2.5 had her own multilingual method, but on my opinion, very uncomfortable (we need manually, recreate full site structure for all languages...)
Will you use Joomla's build-in multilingual method or will you provide your own, more intellectual and user-friendly method?
This king of logic is useful for non-translatable sections. I mean when there are mane different languages on the site, and articles submitted into section on different languages by different users but articles are not subject to be translated.
And for sections where all articles have to have parallel translation copy we do not know yet what to do.
Will it ever be possible to migrate Resources database in Joomla! 1.5 to the new Resources in Joomla! 2.5?
another small improvement for a relate-parent/child field would be a parameter to define the number of characters to be displayed in a list view.
I faced the problem, that some of the parent records were quite long and would destroy the list layout.
A temporary fix was to include another parameter like this in the xml:
<param name="limit_chars" type="text" size="3" label="Limit characters" default="0" description="Limit characters per parent. If 0 no limit." />
and then to add something like this in the onRenderFieldValue of the relate_child3.php around line 260:
// START limit Characters
if ($params->get('limit_chars') && strlen($item->title)> $params->get('limit_chars'))
$li[$i]->link = str_replace('>'.$item->title,'>'.substr($item->title,0,$params->get('limit_chars')-3).'...',$li[$i]->link);
// END limit characters
Maybe you can consider something similar for the next version ...
Thanks ...
You can look how it looks now
Later I'll make small presentation video. I think there have to be separate idea discussion for Relation. Please would you add one
This is in regards to the new Ratings and Multiratins in Black Ice. I thought it would be a nice idea To make a version of this where users can input Half Point ratings, or .5 ratings.
I know this might be a little tricky because you would need an image that represents a Half Rating as well. Maybe you can copy all the ones you are including in Black Ice and cut each image in a left and right Half. Then edit the Ratings Template background to carry a row of those images with 50% transparancy. Then when you display a Half Rating, (Or .5) you will see a semi transparent half. and if you keep selecting as many halfs as you need the other halfs make a whole.
This is not a vital feature but some people get torn when they review certian things and want to give a little more or less to a review.
Hi guys, would you be possible to "Save" an article into a Session - kind of like you have 'compare', but this would be a "Save" or "Add" , so that a visitor without login/registration could print out a list of business listings[articles] he saved while browsing my site?
There will be even version to purchase download with buy now button of PayPal or 2CO or others. And even allow users who upload files in public sections to set their PayPal email and accept payments. It will be simple field based file download multivendor store without cart
We would love to implement native multilang support but as I know there is no solution yet built-in-joomla
The main problem, that we need manually to recreate full structure of our menus, categories and article. In Joomfish we have a possibility to translate only titles and alias of our menu positions, categories and articles, and leave global settings from default language as a default rule for all languages. In joomla's multilang systems we need to recheck everything in all language.
I wish to show very cool multilang method for wordpress, maybe some ideas is possible to implement in Resources? Here is article about this plugin (it's on russian, but from video tutorial and photos (who don't understand russian) everything is understandable). What I like in this method..... that author can make all translations directly in first article/menu/category creation step. And he don't need to create anything manually!
Russian is my native language