Happy New Year everybody!
Right after the holiday season, we will start working on the new major version 4.3.0 of OXID eShop. We are glad to inform you about the planned new features in our blogpost “Roadmap for OXID eShop 4.3.0: Mostly community-driven features planned”:
http://www.oxid-esales.com/en/news/blog/road-map-oxid-eshop-430-mostly-community-driven-features-planned
Regards
I am glad to see, that the “master-image”-concept finally made it on the list.
As described here ( http://www.oxid-esales.com/forum/showthread.php?t=3616 ) I had started working on this topic (what I will put on a hold now), so I would like to present my views on how this should work as “food for thought” for the OXID developers…
As you can see from the previous picture, I have extended the “master-inage” concept on [B]all [/B]pictures (standard + up to 12 additional), so that there is consistency for all pictures used.
I have also completely revamped the look and internals of the template-part responsible for building the above input structure, which I find less confusing now…
The internals of the template have also been completely restructured: instead of [B]individually[/B] defining each entry (shudder!), I made use of Smartys’ looping capabilities (“section”): the necessary HTML-definitions for each picture entry are moved to an include-file, which is used in the Smarty loop to build all required entries for all pictures…
So the “Template Monster” “article_pictures.tpl” could be successfully tamed, and now looks like this:
[{ assign var="Conf" value=$oViewConf->getConfig() }]
[{if $Conf->getConfigParam( 'blUseMasterImage' )}]
[{ assign var="blUseMasterImage" value=true }]
[{ /if}]
[{assign var="iPicCount" value='iPicCount'}]
[{assign var="pictures" value=$Conf->getConfigParam($iPicCount)}]
[{ if $blUseMasterImage }]
[{assign var="master_pre" value="ARTICLE_PICTURES_MASTER_PRE"|oxmultilangassign }]
[{assign var="break_index" value=$pictures/2-1 }]
[{include file="article_pictures_inc.tpl" edit=$edit pic_type="masterimage" pic_short_type="MASTER" index=""}]
[{ else}]
[{assign var="break_index" value=$pictures/2+1 }]
[{include file="article_pictures_inc.tpl" edit=$edit pic_type="icon" pic_short_type="ICO" index=""}]
[{include file="article_pictures_inc.tpl" edit=$edit pic_type="thumb" pic_short_type="TH" index=""}]
[{ /if}]
[{section name=pictures start=1 loop=$pictures+1}]
[{assign var="index" value=$smarty.section.pictures.index}]
[{include file="article_pictures_inc.tpl" edit=$edit pic_type="pic" pic_short_type="P" index=$index}]
[{if $index==$break_index}]
<tr>
<td></td>
<td class="edittext">
<br>
<input type="submit" class="edittext" name="save" value="[{ oxmultilang ident="ARTICLE_PICTURES_SAVE" }]" onClick="Javascript:document.myedit.fnc.value='save'">
<br>
</td>
</tr>
</table>
</td>
<!-- Beginning of right side -->
<td valign="top" class="edittext" align="left">
<table cellspacing="0" cellpadding="0" border="0">
[{/if}]
[{/section}]
(In case somebody is interested: I would be happy to share this…)
I made the usage of the new concept [B]configurable[/B], so you could still choose to do it the “old hard way”
In that case, the old familiar picture definition mask will be displayed:
(This mask is also created by the new template structure.)
Talking of configurable: the “[B]pictures[/B]” settings in the admin have been added some parameters:
First of all, you can choose, if or if not you want to use the new “master-image”-concept.
After that you find parameters used to define another nifty enhancment: you can “[B]watermark[/B]” your images, by overlaying an image (e.g. your logo) on each article picture to prevent misuse by others.
After that you find the “[B]Recreate article images[/B]” link, which leads to another (imo desparately needed) enhancement: the capabilty to [B]recreate existing[/B] mages, if you choose to redefine picture sizes or use a different “watermark”. (Thanks to the “master-image”-concept this is now possible.)
This is done by an “[B]image_update[/B]r”, which also is capable of converting an [B]existing [/B]picture definition structure to the [B]new [/B]“master image” structure.
I have implemented that as modules, so that I have restricted myself to rebuild the current capaliities with the new concept only (i.e., the addtional picture only have the picture and the zoom)…
But now beeing part of the core, and experienced OXID developers going at it, the “master-image”-concept could be ultimately enhanced to allow an [B]icon[/B], [B]thumb[/B], [B]picture [/B]and [B]zoom[/B] for [B]all [/B]images: the standard image and the (up to 12) additional images (like good old xtCommerce has)…
I believe, that this functionality covers everything you could want from a flexible and easy picture management.
You should not need more, but also not less…
BTW:
When defining the additional configuration parameters, I found out how [B]stunningly [/B]easy that is: [B]just use [/B]your new parameter(name)s (in some predefined way) in the template to manage these parameters, define the necessary language translations, and your done!
No need to add the new fields to the database, no nothing: OXID will do all that for you automatically…
Well done, guys!
something different: whats about smarty 3 (if release 3 is stable at the time) and AdoDB replacement according to php 5.3 compability?
[QUOTE=csimon;22152]something different: whats about smarty 3 (if release 3 is stable at the time) and AdoDB replacement according to php 5.3 compability?[/QUOTE]
Good point:
Smarty 3 is “around the corner” and should be included asap, as it will increase performance and allow much better (more logical) Smarty commands.
And ADODB seems to have some problems with php 5.3 which need of course to be fixed.
The roadmap looks great, but I do feel let down. There is no mention of the plight of the international users and the lack of international payment gateways for CE version.
V.
[QUOTE=vmajor;22211]The roadmap looks great, but I do feel let down. There is no mention of the plight of the international users and the lack of international payment gateways for CE version.
V.[/QUOTE]
If you look at other OS Shopsoftware Systems like osCommerce, xtCommerce, Magento aso., you will find, that most (if not all) of these gateway interfaces for international needs where provided by the community, or interested gateway suppliers…
That’s the way OS software is supposed to work.
Do not expect OXID AG to develop and give away everything for free.
It’s hard to earn a living doing it that way.
Yes, open source is meant to drive development and innovation, however from a strategic perspective, OXID entered this space very late, with an otherwise very mature and excellent product.
There are two OXID branches now: mature EU centric OXID that is simply amazing, and the “new” CE International branch that still does not get much attention both from the OXID team and the international users.
I see it as a strategic imperative for OXID team to bridge the divide between the EU and International versions if offering OXID outside of EU is indeed their objective. I feel that OXID themselves must provide the “spark”. If/when OXID becomes truly useable outside of EU, right out of the box, the user base will grow exponentially.
This is of course my personal opinion.
Relying on the relatively mature EU user and developer community to branch out and work on the international version is not necessarily realistic. Similarly using guidance from the “feature request tool” will lead to further bias towards the EU users since they are the ones that are able to use OXID. The release 4.3 is thus fine tuning of a great product, but without actually expanding its functionality.
The few international CE edition users are in the same boat as me - OXID is a great product catalogue, but there is no possibility to use it for e-commerce. We cannot provide feature requests since we cannot even use OXID. I submitted the feature request for payment, but I do not know how many votes it will gather, if any.
Why am I still going on about OXID when I am clearly having “issues”? Because with what it does, it works really well. It is fast, simple to use and powerful. That is why I wish it worked for me…
V.
EDIT: here is the “Feature request link” for anyone that is interested: http://oxid.uservoice.com/pages/31940-feature-requests/suggestions/438938-provide-easy-to-use-international-payment-gateway
Which of the zillion payment gateways OXID is supposed to implement???
Whichever they do, many, many people will still rant, that they desperately need, of course, “the other one”…
Why am I still going on about OXID when I am clearly having “issues”? Because with what it does, it works really well. It is fast, simple to use and powerful. That is why I wish it worked for me…
You made the point here yourself:
OXID has many advantages against other shop systems, so it is your decision to either use it, and provide the missing functionality for yourself and “the community” yourself, or you accept the other drawbacks of other systems, where “the community” has provided one of the missing parts you would like to have.
The TANSTAAFL-principle is also valid here…(TANSTAAFL is shorthand for: “There ain’t no such thing as a free lunch”).
Thanks to the excellent article here http://devzone.zend.com/article/4780 it is not too difficult to develop a payment gateway interface for OXID any more.
Or let yourself be inspired by the iPayment gateway interface…
Yes, I agree, that it would be perfect, if OXID AG would provide all the missing things.
But no, I don’t think this can be reasonably expected…
Open Source still is nothing for the faint at heart…
Meanwhile I believe there is even a mental problem with the OXID CE:
in contrast to most other OS projects, where one or some people join forces, to develop an OS software (and nobody really expects to get a perfect solution for everything) the fact, that a “real” commercial company has developed OXID eShop might have led “the community” to the assumption, that you get all for free also in the future.
Very few people so far really have contributed to the OXID software in the spirit of OS software…
Which is bad.
Hi V.,
I can see your point and we appreciate your feed back. However, we are still under discussion about it…
Regards