I'm using the sfGuardPlugin with Propel on Symfony 1.4.11. I'm overriding some templates in sfGuardUser as well as sfGuardGroup and sfGuardPermission. On my localhost version this works, but on shared hosting the sfGuardGroup and sfGuardPermission modules stubbornly ignore the templates in my app, reverting instead to the cached autoXXX modules. Curiously the sfGuardUser works in this respect on both platforms.
The debug log is identical until the step
Call "sfGuardGroupActions->executeIndex()"
The local version continues correctly with
Render "sf_app_dir/modules/sfGuardGroup/templates/indexSuccess.php"
While the remote server goes on like this:
Render "sf_root_dir/cache/backend/dev/modules/autoSfGuardGroup/templates/indexSuccess.php"
I have never seen any difference in the behavior of my modules before and this really stumps me. The files in both locations are identical, except the ProjectConfiguration.class.php and database.yml. I haven't found any mention of this kind of problem. Do you have any idea what could be causing this?
Edit:
Of course I cleared the cache on both ends.
Well this is embarrassing!
Notice how autoSfGuardGroup is spelled? When I copied the cached folder I took out the 'auto', leaving a capital 'S' in front of the name. My Mac happily ignored the caps but the hosted server was not so nice.
All is well now.
Maybe I should get new glasses ... 8-}
Related
EDIT: Is there anywhere to get an un-minified version of the Here-api to use when debugging? It's impossible for me to figure out what 'v' is and why it may be undefined.
We're using the HERE API both from our website where it works flawlessly and our old RDP C++ application which runs a similar webpage in an embedded IE window. It should be using a stripped version of IE11 I believe.
We recently upgraded to the new HERE API after routing stopped working in the old one, and it worked for a while but a while ago it suddenly didn't. And no one can recall making any changes that could affect this.
I have narrowed it down to a single line of code where it crashes. (platform is already defined in the scope through our geo-service script, the same one being used for the web that works)
var defaultLayers = platform.createDefaultLayers();
This is an initialization of the map layers that is required for the maps to work, but we simply can't perform this action through this embedded browser window even though we run almost identical code on the web.
We receive two error messages of:
'v' is undefined
With a reference to some dynamically generated eval code.
This is the only lead I've managed to dig up, it's not much but I'm hoping someone else has encountered a similar issue and can point me in the right direction what to look for.
I found the issue, it was totally self inflicted...
When we implemented the solution there was an issue in the core js file from Here which made it not work in our servers due to some path being wrong. To fix this we had changed the path so it worked and then hosted our own version of the core file.
This worked great, until Here put up a new minor release which is automatically distributed through the same content link as before. This meant the minified files were no longer in sync with the variable names, thus causing v to never be defined where it should, since in our file it was probably named something else.
It was only by chance I noticed that the core js was side-loaded like that, I was looking in the completely opposite direction the entire time and didn't even consider the loading might've been tinkered with.
Ok, so first of let me start off by saying I know that with go I should really go for the net/http framework unless I have the knowledge to write my own or I explicitly tried that and it didn't work. However, I'm an idiot, and I thought I could save some time and headache by using a framework and I thought choosing one maintained by only 1 guy is a good idea. The framework is here:
https://github.com/kataras/iris
But I don't expect you to read through all of it. However, it is based on top of fasthttp which some of you might have experience with (hopefully).
The problem I'v meet with this framework is with configuration of static content serving. For example, I have my index page being served:
iris.Get("/", serveHome)
which serves and html template over at ip:port.
I have static ressources listed as such:
iris.Static("/css", "./client/css")
Which basically serves the dir css over at ip:port/css
However, when I put this all up on a server and redirected mydomain.example and www.mydomain.example to ip:port using nginx (with an ssl&tls cert), this worked:
iris.Get("/", serveHome)
and served the index.html at mydomain.example. This didn't:
iris.Static("/css", "./client/css")
And now my website can't access any static resources, because its trying to access mydomain.example/css, which, for some reason, isn't pointing to ip:port/css.
Any clue why this might be happening, have you seen this behavior on any other http server before and if so do you have any pointers that might help me figure out this thing ? I'm at a loss and any advice, even if its just speculation, would be useful.
I know you're already porting this, but if i have to guess, i'd say the problem is the relative path you're using for ./client/css.
If you're compiling this and running it form your development environment, this pretty much will run under $GOPATH/bin and i guess your CSS files are in $GOPATH/src/path/to/project/client/css... then when the compiled server tries to find ./client/css from $GOPATH/bin... well, i guess you got it, it looks up in $GOPATH/bin/client/css. But that's just a guess, i'd need more info from your project to debug that.
Good luck with porting your project!
I wrote a .qlgenerator for a particular set of file types and defined a supposedly correct set of "Imported Type UTIs" in the .plist file.
The form of UTIs is "public.archive.xxx.yyy", where "xxx" is a vendor code and "yyy" is a particular file type.
I write "supposedly", because everything seems to work fine until I install the .qlgenerator on another computer running 10.5. There it just doesn't work. Using qlmanage command I found out that the generator plugin gets properly registered for the given UTIs but when I invoke it to show preview of a file it says that my files are of type "public.archive.yyy" "rather than "public.archive.xxx.yyy". I eventually found the reason for that: On that second computer, there is an application installed, which defines those UTIs and registers itself as "Editor". The application does not provide QuickLook plugin but renders mine unusable anyway.
How can I make sure that my plugin will be used, even if someone has this (or similar) application installed?
Thanks in advance.
So I was developing a site that needed image resize so I decided to use avalanche123/imagine-bundle which uses the imagine library
In my local everything worked perfectly and then I uploaded the project to a shared hosting
When I go to the url generated by imagine bundle prints a zero
So I tried to find out where the problem is and I found it executes until this line
$image = $this->imagine->open($sourcePath);
$this->imagine is an object with class Imagine\Image\ImagineInterface
So when this line is executed it just returns 0
No exception is thrown and nothing is shown in logs
And I don't really know how imagine works inside and it seems no one else had this problem
So does anyone know what's the cause?
The AvalancheImagineBundle uses the Imagine PHP library to compute images. As stated in the README:
Depending on the chosen Image implementation, you may need one of the
following:
GD2
Imagick
Gmagick
It seems that you can choose the driver with the following configuration:
avalanche_imagine:
driver: gd
The value can be gd, imagick or gmagick and gd seems to be the default. Go ahead and see if any of this three is installed on the shared host by outputting phpinfo();. Just search for the particular string and see if it is avaiable.
I have a flex application that worked just swell until chrome got a new player: 21.0.1180.83\PepperFlash\pepflashplayer.dll
The application must break when it loads parameters from the xml file. It hangs displaying the loader of the application and on the bottom is the "Error #2032" msg.
Application still works on my localhost and in onther browser but not on the production server (IIS7). This unfortunately also means its a bit harder to debug...
Some suspicions of what might be wrong:
If I disable the pepflashplayer it works again in chrome (on the old player) so I am confident its related to the player.
Could it be related to a crossdomain file? I only have the crosdomain.xml file on the subdomain (where the parameters.xml resides)
Could it be related to mimo type set in IIS for the xml
I also connect to web services. Additionally its a problem as it is http to https call. Could this be the issue.
Ok I solved it. The problem was in an old .actionscriptproperties autogenerated file that included a lot of obsolete references to various crossdomain.xml.
Seems this do not get cleaned on project clean, so a fresh import of the project was needed which fixed the #2032 error.
Hope this helps someone.