Jump to content

Search the Community

Showing results for tags 'utf8'.

  • 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 3 results

  1. Hey Procis, wrote this - and my very first - hook „Prepend date in page name“, yesterday. Once you get it, this system and the API is magnificent. Thank you @ryan and @all contributers! On new (news) pages it works great so far. E.g.: Title: Testnews mit Ümläüten Altered page name: 2024-09-24-testnews-mit-ümläüten But on existing pages special characters are removed. E.g. Title: Partnerschaftliche Unterstützung - Ihr werdet gesucht! Altered page name: 2023-07-27-fans1991-partnerschaftliche-untersttzung-ihr-werdet-gesucht Another example is attached. There you can see, that the ProcessPageEdit-message shows the right path!? I have this in my site/config.php to allow only german special characters: $config->pageNameCharset = 'UTF8'; $config->pageNameWhitelist = '-_abcdefghijklmnopqrstuvwxyz0123456789äöüß'; Temporary uninstalled Module „PagePathHistory“ with no look. The code of my hook (suggestions for improvement are very welcome!): /* NEWS pages only: prepend date in page-name */ $wire->addHookAfter('Pages::saveReady', function($event) { // get current Page object — in this case this is the first argument for the $event object $page = $event->arguments(0); // Only for pages with news template if($page->template == 'news') { // Test if field day exists, otherwise exit if (!$page->template->hasField('day')) { $event->message("Field 'day' is missing!"); return; } $title = $page->get('title'); // Sanitize title and substitute special characters $optimizedTitle = wire('sanitizer')->pageNameUTF8($title); //$optimizedTitle = wire('sanitizer')->pageName($title, Sanitizer::okUTF8); // or translate option $date = wireDate('Y-m-d', $page->day); // Set output formatting state off, for page manipulation $page->of(false); $page->name = $date.'-'.$optimizedTitle; //$page->save('name'); $event->message("New saved name is $page->name"); //$event->message("Path of new saved page is $page->path"); } }); Any idea why this doesn't works on all existing news, too? Thx and 👋 Sebastian
  2. MySQL's utf8 encoding can only represent a tiny (though useful) subset of the full 31-bit range of Unicode; it's not UTF-8 at all. To fix what never should've been broken, they came up with utf8mb4. It's "of course" (i.e. UTF-8 is some properly designed piece of stuff) upwards compatible with the broken utf8 type. Well, not exactly, but more on that later. Would it be possible to default to the real UTF-8 type, when available? (MySQL 5.5.3+) (even wp did it! nudge nudge) And here comes that "later" you've all been waiting for. This important(ish) change would require the noble sacrifice of cutting some of the core (YES, CORE!) fields down to 250 characters to satisfy MySQL's sad-pathetic-deplorable limitation on index sizes. I know, that's 5 precious characters lost, but think about all those suffering emojis and suddenly you'll feel all fuzzy and warm, right? Anw, just a suggestion, because i18n and l10n and all the like. Edit: It seems a cruel RFC took away much of UTF-8's expressive beauty, and it is now valid only up to 4-byte lengths and values of 0x10FFFF, whichever smaller; I'm gonna go and cry myself to sleep now, goodbye.
  3. Hi, I have had some (more) trouble to get started with PW :-( In my php.ini the default_charset was set to 'ISO-88591' or something similar. So, as the DB uses utf8 and the pages are delivered in utf8, php is required to use it too. If not you can run into errors when try to save strings with e.g. german umlaute: äöü ÄÖÜ Incorrect string value: '\xFCchte ...' for column 'data' at row 1 I'm not sure if this was checked with the install routine, but I have seen only green lines Maybe this could be done to avoid some hassle to users with a setup other than utf8. Or it maybe an option to add "ini_set('default_charset','utf8');" somewhere at the top of index.php, and to be very very sure (also for paranoics like me ) one can set and check it: ini_set('default_charset','utf8'); $php_use_utf8 = strtolower(trim(ini_get('default_charset')))=='utf8' ? true : false; Ok, now I can start try out that wonderful CMS
×
×
  • Create New...