MrPhil got a reaction from poj_ud in Unreadable font in the newly add-on infobox.
What character encoding is your Thai text in? A ?-in-black-diamond glyph normally means you're trying to display your page in UTF-8, but the text being supplied is encoded in something other than UTF-8 (and thus, invalid characters). Most likely you'll have to change your Thai text to UTF-8, or else change the page encoding from UTF-8 to whatever encoding is in use. What other languages are you supporting, and in what encodings? What osC version?
MrPhil got a reaction from Smoky Barnable in wysiwyg editor for index page in 2.3.1
Are you looking to modify the page text or the layout of the page? The text is defined in various language files that can be edited with any text editor (never use Dreamweaver, Expression Web, or any other HTML page editor on PHP files). If the text includes HTML tags to format the display, that could be a problem if you want WYSIWYG. You could try cutting and pasting the text (including HTML markup) into a scratch .html file. Go through and unescape all escaped apostrophes (\' --> '). Use any WYSIWYG HTML editor (such as Dreamweaver, Expression Web, Nvu, etc.) to edit this file. Go through and escape all apostrophes (' --> \'). Cut and paste it back into the language file. You really should be somewhat familiar with HTML if you're going to do this; otherwise HTML editors may insert extra code such as <!doctype>, <html>, and <body> tags that you don't want. Also note that without the standard CSS files being included, you won't get quite the same final appearance.
What osC really needs is an "Edit" button that shows up on each page just for the administrator, and allows some sort of WYSIWYG editing of a segment of text defined in a language file (and of course, writing it back to the language file within the correct "define"). It would be a big project, but would really make osC easy to modify. Anyone up for this?
If you're looking to change the layout of the page, you'll need to directly edit the PHP code with a plain text (file) editor. There is no foolproof WYSIWYG editor for PHP pages.
MrPhil got a reaction from Saldor in Excel Populate. Can.t import. Sorry for my English ;(.
Do NOT directly import XLS or CSV files into the database. Adding a product ("goodie") requires updating multiple tables. If you want to bulk import or update products (more than one at a time), install the "Easy Populate" add-on, which allows you to use a CSV (Comma Separated Values) file as your source.
Or are you already using Easy Populate, and gave it the wrong name? What osCommerce version are you using? What PHP version?
MrPhil got a reaction from ghost_barron in Help with templates
If it's just a matter of displaying fixed background images rather than colors, that should be possible by manually editing the CSS file(s) being used, to add a background-image property. If you're looking to have a background image that changes with the product, or whatever, that would require some coding.
MrPhil got a reaction from altoid in Fake URL redirection by administration
I think there would be a lesson learned here is that you don't simply delete a product, but set up something to send any old incoming link to either a similar product or to a product category. In either case, there should be some message to the visitor that the original product is no longer available, but here is something similar/here is a useful category. I suppose it's possible that there could be nothing appropriate to send a customer to, but they should still get a message of some sort explaining the situation, and making suggestions for alternatives. Hopefully this can be done in a way that Google doesn't ding you for duplicate content, or whatever.
MrPhil got a reaction from wisekurt in Restrict Shipping Method for 2.3
Besides restricting shipping choices for various products, would this be a good base for other restrictions on a product? For example, some cities or states may not allow certain "weapons" (e.g., knives or swords) to be shipped to addresses within them, or require an affidavit that the purchaser is of a certain age. Some products might be subject to national export (or import) controls, and thus can't be shipped to certain countries. Some products may be considered hazardous, and refused by certain shippers, but this is probably already handled. So, given a shipping address (and/or age), some products might have no shipping method at all, and would have to be deleted from the order, while others would have a restricted choice of shippers (you might choose to bundle the entire order together, even at a less attractive rate, rather than ship part by one shipper and part by another.
Finally, it would be good to have icons indicating shipping restrictions, to appear on a product listing page (wherever a customer could add it to the cart). For example, if FedEx won't handle it, you could have red-circle-slash "FedEx", or if you must be 21 to purchase, red-circle-slash "under 21" (or green-circle "over 21"). That sort of thing. They could trigger the "signing" of an affidavit that the purchaser is over some minimum age, although I don't know how much legal protection that would give you (it might be worthwhile to consult a lawyer, if you're selling such things). It's worth considering, rather than having all sorts of different ways to restrict shipping for various reasons.
MrPhil got a reaction from garbagecollection in Using Bengali in OS Commerce
I haven't counted them up, but you can take a look and see if it's more work than you want to do. Install (or just unzip) a standard English version (126.96.36.199) and look in catalog/includes/languages at all .php files in files and directories including the name "english". If you want to do administration in Bengali too, look in catalog/admin/includes/languages. If you're comfortable doing admin in English, you can leave it alone. I would suggest comparing these files to some other non-English, UTF-8-encoded language pack to see how to name files, how to translate, and how to set up encoding as UTF-8. "WinMerge" is a good tool for doing side-by-side file comparisons. I don't think there is anything in the .sql file you really need to change (you will be erasing all the default categories and products, anyway). There appear to be a number of icons, buttons, etc. containing English language, which you may want to edit to change the language. Finally, most add-ons (if you install them) have some language strings you'll need to edit, and maybe some icons or buttons with English text.
Editing .php files should be done with a text editor that understands UTF-8, and can be told not to write a Byte Order Mark (BOM) to the file. There are many fine editors available for free that should be able to handle this. You will need image-editing skills to update icons and buttons. GIMP is very good, and is free.
Once you have a complete Bengali translation, if done correctly, you could submit it to osCommerce as an add-on. Keep in mind that as osC is updated, you will be expected to provide updated versions of your language package.
MrPhil got a reaction from joli1811 in Paypal / OSC Rounding Totals
So, are you required by law to list the price as "including VAT", but PayPal needs it separated out as a tax? You're going to run into these complications when you build in a tax and have to remove it to display separately on the invoice. If the above is true, I'm wondering if it wouldn't be better to modify osC to store the price without VAT and when displaying a page or the shopping cart contents, to show price+VAT? What do you do for cases where VAT is not to be charged (sales to the U.S., for example?)? Is it possible to not tell PayPal that it's a tax, and just treat it as part of the base price ("including VAT")? There's got to be a better way than getting our undies tied in a knot over how to cleanly pull VAT out of a price and then putting it back in, accurate to the penny.
MrPhil got a reaction from The Lego Man in Guest Checkout options for v2.3.3 ?
Try searching on Purchase Without Account. I'm not sure that there's a PWA specifically for 2.3.3, but it's worth a try if you haven't looked on those keywords.
By the way, debate rages about whether it's worth the effort. For just about any kind of purchase, anyway, the customer has to provide as much information (name, address, contact phone, credit card info, etc.) for PWA as for a normal account. It's just a small additional amount of information (ID, password) to make an account. For customers who think they'll likely be back, an account is a good thing. For those afraid that their account opens them up to spamming, or doubt that they'll be back any time soon (and will forget that they have an account), they'll prefer PWA. Having some kind of "do not send marketing information emails or snail mail to me" clearly available, along with a clear privacy statement, can persuade reluctant customers to open an account. My suggestion is that after they've entered all the information needed for PWA, gently suggest that by adding a couple more bits of information they can have an account and save having to enter all that information again. Leave the ultimate decision up to the customer, or you could lose the whole sale.
MrPhil got a reaction from NatalieM in Georgian Language
Make sure you're starting with the right Russian language pack for your osC version (you should be at 2.3.3). There is a Russian pack for 2.3 and an upgrade from 2.3.1 to 2.3.2, so make sure you don't overlook any files or entries within files. Comparing that to the standard 2.3.3 English, you can see what needs translating, but first make sure you understand how to install the Russian add-on, so when you test your Georgian add-on, you'll know how it's supposed to install. Both Russian and Georgian should be UTF-8 encoding -- make sure you know how to edit a file in UTF-8 and save it without a Byte Order Mark (BOM).
You can translate either the Russian or the English into Georgian. If you want to, you can leave the admin side untranslated from English (copy in the English files if your starting point is the Russian package). If you start with English, make sure the georgian.php file sets the correct locale and encoding.
MrPhil got a reaction from powerpig in Help PLEASE - EU Cookies law/MODULE/...
It is not necessary to inform visitors about cookies that are essential to the function of the site (such as maintaining the session connection). If you have not added anything else using cookies to osC, you are fine. On the other hand, if you add something like (?) Google Adwords, which uses a tracking cookie, that's what the law requires you to inform visitors about and ask permission to use. The law is intended to protect visitors from an invasion of privacy by the use of tracking cookies.
If you came late to the party and have no idea what add-ons (with cookies) are being used, something like cookieguard may be necessary.
MrPhil got a reaction from roobum in Warning Error after installation of QTPro, Advice would be appreciated
It's telling you that line 1 of admin/includes/functions/general.php is outputting something, and it shouldn't be. Check for hack code added to the beginning of general.php, check for blanks before <?php, check for a Byte Order Mark (UTF-8 editing).
MrPhil got a reaction from multimixer in wysiwyg editor for index page in 2.3.1
Thinking about it some more, I have to say that it's a complete waste of time to give a layman a WYSIWYG HTML editor. At least, for all the editors I've ever seen, a layman will screw it up badly. For example, the code has an ordered list (<ol>) with 4 items in it. The store owner wants to add a 5th item. What are they going to do? Add a paragraph with a hard coded 5. in it at the end! If they can see the tags (and have the training to understand them), or the editor has a tremendous amount of smarts to restrict what they can do ("Here is a numbered list between this mark and this one. You can add, remove, move, or change a list item.") it might work. To hand a WYSIWYG editor over to an inexperienced store owner will lead to lots of problems. They will complain to you that the new 5th element doesn't quite match the look of the rest of the list, so fix it!
That said, if you still want to explore the possibilities, I'm sure something could be done. One thing would be to offer an editor page in the admin, where you could keep a list of all the defines for each page, and use an editor such as CKEditor to update them. If you can get at least the common CSS in effect, that would be good. To write an edited entry back into the file would be challendging, as it could have multiple lines. Any apostrophes would have to be escaped. The referenced editor for 2.2 seems to be something along these lines.
Another method would be a Wiki-style edit button for each separate define. For just one specific user ID (the store administrator), the regualr catalog pages would be built with each define'd text in its own id'd <span>. The page designer would put an edit button (seen only by the administrator) for that text somewhere on the page, preferably close to the text (or a toolbar could be used). When mousing over the Edit button, the corresponding text would be highlighted so the administrator knows which text they'll be editing. Click on the Edit button to pop up a CKEditor page (using the existing CSS, or refresh this page to invoke the editor). When saving, again escape apostrophes and rewrite the language file. The advantage here is that all the page's normal CSS is in effect. A nice extra would be to restrict the editor width to the final width of the element, to keep the formatting as close as possible to what they'll actually see on the page.
So, it could be done, with various degrees of success for someone who knows HTML and can work with a WYSIWYG editor to edit an existing page. For your Average Joe, I don't think the results will be worth the effort, unless you can find a fantastically sophisticated WYSIWYG HTML editor that won't let them mess up the page (call this "Prussian model editing").
MrPhil got a reaction from burt in Europe Cookie Laws
ROTFLMAO. Just wait until Amazon et al. big boys push through similar legislation in the US to get rid of all their pesky little competitors. Let's see... Microsoft hides some function in IE10 to hide cookie usage from the Feds for selected friends... all competing browsers are outlawed (as insecure)... the little guys' sites can't function very well without cookies and no one shops any more except at the big boys... are we sufficiently paranoid yet?
MrPhil got a reaction from burt in Europe Cookie Laws
I had to chuckle when I read that. The "Wild West" never was. It was purely 20th century mythology built up in the movies and TV shows. According to historians, there was actually less gunplay in the dusty streets of almost any western settlement than there is today in most large US cities. Disease, privation, isolation, abuse of Indians and minorities, sure. Wild? No.
The Internet and the World Wide Web were architected on the premise that its users would be basically honest and fair in dealing with each other. In academic, military, and government usage, that was probably a fairly safe bet. Once it was thrown open to commercial usage, and money could be made, the cockroaches poured out of the woodwork. I'd almost say that you had it backwards -- it started out genteel and is getting rougher and rougher.
MrPhil got a reaction from Name Name in Need to change header when language changes
I'm not sure what text you're asking about. When I switch to English, everything is in English except for the logo HIUKAN... and your breadcrumb trail (navigation links) at the lower right. For the breadcrumb trail, I would assume that the code should be the same as the top right breadcrumb trail, which does switch between languages. What did you do there different from the top? I would put them into a common function so that they always come out the same.
A few suggestions on the breadcrumb (second navigation bar):
Never, never, EVER hard code a non-ASCII character in a general code file. I'm talking about the double right guillemet >>. Use » instead (notice that the real breadcrumb uses that). If you ever change page character encoding, you'll be in deep trouble with those characters not displaying properly. Non-ASCII characters are OK only in a language file, where a specific character encoding is expected.
Speaking of which, those links on the right aren't really a breadcrumb, so you should use something other than » to separate them. Using >> gives the impression that's a breadcrumb (a nested series of links) rather than separate top-level links. "|" (&vbar;) is commonly used for this purpose, as are various variants such as broken bars (¦) and double bars ||, and even bullets • and other symbols.
You have an extra >> at the end of the list. People will be puzzled and look around for the next item.
Consider putting this set of links on the same line as your real breadcrumb. It just looks odd being offset onto the next line. If you fear that the two of them together will be too wide to fit without wrapping around, I would suggest left-justifying the navigation links (under the real breadcrumb list).
MrPhil got a reaction from oscommerce21 in Message: I am able to write to the configuration file - can not change permissions
How did you attempt to change the permissions? Many servers are now configured to silently ignore chmod requests from FTP clients. Try using your hosting service control panel > file manager. I don't quite follow your sequence of 'changing permissions to 444, save, upload'. If already 444 on the host, you need to change it back to 644 before uploading. Once the file has been updated on the host (after uploading), you change it to 444. You don't do anything to the file on your PC -- just to the one on the host (site).
MrPhil got a reaction from BeckyLiu in function ereg index
Is that just for the base osC code, or does that also fix any arbitrary contribution's code? I suspect the former, which means the OP will still have to manually fix any deprecated code found in her added contributions.
http://us.php.net/manual/en/migration53.deprecated.php is the full list of PHP calls that may need to be changed, and how to change them.
MrPhil got a reaction from burt in 960gs
It's certainly possible to develop a perfectly usable layout using tables -- indeed, until CSS matured, it was the only way to do it. However, keep in mind the drawbacks: it can be difficult to modify a table-driven layout if it's at all complex, it's slower to load, it can be positively hostile to the visually impaired (using screen readers), and it may not provide as good of search engine results as a div + CSS layout. I would certainly recommend using div + CSS for new work, but it's a judgment call as to whether it's worth converting over something old (and working), unless you're doing extensive changes anyway, or expect it to be around for at least 5 years.
MrPhil got a reaction from yakatz in Charging a service fee for paypal
Check the payment service agreement. I don't think PayPal allows you to charge an extra fee, and other services may or may not allow it.
If it's allowed, I don't think there's anything built-in to charge an extra fee based on the payment type. Have you looked through the contributions to see if there's something already written for it? One complication is that legally you will have to inform the customer of the extra fee (since you're already past the checkout page and totals when they select the payment type) and give them a chance to select another payment type or cancel the transaction. How about just adding a transaction fee for everyone, as part of shipping and handling?