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!
Related
we're developing a drupal 8 site with several developers. Therefor, each one of us has his own drupal instance on the dev machine (to avoid getting errors with different template file states and stuff), and they are set up like this:
/srv/www/devDudeA/html (instance A root)
/srv/www/devDudeB/html (instance B root)
/srv/www/devDudeC/html (instance C root)
and so on...
These instances are all connected to the SAME database. After writing a twig extension module (delivering a necessary twig filter) and activating it, some of my colleagues are getting several exceptions (saying the module couldn't be found), though they definitely have the same module files like me.
Do you know of trouble using the same database from different hosts? I suspect the cache is causing trouble (because i found some paths entries containing "devDudeA" or "devDudeB" in the database.
In my opinion the requiredments should be satisfied:
same module files in the same directory on each instance
same module information from (same) DB
IMHO there is the opcache and also a memcache. The integrated twig engine also has his own cache. Could it be a problem that one of us has his caching enabled while the others don't?
Im just getting crazy about this (O.x). Do you have any relevant instructions for me?
Thanks in advance & kind regards!
If you are going to have multiple devs actively working on multiple sites with a shared database odd bugs like this are going to come up. Likely a cache rebuild will resolve it, but a similar error may appear for another user. Basically you are doing something Drupal doesn't want to do.
Since you're in Drupal 8 the reasons people used for shared databases in Drupal 7 and before are largely gone. The Drupal 8 configuration management system is a vast improvement over the previous versions. You can now move site configuration using YML files between instances of the site. Those files can be managed with the rest of your code.
And you can look at using the deploy module (and supporting modules) to move content between instances.
I understand that this question may be vague, I will try my best to explain my problem and hopefully can get lots of insights from the experienced and hopefully this will not be closed.
I'm writing a PHP web app framework based on Symfony 2's components and bundles, my question may not relate to that however. The framework is intended to be open to 3rd party plugins, these plugins will have their own config files (yaml) and the person who install these plugins should be able to override these settings locally.
I also have to make sure that each time the person perform the plugin upgrade operation, it should be easy to loop over the list of "upgrade patches" to upgrade the plugin's settings while still retaining the local settings.
I imagine I can have a local, app's specific plugins.yml file which store something like this:
pluginA:
somesettings: value
somesettings2: value2
This app's specific settings file will allow user to override any default settings. And then each plugin can contain an "upgrade" class that will contain all the patches for each version, the framework will identify the current installed path and will loop through each "upgrade patch" and perform actions until it reach the most current version.
Does this sound like a good option, or if there is something else I should look into? How do I have configuration settings that can be overridden can be upgraded easily? Please let me know if you need more details.
It seems to me that you are looking to achieve something that actually core Symfony allows to do - i. e. to let other users override / implement custom parts of an already existing bundle.
If so, maybe this answer can give a good idea on how to achieve that using the ClassLoader Component (Symfony 2.0) or Composer (Symfony 2.1):
How can I override Core Symfony2 Classes?
I am in the process of planning a custom web application which will be sold (not SaaS) and so will be required to be installed on different servers. Do you think it would be a bad/good idea to go with Symfony2 or Zend Framework.
I have to choose 1 and can't go with any other framework as I only have extensive knowledge with both of these. Despite my experience with Symfony2, I would still appreciate another opinion.
My main concerns are ease of install on servers and source code protection. Sadly, it would seem ZF already has this going for it in that you don't need 5.3 like Symfony2, and we have Zend Guard.
Any advice is welcome! I am looking to nurture and grow this app and I really want to be sure the first step is the right one.
The Symfony2 download page still says:
Be warned that Symfony 2.0 is not
stable yet; use it with caution
(current version is Beta 1).
So I would wait just a but for Symfony2.
I'm not sure what you mean by source code protection but there is no point in encoding any part of any of the two frameworks since they are both open source (and you should see if their licenses actually do permit that!).
Zend Framework 2 is still in the oven and for the looks of it, Symfony2 will be out of beta way before ZF2. If you can't wait, then use the one that you are most comfortable with. Otherwise, wait for Symfony2 to come out of beta and then wait a little bit more until they iron out it's bugs.
Now, about bundling the framework in your application, you are probably going to need to write an installer of sorts. You could first look at the "sandbox" version of Symfony to see how they did that. It's basically an unzip-it-and-it-works kind of install. No need to set anything up. That could give you some pointers.
Whatever you do, you'll need to write a minimum specs script that users can download and run to check whether their system has everything ready to run your app (check configs, php modules, etc, etc). See SlideShowPro Director for an example of such scripts.
Subjective answer: I'd go with ZF because that's what I know better, but having said that, performance wise I've had better results with Symfony. Apparently ZF2 will have see huge speed improvements.
I would like to know about the compatibility between upcoming versions of KO3. I have heard that once 3.1 comes in, it won't be easy to simply upgrade to it from kohana 3.0 (Wordpress upgrade is pretty swift from 2 to version 3)
If I create my project in KO3 (currently using 3.0.6.2), what are the chances that my project will be easily upgradable to 3.1 or above versions without breaking anything ?
Please answer if you are a real pro on KO3 or part of the development team.. This is important.
Major versions (eg: 3.0 to 3.1) may change the API. Currently, the biggest API change will be splitting the Request class into Request and Response, as well as changes to Request that allow external routing. This also implies that the Remote class will be significantly modified to removed completely in favor of external requests and responses.
You can keep track of the changes scheduled for 3.1 by following the 3.1 roadmap.
I'd just like to point out that wordpress is an entirely different system, it's basically an application written on their own framework whereas kohana is just the framework and you supply the application.
If the wordpress core framework changes then they also change their application to account for those modifications. Sometimes plugins aren't compatible across upgrades so the plugin author has to release an update which makes it compatible. All of this is hidden from the front end users, they don't need to be aware of how it works in order to use it.
Kohana on the other hand has no gui or front end, you're getting nitty gritty with the code. If an interface changes then you'll have to adapt your implementation to suit, there's no way around that.
And as antpaw said, unit tests are always useful for making sure things work as expected! For more info see the unittest repo
it highly depends on the features your have used. give it a try and watch your logs or even better: you run unittests. http://github.com/kohana/core/compare/3.1...master if i picked the right repository. this will help you to see the difference betwenn ko3.1 and ko3.0.7
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.