I am getting the error GoogleMapAPI:createMarkerIcon: Error reading image /path/to/my/image.php when trying to load a map on my website. This only happens on my staging and live systems. Everything works fine on my dev machine. The files are completely the same on all three systems.
I couldn't find a definitive fix for the issue, but others did have it, too because there are a couple of threads on other boards regarding this issue exactly.
The path to the image is correct and the file is accessible.
I don't know if anyone is still having this issue. But I spent quite a while on GoogleMapAPI's createMarkerIcon() method because it would load the image just fine on my dev machine, but failed with the message GoogleMapAPI:createMarkerIcon: Error reading image /path/to/image.png on my staging and live machines.
I know that this has been a problem a couple of years ago and couldn't find any threads marked as 'solved' yet. So I figured, i'd share my insights with the world here.
For me, the problem was, that $_SERVER['DOCUMENT_ROOT'] returned a wrong directory. This is most likely the case, if you're using virtual hosts with some aliases configured. As long as you don't call the website over the alias, everything works fine. But as soon as you call the website with the alias, the $_SERVER variable fails to reflect the correct values. This also isn't only the case with the 'DOCUMENT_ROOT' index.
The Maps API, however, uses just this variable to determine the absolute location of the icon image. The workaround is quite simple, if you know what you're looking for. First double check that $_SERVER['DOCUMENT_ROOT'] returns the correct path. If it does in fact return the correct path and you're still getting the error, you'll need to keep looking for a solution. If it doesn't, you can easily write an override method for the API's createMarkerIcon() method. Just replace the $_SERVER['DOCUMENT_ROOT'] variable with your real document root. To retrieve it, use the following line in your index.php to create a constant with the correct path. The final slash is optional, but I recommend you add it.
define('DOCROOT',realpath(dirname(__FILE__).'/'));
That should do. Solved the error for me. Just don't make modifications to the API itself to maintain updatability.
Related
I just fixed a problem but do not exactly understand why the solution works.
Setting:
Windows 10
Laravel 7.0
PHP built in server (via php artisan serve --port=80)
Hosts file with entry 127.0.0.1 something.local
Problem:
Making a web page request to http://something.local in the browser took very long to load. Upon inspection in chrome dev tools I found out that it is not the server but the actual content download.
Although we are talking about ~7MB to download a download time of >10sec seemed insane to me.
Solution that I do not really understand :
Changing the hosts file entry to 127.0.0.1 something.habibi fixed it for me.
Why does it take so long to download a web page if I use an entry ending in .local in my hosts file?
Thoughts:
.local is not a top level domain but a special-use domain. It seems to me that because of this the request to a url ending in .local might not stay on my machine but goes through my wlan/router somehow and thus takes longer.
But this is as far as I got. It would be nice if someone can make better sense of this behaviour.
Unfortunately I can not make the special behavior of a special-use domain any clearer to you as this is not my forte at all.
But:
Do you - by any chance - have a chrome extension called "Xdebug helper" installed?
If this chrome extension would be the actual cause of your problem than your solution makes sense: changing the url in the browser has the effect that the Xdebug helper extension does not debug this new url you just put in.
Therefore you might think that your problem is caused by the different ending (switching from ".local" to ".habibi") but in reality it is just this chrome extension that gets disabled for the new url.
So long story short: your question is not reproducible and thus can't really be answered.
By the way: Others seem to have the same problem.
This is the weirdest problem I've never met on PHP (I use it since 10 years) and that's why I'm writing this message. PHP version is 7.2.
I think it's not important but i use CodeIgniter, my problem is before, in the first index.php. All works in local, but when I put my code on a server (which is a shared server unfortunately), the behavior is :
if, in the beginning of index.php, there is an image using data:image with base64, the page displays
if not, i have a blank page
I just can't understand. I noticed this when i added a phpinfo at the beginning, suddenly my page displayed because the logo of phpinfo uses this kind of picture.
I made many many many tests, and the only way to make it work is using a data:image base64 before (and by the way, just before I use "" to put it in display none and it still works...). Using a link for the image doesn't work.
I have no error, nowhere.
I just want to know if someone has an idea about what is happening here ?
Thank you so much ! (Sorry I'm not an english native person)
I think you are using windows machine for local development. And your server is Linux based...
Linux server is fully case sensitive. Please check folder,files name is correct or not..
If a folder is ../View/123.jpg
Then. The src="../VIEW/123.JPG" will work on windows machime. But error in linux server..
I dont know what to do, on my local LAMP stack and my other server's LAMP stack it work perfectly fine so I have no clue why it wouldn't on my main server. At the start, I thought that the sessions werent saving properly so I found out what folder they saved to, went to it and found an empty sess_... file and a small sess_... file that is 67B. I checked the big one and it contains the right information but the client is obviously for some reason getting the 0B one, does anyone know a fix for this?
I can provide code if necessary but I dont see how it would be.
I just tested it on Edge instead of Chrome and that somehow seems to work, I have absolutely no idea what is going on
Im relatively new to silverstripe cms and Im trying to move a site to a new host.
I followed all the instructions I could find on their official forums but to no avail.
Here is what I mean.
Here you can see what the site should look like
http://www.efekto.co.za
But this is what it looks like after I have moved it (copied everything to my public_html folder on the new site, set up the db username and passwords etc)
Please help cause I'm utterly and truly stuck at the moment.
Since someone else initialy moved the site so I decided to delete everything and move everything myself. Its hard to explain otherwise what I have tried or not tried.
First I tried to install just a base silverstripe. Got that right pretty much but only after I specified the database ip as 127.0.0.1 and not the external ip. So I deleted the base install again, copied over all the site files again and this time modified the db params to use 127.0.0.1 Some of the pages now actually reflect valid content but it seems that everything is not this light blue kind of color (seems to be a default of SS? ) It is as if it's missing some kind of master page or something as I can see content, but no module thingies like menus, blog section etc.
I also have to mention that to test this I change my hosts file so that www.efecto.co.za resolves to the sites new ip address with our new host. So from my machine it resolves to new ip but from the servers perspective when it fetches things like css its obviously going to fecth it from where www.efekto.co.za is currently hosted. Hope that makes sense?
So 1 step in the right direction at least. We have content and no more errors. Now whats up with this blue color scheme??
http://www.efekto.co.za seems to be fine now.
My guess: You've had a silverstripe-cache folder on your old server, which you've copied. It contains (as you might suspect) cached files with absolute paths. If your path structure is not exactly the same on both servers, you will run into problems. So always remove everything from the cache folder when moving sites around.
If that isn't the problem, take a look at the Apache log file (probably /var/log/apache2/error.log, but this can vary). As it's a server error, it should tell you what the problem is...
Check the error log in cpanel or whatever, perhaps a PHP or APACHE directive is different on this server. You'll find out from the logs what the problem is.
I got this once and the problem was that /dev/build wouldn't run because the php memory upper limit was set higher in SS than it was on the server.
Also go into _config and set the environment directive to 'debug', this will display as much output as SS can give you on the page.
I am new to joomla and I need to work on a joomla website for a school project. I modified an existing module to make it display featured projects and it does that flawlessly when I test the site locally. However, when I uploaded my files to the hosted copy of the website, the module will load but does not display anything. It just loads the title and the area for the php output but there is nothing returned by the script. Why would this be happening? I have joomla mostly figured out but I'm stumped when it comes to this problem.
As far as I can tell, all files related to this module have been copied over successfully and it is setup properly in the module manager. I turned on debugging mode on the hosted copy and got this message when trying to load another page with this module on it:
Parse error: syntax error, unexpected
T_STRING in
/home/content/s/r/s/srsgdmnet/html/components/com_rbids/rbids.html.php
on line 1
I looked at the file and I don't have a clue what it's talking about. Line one is just "<?php" which is fine. Is it just saying line 1 but actually referring to a problem elsewhere? This file is part of a reverse auctions component that my module interacts with. I didn't modify the code in that file with the exception of using a regular expression (search using "\n\s*(\n)", replace with "\n") to remove excessive amounts of whitespace via the replace command in Netbeans. This cut roughly 3200 lines from the file, making it much easier to navigate. I assume this did not alter anything in terms of code because it still works fine when used locally.
I modified my local configuration.php file to use the same database as the hosted copy to see if it was a database issue but it still worked fine so that rules that out. The php.ini files are the same on both copies with the exception of the local one having the Zend stuff commented out so I could use Xdebug (made this change after the problem occurred in an attempt to locate it). I have stepped through the code with Xdebug and haven't been able to track the issue down so I'm thinking it's a configuration problem.
My local copy also does not load certain modules (main menu, for one) and I can't navigate to some of the other pages, not sure if that is related. The code is the same for both copies yet each one has different results. Am I skipping vital steps for migrating the code?
I am using Joomla version 1.5.9. Please help!
Your question is ten days old, so perhaps you solved it already. But my suggestion would be to check the code for forward and back slashes. It might be that the code uses \ which works locally but fails on your server where it needs /. In Joomla extensions you can replace folder separations by DS, in the way of 'folder'.DS.'subfolder' instead of 'folder/subfolder'. The API will replace the DS by \ or / as appropriate.
However, the parse error you get indicates that something is missing in the syntax of your code. You will just have to go over it with a magnifyer glass. Sometimes when the error refers to the first line the impact of something missing works its way back to the beginning of the file. It could be a ' or ; or something small like that.
Regardless of your module, you should update to Joomla version 1.5.15 which at present is the latest version. you are 6 security releases behind schedule!
The group I have been working with has come to the conclusion that somehow Netbeans is messing up some of the files when we edit and save them. We tested by taking files from our server, opening and then saving in Netbeans, and then uploading back to the server. Sometimes this produced files that apparently did not have any newlines in them and led to php errors, breaking components or even taking down the whole site.
Our current workaround for this is to just take the files this happens to and use notepad++ to make our changes before uploading. It's a very strange issue and caused us a lot of grief. Hopefully the Netbeans team fixes this in future releases.
Thank you all for your attempts to help me solve this problem.
Try closing your <?php the traditional way and see if it works or the error line changes.
I remember seeing a similar question either on Joomla or Fabrik forums but cannot remember precise answer