Jump to content

Search the Community

Showing results for tags 'PW installation'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Welcome to ProcessWire
    • News & Announcements
    • Showcase
    • Wishlist & Roadmap
  • Community Support
    • Getting Started
    • Tutorials
    • FAQs
    • General Support
    • API & Templates
    • Modules/Plugins
    • Themes and Profiles
    • Multi-Language Support
    • Security
    • Jobs
  • Off Topic
    • Pub
    • Dev Talk

Product Groups

  • Form Builder
  • ProFields
  • ProCache
  • ProMailer
  • Login Register Pro
  • ProDrafts
  • ListerPro
  • ProDevTools
  • Likes
  • Custom Development

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 1 result

  1. Hi All, After SiNNuT's excellent help in this post: (thank you, SiNNuT), http://processwire.com/talk/topic/5400-tinymce-converting-html-entities-to-characters/ I ran across a new situation -- or more accurately -- a new knowledge gap that I wish I didn't have. I have another PW install, in which the curly quotes are not displaying properly, even though the header includes the line: <meta http-equiv="content-type" content="text/html; charset=utf-8" /> I was digging around, and noticed that I had installed PW into a database that I had created, set to: * charset: latin1 * collation: latin1_swedish_ci instead of utf8 and utf8_general_ci. Now, just to be clear, one of my PW installs with the latin1 charset does display the curly quotes correctly, so I'm not sure why the other install does not. I'm not entirely sure if the db charset and collation are the issue, or something else. And that's an item to solve. But my main questions here are: - Is the issue of installing PW into a latin1 db a huge problem? (It would be really great if the PW install prompted one to make sure that the db had the right charset. Or maybe it did, and I missed it.) - If it is a problem, does anyone have any tips on converting the db, tables and content appropriately? I'm under the impression that one could relatively easily convert the db and tables to utf8, but that the content would have to be converted as well -- perhaps using the PHP inconv function, as Ryan pointed out in another post? $newPage->title = iconv("ISO-8859-1", "UTF-8", $row['HEADLINE']); That sounds like a lot of effort and processing: having to convert every field of every page. As I mentioned, I have one install with latin1 where everything seems to be working okay. So maybe no conversion is necessary. ?? It's that one other install, where the curly quotes aren't showing up in view mode, that has me baffled. What's really weird with that one, is that when I click on edit, either in the admin, or in my front end data form, the typographic curly quotes display correctly. It's only in view mode that they turn into this (in the source), with the page charset set to UTF-8: â��testâ�� the above text should be: “test” (i.e. "test" with curly quotes) By the way, the particular field I'm testing is set to be textarea only -- no TinyMCE at all. => As a related item, the problematic database receives email from a variety of email programs, from both PCs and MACs, and then saves the data to PW. Thus, things like curly quotes could be coming from a variety of machines. My Processwire script to save those pages does not include any type of charset declaration or conversion, because I was under the impression that I didn't need to do that. But that might be another knowledge gap. The test I did above, however, was me pasting in the word "test", with curly quotes, from LibreOffice Writer, on a PC. Thanks for all the help! I do intend to one day answer some questions myself, when I become more proficient in PW. (Well, I have posted one Case Study, so far.) Peter
×
×
  • Create New...