I am pretty new to Virtuemart and now I do have to set up my first Webshop for a Customer.
As there is already a Virtuemart 2 Version I am now not shure which Version to take.
Well I think I am going to use VM1, because it is stable. But now I am asking myself:
What are the advantages/features of VM2?
Are there already Plugins out there for VM2? (Because I assume that
they'll need to be rewritten for VM2)
When can I expect a stable version of VM2?
Do you already have experience with VM2?
Advantages/features of VM2
For faster and more secure programming they use now more abstract classes.
Completly redesigned table layout.
Added hooks for plugins (own views, own customer number system, and so on,...), look in the wiki for more information ( http://dev.virtuemart.net/projects/virtuemart/wiki/Plugin_system )
Added registering while checkout
New backend design
Hardened against hackers
New js (jQuery to avoid Mootools incompatibility problems)
Customfields for the computer/pizza configurator
Real multicurrency, real currency format defined by currency
Prices displaying configurable by shoppergroups (also rounding)
Various sorting and searching options
Update system using Akeeba Release System (ARS, more information akeebabackup.com/software/akeeba-release-system.html)
Extensions for VM2
The extensions directory contain a lot of extensions for VM and some were updated for VM2 ( http://extensions.joomla.org/extensions/extension-specific/virtuemart-extensions )
Stable version of VM2
There is no clear data about this now. The current version at the moment is a release candidate which means a sable version is coming soon after sufficient users and developers test it and report the bugs.
Experience with VM2
I've used VM1 and migrated two websites for VM2 before. VM2 definitely worth the try, templates is way much better than the old table based ugly coded layout. Everything is perfect except if you are going to use Joomla 1.6 The modules does not work without glitches. Other that it's working with Joomla 1.5 perfectly.
Try Virtuemart 2 only if you are not planning to use any custom shipping module like canada post or UPS.
Or have enough knowledge to build it on your own.
VM2 performs shipping and payment system using plugin and trying hard to follow MVC structure of joomla.which is still under development.
Unless, VM2 is great and flexible.
Related
The current latest Joomla! v3.9.14 (August 2019)
The integrated tinymce is v4.5.11
Tinymce released the new V.5.0.0 in February 2019, including major improvements and a great new API
I want to use a plugin written with the new V5 API in Joomla!, so I wondered if it's possible to upgrade Tinymce to V5 in Joomla, or if we have no choice but to still use the old ugly Tinymce v4.x?
I tried to replace/edit files in media/editors/tinymce, just to see if it could lead to something, but of course it doesn't seem to be the right direction.
Rather than replacing the files (which could be overwritten in any future update), you're probably better off writing a new plugin for Joomla that installs Tiny 5.
The source code for the (v4) TinyMCE plugin is a good place to start to write your own - replicate how this plugin works, and you'll need to extend its functionality.
Doing it this way also means you could choose to use the Cloud version of Tiny, meaning you don't need to host the files locally, and receive updates as Tiny push them live. You do need a Tiny API key for this, but IMO, I feel it is a smarter way to host Tiny given that even during 5's life in 2019, some really useful features have been deployed, and if you're hosting all the files yourself, you'll need to keep updating them as you go.
The challenge with writing your own Tiny 5 Joomla plugin is that the core TinyMCE plugin for Joomla does not make it possible to have externally hosted Tiny plugins (such as a custom one you've created). So you would need to extend both the configuration and the instantiation to be able to store external plugin configuration, pull it in to Tiny's config, and also be able to manage your toolbars.
At Joomla Day Australia 2019 I spoke about developing external plugins for Tiny 5 in Joomla 4, and have a plugin that uses the cloud version of Tiny, and allows for external plugin configuration - but this was for an alpha version of Joomla 4.
Joomla 4 will come with Tiny 5, and I did a pull request to get external plugins in to the Editor config, so just waiting for Joomla 4 could be a more passive option.
I need to have several textfields (may be articles, but not neccessarily) on a page, that is easily edited from frontend for registered users.
How do I best achieve this?
It is for Joomla 3.1
You can go several ways:
Use a cck: this is the easiest, no coding required, browse the JED for Sobi, K2, Zoo, Content builder...
Write a simple component: using componentbuilder or the like it won't take long and you'll only need to write very little code if this is the only requirement.
Upgrade to J3.2 and use the bundled FOF (by akeeba, introduced in Joomla core as of 3.2); Joomla! 3.2 will be available in 3 days, but you can already download the beta. With FOF you can achieve much the same as 2. by writing a simple xml file.
Depending on what you plan to do with this data, and your coding skills, the right answer may be any of the above.
I had an issues with some joomla api. The issue was that I was using the latest version of joomla and couldn't find where a joomla class, that was being called in my code, was derived . I searched the joomla api docs and found nothing relating to the class I was looking for.
I then stumbled across the refactoring change log for joomla and noticed that the function i was after had actually been moved from /libraries/joomla/form to libraries/cms/form.
Why would this be the case? There doesn't seem to be any reference to /libraries/cms in the api docs. How are we suppose to know that there are classes living there? Very confusing.
Since Joomla! 1.6 the code has been progressively split into the Joomla! CMS and the Joomla! Platform. You can see this separation in the github repository - a good place to also keep track of changes that are committed to both the CMS and the Platform. The simplest way is fork each repository and keep track of them.
As classes are updated they may be migrated to the /libraries/cms directory if they apply specifically to the CMS application (e.g. html forms are an application level function not a platform level).
I find the best place to hear about changes under discussion are in the respective Google Groups - Joomla! Platform Development and Joomla! CMS Development
[Edit]
Documentation of class's is the hardest thing to find for Joomla! CMS - there doesn't appear to be a current api listing for it, unlike the Platform API reference. Often it is just easier to read through the code.
It's also worth keeping a watch on the developer sub-site.
If you want to define excellence in CMS without coding, Joomla is the right option for you.Joomla the most preferred content management system among developers is an easy-to-use open source solution.If you want to define excellence in CMS without coding, Joomla is the right option for you. In this post, you will find few of its features that make the website development easy and most preferred option for developers.
I'm working on NopCommerce 2.60 and I have extended Affiliate Module in NopCommerce 2.6 by adding two new fields like "WebsiteURL" and "Picture Upload".
For that I have made changes in Affiliate Services, Affiliate Controller, Affiliate.cs, Affiliate Map, Affiliate Model files. Now If I want to integrate these changes in upcoming versions of NopCommerce.
So What is better way to make changes in NopCommerce code and easily integrate in upcoming versions of NopCommerce?
There is no any way in nopcommerce to upgrade custom functionality in higher version. instead of that i would suggest right you function independent to nop means write separate classes for all Affiliate functionality, copy it in next version as you see in nopcommerce2.65 they have change some service, properties name.
I have recently looked into this since our company wanted to make sure nopCommerce could be upgraded at later dates if needed. The best solution we found was to make our modifications into plugins so that we could refrain from modifying the core as much as possible. Like Shivkumar said, it's not really possible to make nopCommerce upgrade proof.
Hope this helps.
I have to build a News based website but I am not sure whether to use joomla 1.5 or 1.7? I have been using joomla 1.5 for a while and there are many extensions available for it. On the other hand joomla 1.7 has less extensions available at present and I have heard joomla 1.5 support will be stopped by next year. So would you please kindly suggest me which version of joomla should I go for and why?
Thanks in Advance :)
If you are building new, build in 1.7 as 1.5 is soon to be depreciated. While some extensions are only available in 1.5, most everything new is being written for 1.7.
1.7 has a much better ACL model and other improvements that will be useful for you.
Reasons to stay on 1.5 are limited to:
1. I absolutely need a specific module and nothing similar is available in 1.7 (but if you are building for a client, think of the implications down the road for this decision.)
2. I am supporting many sites and reusing resources among them; all my other sites are on 1.5. I have a migration plan to get them to 1.7 (or 2.5), but I want to do it later in an orderly manner.
If you are holding back for any other reason, you are making a mistake.
If you need extensions that are only available for 1.5, I'd use that. But if you can get away with using/making extensions for 1.7, I'd definitely recommend using 1.7. There will be a little bit of learning at first, but it'll make for a much easier upgrade to 1.8, and you may just find some of the new 1.7 features useful.
That's the approach we've been taking recently for our client projects. There's always a bit of a chicken-and-egg issue at first (waiting for extensions to update), but we now find there are very few things stopping us from using 1.7 as a base (although we're comfortable creating our own extensions where needed).