I downloaded a Flickr module from kohana-modules.com and when I tested on my local server worked perfectly. But when I uploaded to a remote server, to the same directory as the default Koahan modules, I got a "ErrorException [ Fatal Error ]: Class 'Flickr' not found". The default Kohana modules are working as expected. I'm using Kohana 3.2.2.
Any pointers to why this is happening?
Thanks.
I experience that exact same behaviour with both Kohana 3.2 and 3.3 if a dynamic reference to a class can not be resolved by the autoloader on a Linux server. Mainly because filesystems used by Mac OSX and Windows are case insensitive but a Unix/Linux based server is not. What operating systems are your local and remote servers running on?
Since you are using Kohana 3.2 and the main branch of the mentioned flickr module is erroneously named 3.1/master but contains 3.3 PSR-0 updates try using the 3.0 branch instead: https://github.com/jeanmask/flickr/tree/3.0/master
Heads up: even better would be to fork the github repository, build a valid Kohana 3.2 branch that holds all changes but does not contain PSR-0 modifications and state a pull request.
Related
For a project I'm working on, I'd love to be able to make use of the maven_artifact module in the Ansible Extras repository.
However, the project uses Ansible stable (currently 1.9.3) and the module is documented as only being available from version 2.0 onwards (which looks to still be in alpha).
What's the best way to "backport" this module to our current Ansible install, across many machines?
Will dropping the "maven_artifact.py" file into the "ansible/modules/extras/packaging/language/" directory on each machine work? Or will the line in the source code:
version_added: "2.0"
prevent it from running due to some sort of compatibility check?
Additionally, how can I tell whether the module relies on features present in Ansible version 2.0 and therefore is incompatible and won't run on 1.9.3 or whether it's just that version 2.0 is when it's set to be introduced?
2.0 had very minimal changes to the module subsystem- most 2.0 modules will work fine in 1.9.x (there's no version check). The easiest way to use it is to copy the source for the module you want to use from the Github extras repo to a directory called library next to your playbooks. If you have your Ansible content checked into a source-control repo of some kind, put the library directory in there too- then all your Ansible machines where you've checked out your playbook content can run the module without you needing to copy it around manually.
We have developed a project with Yii framework on local windows server. It is working with no problem on a local windows server.But when we uploaded the project to a linux hosting it started giving us problems. Not getting where is an issue?
Linux accesses files (and therefore all classes it autoloads) case-sensitively. You may run into problems when your models are called something like Contractperiod and accessing them like ContractPeriod. Rename their files to use the same name as their classes (.php) and any code using those classes to use the right names to fix this kind of issue.
Then there's the permissions; your runtime and assets folders need write access under Linux. Windows needs this as well but usually gets it automatically by being ran under an administrator account (unless you've properly configured your Windows web server). See chmod.
You may experience issues due to different PHP versions as some Linux distributions such as Debian don't have updated PHP versions in their default packages. Another possibility is that your PHP is configured differently on your Linux server; showing errors that are hidden on Windows. Generally these should be solved by repairing the code.
To get a more specific answer (or guess) for your instance you're going to have to provide us with more information, such as a copy of some of the errors.
I have created a module on a development server (xampp) all is fine and working. However when I have move the module to my production server it fails to install properly, WSOD. From db I can see that my fields are not being created.
Drupal version 7.27 on both, both clean installs with the same dependencies installed.
Nothing in apache error log.
Grateful for any tips.
Mathew
ok just incase this helps someone else further down the line - this was an issue with different versions on PHP on the two servers one had 5.3 the other 5.5. One supports short form arrays [] and one does not which was my problem.
Would i have been able to resolve this from PHP logs?
Third-party libraries are often included by the appliation server you are deploying to and class with the ones included by your application. So far I have dealt with this in the simplest and hackiest way possible: removing the libraries on the app server.
In our case it is ok, noone is relying on the app server to provide them with any libraries. But if I were running my app along with lots of other peoples app, which again might depend on the libraries included by the application server, this would not be a solution.
How is this supposed to be solved (cleanly)? How are you doing it?
An example of a problem might be this:
you build an jax-rs application using cxf, hibernate and jackson, and deploy to glassfish 2.1.1. glassfish supplies the asm 3.1 library, but this causes clashes with hibernate using an incompatible 1.5 version. similarly the application needs jackson 1.8.2 (due to a bug fix), but glassfish 2.1.1 ships with version 0.9. BOOM. Any way of fixing this other than simply removing offending libraries?
consider using :
asadmin deploy --libraries ...
I'm upgrading a RoR app that I inherited, from 1.8.7/2.3.? to 1.9/3.0.9
The app uses attachemnt_fu to allow users to upload photos, but when I try to display a photo on the home page, I get :
undefined method `public_filename' for "#<Photo:0x000000049f3838>":Photo
The model photo class that has_attachment is loading DB data (can see it in the debugger), but all the attachment_fu methods are 'undefined'. Same with any method explicitly defined in the model class (so is possible that it is not attachment_fu related)
Using attachment_fu which claims compatibility with rails 3.0.3
As usual, I was looking in the wrong place.
The problem was the upgrade to attachment_fu, and I think the solution was buried in the documentation. As near as I can tell, the plugin upgrade did not work on my install - it left the older non-rails 3 compatible library on my disk, where ruby diligently hunted it down and loaded it.
When I searched my disk and manually 'rm'ed all trace of the older installation, the method was suddenly no longer undefined.