For the second time now an apparently simple change manages to trash my store completely. I have given up for the moment, but if any of you has the solution I will be glad to hear it.
I have Magento 1702 (this also happened in 1700) on GoDaddy with the hellowired template and some other unrelated changes I coded in. The store is in Spain so the standard currency is the Euro and the language files (es_ES) are installed. Everything works A-Ok until I try to change the position of the € from prefix (€ 12,90) to suffix (12,90 €).
To make the change I navigate to /lib/Zend/Locale/Data/es.xml, find currencyFormat and change ¤#,##0.00 to #,##0.00 ¤. Simple, right?
From there on, I can't access the backend and can only access the frontend UNTIL I get to a page with a price (product or cart). When either of those happen I get a "There has been an error processing your request" screen and when I check the error logs the say "Currency USD not found". I did NOT touch the en.xml and the default currency (at admin) is the Euro.
The only solution so far is restoring the backup files. But not just the specific es.xml or even the complete es_ES folder. I have to do a full restore because I haven't been able to identify which ones actually break or why.
I can live with the € in the wrong position, but I shouldn't have to.
Any ideas about how to solve this problem?
Thanks to all
Miguel
Report the specific error message here as Alan stated in his comments. But here's a thing to check if you edited this file:
if your editor preservers the encoding of the file (utf-8)
verify if the xml of this file is valid after saving your changes
if your editor or ftp client preserves the file permissions on server
verify that you have cleared the cache on the server
Related
I'm having problem with a client site. I'm not good with Joomla (we mostly do Wordpress), but one of my long-time clients asked me to move a site from another developer that never finished it, so I obliged. The problem is, everything is working great except for the Community page:
http://gettingripped.com/index.php/community
The only errors I'm finding are with the Facebook integration (which they told me the previous dev never finished/fixed). I'm really confused here...anyone out there have any ideas? It seems instead of showing the proper titles that Com_community_somethingElseHere is replacing everything.
Thank you guys in advance for your help!
Seems something is wrong with the en-GB.com_community.ini file.
Location: gettingripped.com/language/en-GB/en-GB.com_community.ini
I could not find the file in the above location!!!
Put this file in that folder and it will work!!!
If you can't find the file to put in the folder, create your own and place it there.. how? Well, google for this string as it is (including double quotes) "en-GB.com_community.ini" and open the first couple of results.
Then copy paste the displayed file content into your own ini file (name it en-GB.com_community.ini) and place it in your en-GB folder.
Load the page and it will show up as it should!
I'm developing a shopping site using Magento, but I'm since the site needs to be for spanish-speaking people, I need to translate the site into spanish. I downloaded some .csv files to make the translation but they're not working. I've even tried to make changes on the english .csv files, changing the statements to spanish but it's still not working. Any ideas of how to make this issue work?
Thanks in advance!
Make sure, that your csv files are located in selected locale (i think /app/locale/es_ES) and this locale is selected in admin for your StoreView (System -> Configuration -> General -> Locale options)
Clear cache after changing csv files
Just found it, you need to go to system > configuration > developer > translate inline, there yoou have to eneable the changes in the backend or in the front end and thats it. Its a really hard way to get it going, but it works. Any other suggestion is welcome.
I have an ecommerce site built on OpenCart (1.5.0 i believe), which after inserting tracking code from Alexa.com and a block of code for redirecting to another site went entirely blank. Initially it worked, so I felt it was safe to save over my backups. But after refreshing the pages it was blank, and the 'view source' option in all my browsers (firefox, chrome, safari) revealed that there was no code reaching them. I then began to follow a series of debugging steps:
As my text editor was still open I undid all changes and reuploaded with no changes
I scanned the documents to be sure there were no issues in the text, with no discoveries
I ran it through W3C validation, with 2 warnings which are 1- no character encoding and 2- unable to determine parse mode.
contacted host for a server side restore though their earliest backup was a day after the problem began (it took 3 days of arguing to get them to initiate a restore)
In regards to these validation warnings, I am not sure what encoding should be used for OpenCart, ASCII or UTF-8 (which the validator resorted to) or what, in addition I am not sure if the template used with OpenCart would conflict with it if I were to declare encoding. In addition, I find it hard to believe that such a widely distributed product would have something this simple causing such a huge mistake because then all users would have this issue.
In regards to parse mode, the index page does declare parse mode (in the included header file).
In addition to all this, the validator is also claiming that it is not receiving code at all, which disables any chance of determining problems through that route.
The header and footer were both edited for these additions but are relatively long to include in this. The code used to edit were, for alexa <!-- tracking code here --> inserted into the head section of the header file, and the code for the footer was:
<span style="display:inline-block;width:160px;height:30px;text-align:center;border:#000 1px dotted;font-family:Arial,Helvetica,sans-serif;font-size:11px;background-color:#FFFFFF;"><strong style="display:block;padding:0px;margin:0px;">Reputation Management</strong>Submit Express</span>
If anymore code is needed to help then please let me know, I am not looking for someone to fix my problem but to give me relevant tips to help figure it out myself or if they do provide a fix to educate me as how they managed it so I may be able to use the same debugging method. Thanks!
EDIT: The issue, as discovered thanks to Jay, is "PHP Notice: Undefined index: HTTP_HOST in **/public_html/graphic-shack.com/index.php on line 40" and a google search has not revealed any effective results. This, to my untrained mind is jibberish, clarification would be greatly appreciated as line 40 is in fact a blank line, where as the text around it I can not post for some reason but will be viewable at http://graphic-shack.com/example.html
Open Cart uses UTF-8 throughout, so its definitely best to use that which your theme should set for the browser in the
The first thing I would ask is have you got error reporting set up (NOT OPEN CARTS ONE) that logs php errors?
If not, then you need to do something like
php_flag log_errors on
php_value error_log /path/to/custom/error.log
in your .htaccess file, so that you can log all your php errors to a file. this will need to be somewhere you can get the file, so change the path accordingly so you can view it.
Once you have that, you'll have a good base for working out the problem. I find it hard to believe that opencart has stopped because you added code. The most likely cause is a file missing, blanked or half written accidentally when saving or you've got some extra php code somewhere you shouldn't
== TEST.PHP CONTENT ==
<?php
echo '<pre>' . print_r($_SERVER, true) . '</pre>';
?>
I have a simple vb6 editor type application which has a richtextbox as the editor page. It allows users to key in stuff and the store it into a file which will keep all the text in RTF stored as CDATA in xml.
When you load back the file, it will read it off the xml and load back the rtf. We allow for unicode editing, but my problem is I have a user which is using Windows XP, and they have some problems reading the chinese characters. They show up as gibberish in their pc.
It displays fine in both mine and a coworker's. I've already checked that they have the proper regional language and settings in their system. The install files for east asian language is already checked. And they can see chinese words on websites and even type them out.
I feel like I'm missing something here but I'm at a lost on what to check next? Any ideas on what I could test or check next?
my bad for the poor description skills, if anything is not clear just ask me.
thanks.
~steve
That is weird. Try confirming that your user have the same version of RICHTXT32.OCX ?
Could be a problem with font?
Try using font that supports unicode characters (Arial Unicode).
Or try going to a website with chinese characters and paste it into richtextbox, save it to a file and try loading it from the file.
Does that work?
well they should because i packed the app in vs installer setup package.
and for fonts, it's sim sun, and i've already checked with the users that they do have the sim sun fonts under window/fonts.
Btw i've already updated that the data is actually stored in xml under CDATA, although the rtf chunk is kept as it is.
okie, this seems to be the solution although i don't know why. in my msi setup file i've included the riched.dll so when i installed it in, the dll acts up and screw up my chinese character in the richtext control.
but when i repack to exclude that dll file and reinstall using that setup, it seems to work now...
When I am using a form containing <input id="myFile" type="file" runat="server" /> to upload a file, my server-side code only sees the filename without the full path when using Firefox, while it works just fine in IE.
Is it possible to retrieve the full file path server-side in this case?
You cannot. Actually, only IE gives this information which isn't important for the server in most cases. Neither FF nor Opera, at least, provide this info.
[UPDATE] Also tried with Safari, still no path... Somebody reported that Chrome might provide the info, although being a beta, that might change...
Perhaps you might need them in some intranet cases. In such case, you might ask the user to paste the path in a secondary input field... Not very friendly, but at least they will know they provide the info.
Actually, I know some people needed this info for some reasons, so they used JavaScript to pick up the path from the file input field and put it in an hidden field. FF developers found it was insecure (you can learn a lot from a simple path... like the login name of the user!) so prohibited such usage in FF3, making some people angry against this release...
References: Firefox 3's file upload box mentioned in Firefox 3 annoyance: Keying-in disabled in file upload control ...; also File input box disabled leads to great usability problem, among many other ones.
You can never be sure of getting a full filepath or even a reliable filename or content-type submitted in a file upload file. Even if you get a full filepath you don't know what the path separator character is on the client's operating system, or whether a file extension (if present) denotes anything at all.
If your application requires the filepath/filename/content-type of a submitted file for anything more than giving the user a default title for the item uploaded, it's doing something wrong and will need fixing.
I already stated this in a comment, but I think it bears repeating.
Microsoft opted to make the file control give the entire path to the file for use in intranet applications.
The HTML specification only makes mention of what the value should contain in one spot:
User agents may use the value of the
value attribute as the initial file
name.
However, they also have examples of what the multipart/form-data encoding should look like, and it doesn't contain the file path.
In other words, IE is breaking the standard and you can't rely on other browsers, even later versions of IE, to support it.