I tried the Audio module at http://www.drupal.org/project/audio but I'm looking for alternatives if better ones exist.
My problem with the Audio module is that the current release (and the past 5 releases) seem to have all been released as unsable.
The second problem is that the player itself that plays the audio is not showing when I display the node. I thought it was a theme problem, but when reverting back to Garland, the player is still invisible.
Any solutions or alternatives?
It's hard to say much about a module from it's release names. Some module developers don't like to release stable releases, as they then are saying, this module is bug free. They don't have the same commitment if user's should have issues, as the module is a unstable version. There have been talks about making a guideline/codex for module development and when modules should be regarded as stable releases.
Anyways in your example, if you look at the usage of the project, you'll find that July 4th had 2,958 sites using the 6.x branch of the module. that's a fairly high number, so you shouldn't worry too much about the module being all that unstable.
Your problem with the player, could be a theming / settings issue. If you want help with that, you should write a more specific question about that, including what you've tried/done etc.
Related
I am using Drupal 8.9.15 (with composer and Docker).
The problem is that the vurenabilities dependency check tool detects about 200 issues and most of them are realted to Drupal, and most of them to jqueryui which is used by Drupal, for example:
/web/core/assets/vendor/jquery.ui/node_modules/grunt-html/vnu.jar/META-INF/maven/commons-fileupload/commons-fileupload/pom.xml
/web/core/assets/vendor/jquery.ui/node_modules/babel-core/node_modules/lodash/package.json
/web/core/node_modules/ftp/package.json
Why is it happening if Drupal is secure CMS?
Is it possible to fix it somehow? I see that the packages are downloading automatically to node_modules in drupal core directory.
This is unfortunately part of the reason that it's recommended to upgrade to Drupal 9 (believe me, the path is much better than from 7 -> 8).
It's known by the Drupal community that jQuery UI is no longer supported as mentioned in this change record. The recommended course of action is to upgrade to Drupal 9.
To answer your question, "Why is it happening if Drupal is secure CMS?" Well, it is as secure as it can be and as secure as its end users allow it to be. When Drupal 8 was released, jQuery UI was still supported. Now that Drupal 9 is released, jQuery UI is not part of core.
If you upgrade to Drupal 9, the security issues with jQuery UI will no longer be of concern.
Now, this is only for Drupal Core. There may still be some contrib modules that use jQuery UI elements, but that is not the responsibility of the core maintainers to watch for. However, as listed in the change record, they have mentioned a few contrib modules that still use those assets.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
We are planning to start an ecommerce startup and are evaluating scalability options for choosing between (PrestaShop/WooCommerce/OpenCart) or our own custom ecommerce solution.
We have thought of the following optimization techniques for scalability:
1) CDN for static resources.
2) Load balancer for horizontal scaling once the traffic goes high.
3) MemCached or APCU cache for caching database queries.
4) APC Cache for PHP ByteCode Caching.
5) Making sure all images are compressed losslessly.
6) Minifying CSS and JS of theme.
7) Enabling mod_deflate or mod_gzip for compression.
8) Master Slave Replication once DB starts to become a bottleneck.
9) Making sure unnecessary Apache modules are disabled.
10) Making sure unnecessary Prestashop modules are disabled.
What would you recommend? A custom eCommerce solution or we can optimize one of these frameworks(PrestaShop, WooCommerce, OpenCart etc) ?
Since others have given their comments on each solutions I will give you more overall idea.
PrestaShop/WooCommerce/OpenCart - These products are somewhat mature according to my knowledge.
Advantages
minimizes the time and efforts involved in the website building process.
plug-and-play functionality.
regular updates with bug fixes and new features.
stable and well-tested code.
help from the community.
Disadvantages
invest time to learn.
a lot of unnecessary code.
you’ll need to tweak a ready-to-use framework to meet your requirements, which will take additional time.
your website will look like all the rest.
additional third party integration step (possibly in the form of bloated jQuery plugins or similar).
no control over the code.
extra effort on security since your architecture is well known.
As you think you can't edit the core files since it will crash the system in the next update.
own custom e-commerce solution - There are pros and cons using your own e-commerce solution rather than an existing products.
Advantages
will save you time and effort in the future because it was built precisely to your long-term needs.
will not need to learn how to use or customize it.
optimized to satisfy only your needs, not everyone’s.
only what you need and in the way you need it. No unnecessary stuff, no bloated code.
full control over the code and its design implementation.
Complete modularity. The flexibility of your framework depends only on you.
A unified code base. You can minimize the need of third party components, which means less mix-and-match work.
Uniqueness of your website is 100% guaranteed.
no effort on security since your architecture is not known
Disadvantages
more time and effort.
You need to test and maintain the code.
bug fixes, updates, and new features are built by you.
To find out whether it’s a proper decision for you too, you need to answer the following questions:
Am I capable to create it?
Do I have enough free/extra time to do it?
Is it reasonable to make it?
If you are going to use PrestaShop/WooCommerce/OpenCart, I would advice you to check out Magento as well. Hope this answers your question.
Also note that your considered optimisation techniques for scalability aspects are
good but there is a lot more to be considered if you are willing to learn. I can help you with them as well.
My recommendation is PrestaShop:
1) It has CDN support
2) No "special" support (it supports master/slave DB servers)
3 & 4) Has MemCached, APC & xcache
5) Not supported by default, but has Smush.it paid module
6) Full suppoert - CCC i.e. Combine (all .js in one file, etc), Compress (minify js, css, html & Cache - the combined files in cache folder with timestamp based expiration)
7) Integrated mod_deflate, you can always enable mod_gzip at the .htaccess file
8) You can configure master (this is the default one) & slave servers, and the core PrestaShop queries support master/slave (i.e. some queries are passed to slave and they have specified which exactly). Most of the 3rd party modules does not use that feature.
9 & 10) These are the thing the administrator/developer must take care.
Custom solution is a worst case, unless if you have 1+ year and lot money to invest. I don't like Magento & OpenCart and that's why 5 years ago I chose PrestaShop for eCommerce developement. Magento has unnecessarily complex class tree and of course the developers charge usually a lot more, because they have a lot of work :), and OpenCart is a way below the others - having not a single comment in the code is a just not professional, no indexes at all on the database tables, it does not even uses template engine. Regarding the "WooCommerce" - using CMS system for eCommerce is just not serious.
My advice is to check PrestaShop - get the latest version, test it, check at addons.prestashop.com (The official Marketplace) for the modules you will need. Also, there's a newly released "PrestaShop Cloud" - you can take a look on it as well.
First of all its not frameworks its cms. Frameworks: laravel, symphony and etc..
And u can do all things with all cms. But to my mind the best - prestashop.
2) Lot of ways to optimize your server, your cms, write correct modules .
3) In prestashop you can use memcached
4) You can install APC on server and enable it in prestashop performance
5) You can edit compression settings or write/buy powerful module to get such effect
6) Minifying CSS / JS / HTML in performance (settings)
7) mod_gzip in server settings
8) Disable overrides or non prestashop modules. Do profiling to check MS and bad modules.
If you're looking at developing on top of any of the existing open source carts out there, have a good look at the code first. Just a quick look and I can make these comments:
WooCommerce -- OK if you're used to the wordpress style of code I guess but it locks you into using that specific CMS as your development framework.
PrestaShop -- Coding standards are a bit outdated (no PSR compliance), no use of namespaces, code has some but not comprehensive API documentation.
OpenCart -- code has almost no comments, no use of namespaces, limited PSR compliance, no API documentation.
Have you considered Magento 2.0 which is in beta? Magento 1 had the limitation of no namespaces because it relied on Zend Framework 1 which was pre-namespace but Magento 2.0 has namespace support while not throwing the baby out with the bathwater (Zend 1 classes have been kept and wrapped in namespaced classes).
If you're looking at extreme flexibility and the ability to code things your own way, you may be better off starting from scratch on top of one of the existing PHP frameworks (Laravel, Yii2, etc). In terms of performance you're not likely to gain much -- you're apt to make just as many performance mistakes building your own code as you will find in someone else's code. However this will be a lot of work! eBay bought Magento for $180 million and that wasn't because it was knocked together by a couple of guys in a week or two -- there is some serious programming work in all of these systems.
Building your own custom eCommerce solution from scratch can be a real nightmare for a startup and should generally be avoided.
Usually what happens a few months later is that the startup ends up having to maintain code, fix bugs and create new features internally. This all adds up and eats into time that could be better spent working on other more important aspects of your startup. There's no point re-inventing the wheel!
Eventually the startup decides to bite the bullet and scrap what they built out for several months for an off the shelf solution. They then choose a downloaded platform like Prestashop/WooCommerce/OpenCart etc.. that they feel they can then customise. This again takes time to both learn, implement and tailor to your specific needs; taking you away from other more important activities.
If you're looking for a lightweight and scalable solution that is quick to integrate, low maintainance, with no bloated code base and is super customisable you could look at more modern methodologies like eCommerce APIs.
These services are usually already heavily optimized for increased performance. They are usually available globally in multiple regions, load balanced, provide asset CDNs and some allow for custom data structures etc...
The beauty with this approach is that you can pick the components you need to integrate, without having to disable modules. You can also decide in the future that you need to change or add to your frontend technology stack and even pick a different programming language.
You could even build static sites that talk to these APIs and host a few files that make up your site in an Amazon S3 bucket for a few cents a month!?
I am trying to install the ZF2 module called ZendDeveloperTools for use with ZF2 beta4. I have placed the module inside my Module directory and added it to the modules array in config/application.config.php. When I load my app, I get the below error:
Fatal error: Interface 'Zend\Module\Consumer\AutoloaderProvider' not
found in /.../module/ZendDeveloperTools/Module.php on line 29
Looking at Module.php, here is the list of libraries that the module is trying to use:
use Zend\Module\Manager,
Zend\Module\Consumer\AutoloaderProvider,
Zend\EventManager\StaticEventManager;
When I look at the latest version of the ZF2 library which I have installed, I can see that the whole Zend\Module path is missing (Zend\EventManager is there).
Also, I can see what the ZendDeveloperTools module was last updated 4 months ago whereas ZF2 came out about 1 month ago.
Can I use the ZendDeveloperTools module at all (if so what do I need to adapt), or do I need to wait for a refactor of the module matching ZF2 beta 4?
I was the last person to work on ZendDeveloperTools. Zend Framework 2 is still in beta (we're about to release beta5 next week, after which ZF2 will go into RC). ZendDeveloperTools has not been updated since sometime around beta1, maybe beta2. At that time, the only thing it did was very rough and basic execution time profiling using microtime(), and it had a method for prepending some output (the execution time) before the tag, and immediately prior the response was sent to the browser. That was really just a proof of concept for what we really want it to be.
To answer your question, this module is very much out of date, and simply will not work with the most recent beta4 release (nor the current master branch on Github). Way too much has changed, including changed namespaces (Zend\Module is not Zend\ModuleManager) and the entire MVC stack being refactored. The module simply needs to be majorly updated. Luckily, at least one person has started on some updates here, and one of my developers as well as myself will be working with him on his updates to try to get ZendDeveloper tools functional and doing what we have envisioned. I'm also going to reach out to the developer behind the ZFDebug project for ZF1 to see if he's interested in helping.
The idea is this:
By default, ZendDeveloperTools should provide a nice floating toolbar on non-ajax HTTP requests (probably only those with a tag). This will be similar to Symfony2's web debug toolbar or the ZFDebug project for ZF1.
It will be designed with ZF2 modules in mind so that in addition to whatever default debugging tools we provide in the bar, third-party modules can provide their own "plugins" / data providers, to be displayed as additional buttons/menus on the toolbar. For example, one of my developers has started on a profiler module (currently provides DB profiling but will allow setting arbitrary timers as well), which we'd like to eventually have provide data to the ZendDeveleperTools toolbar.
Update Jul 6 2012: I've updated the latest master of ZendDeveloperTools with the great work done by #coss on GitHub. It should now be functional with beta5 which was released just a few minutes ago. :) It looks pretty nice, too!
Joomla 1.5 will reach the end of its life in a short term and many site are being upgrade to a 1.7 or 2.5 version. We are trying to figure out how we can upgrade our sites. Unfortunately the developers of Joomla, who are doing a great job, haven't kept backwards compatibility high on their requirementslist.
We know there are many resources describing how to migrate a Joomla site to version X from version 1.5. But in our company we have about 120 Joomla sites. With all the migration steps that have to be done to the templates, custom written code and the third party modules we use this would be a hell of a job to migrate. So we are looking into methods and techniques that would make our (upgrade) job easier.
I can't imagine we are the only one with this problem so I am looking for more information on migrating these sites on a large scale. We can't be the only one who are struggling with this.
To give some detail, for upgrading of the minor versions we used the Vendor branches technique which worked awesome. In short, in our SVN repository we have a folder containing the current Joomla release. In the same repository we have a folder containing our own Joomla version with some custom code adjustments. Every project is based on that custom version. With the use of version branching we could easily update all our projects to the latest Joomla version.
For the major upgrade this technique won't be suitable. For instance we expect that some projects won't be upgraded to the new Joomla version for compability issues.
A way to solve this for the 2.5 branch could be to create two new folders with the 2.5 release of Joomla and our own customized 2.5 version. Each migrated project then would be branched of the 2.5 customized version. The migration process would be tedious and for sure be a manual drill.
We are afraid that we have to do this for every major release of Joomla so this won't be a real solution.
A solution we are thinking of is using phar and composer to create the project. If we succesfully can create a joomla phar as library and put custom development in an other phar, upgrading should be as simple as replacing the phar. Third party modules should be put into a phar archive also for easy updating. If modules don't support this, we are going to phar it ourself.
Of course we know that Joomla has a new, integrated update mechanism. We are looking into this mechanism but doubt we can use it since we have some custom patches to core code or module functionality.
To summarize this post, we have two challenges we'd love to get some feedback of.
How would you sggest upgrading 120+ sites to the latest release of Joomla
How do you manage Joomla updates if you have a large number of Joomla sites to maintain
The bad news is that there is no automated upgrade path from Joomla 1.5 to 2.5, as the changes are so drastic that they are almost like night and day. The template changes are such that you may have to rewrite them from scratch. Do not forget that 2.5 does a number of things differently too so you may also face a learning curve.
My suggestion would be to have a tiered migration plan and only migrate the sites that you need to or can justify the costs of the migration as the components, modules and plugins you use.
When doing so you need to watch the release schedule which provides a Long Term Release every 18 months each of which will most probably break backward compatibility from the previous versions, so you will end up with sites at 1.5, 2.5, 3.x etc
I believe that phar can be used in order to distribute a new upgraded version - but it will not help you in the upgrade process itself.
My (painful) experience with a migration from 1.5 to 1.7 taught me that not only the code changes were dramatic but also the DB changes (structure!), ACL implementation etc etc. The template will probably be the least of your problems.
My question back to you is, why do you want to upgrade ALL the websites ? if a specific website needs tools/plugins that are available only on higher versions of Joomla then I guess it's a good enough reason. But to upgrade all the websites will be, like you anticipate, a project from hell...
I've read that you can host multiple drupal sites, while they use the same core files(so not needing to copy a few megabytes for each site). I wanted to ask if there is an automated tool that can create a new site, while let you choose a template and then connecting it to the drupal system?
Are there tools like that(with a web layout)?
I would really like to get a few pointers as to how, lets say a company for building websites, will be able to use an automated system to build sites easily. I also understand that with drupal you have alot of manuver to edit your own code, when lets say you want some future in one of the sites. Is it pure php/html or in order to do that you have to delve into core Drupal futures? Also what are the chances that somebody already did it before and you can use this module?
Last, if a company wants to move to a Drupal system (web development company), how much of a transformation is it? Should they be Drupal core experts in order to not lose themself? Or they can keep a drupal base while still using the regular html/php? I really appreciate any leads.
Thanks.
*the questions is also intended to Joomla.
To answer your first question, the Aegir project is a system whereby you can use Drupal to create and manage Drupal sites. That includes installing from install profiles--which are sort of like site templates--or a distribution (Drupal installations pre-packaged with modules). The downside is that installation is fairly involved, more so than just Drupal itself. There's a lot of documentation on the Drupal groups site for Aegir. For a straight multi-site install, there's some documentation on the subject, but the install instructions with the software come with help that you should consult first.
As for your second question, the answer is (unfortunately) "it depends". Knowledge of PHP, especially "the Drupal way", plus integration with the community, are huge plusses. If you intend to join the community, immediately sign up both yourself and all developers an account on Drupal.org and, if you find solutions to bugs or other problems, providing back is a sign of goodwill, and it usually pays back dividends (one example: you submit a patch, it gets included in a module, and then the community maintains it for you). Developers need not be experts with Drupal core, but they need to be pretty comfortable with learning the API and knowing how to create sites for clients in general. First start with requirements gathering, then see how it fits into the Drupal way of doing things. If it doesn't fit, then use the right tool.
That's a tip of the iceberg view from the developer's point of view (as opposed to the businessman's point of view). There are plenty of companies that do only Drupal and there are plenty of companies where Drupal is one tool they use out of many.