Namibia

@matbeuz: I had the same problem. I tried lots of manipulations to solve the problem. I am not sure which one finally worked. Try first editing the “wp-config.php” file in your root directory and deleting all the “define(‘WP_CACHE’…” lines.

This plug-in’s releases for the last few months have been a complete disaster. It’s as if the developers do no quality checks
themselves, and they let their end-users (including PRO users) do all the debugging. Shameful and unacceptable!

Thank you for your reply. Picturefill.WP 2 looks exactly like what I need. I didn’t know about the existence of this version 2, since it’s only on Github. Unfortunately, it doesn’t work on my server out-of-the-box. I get black pages on the frontend, and a series of PHP errors on the backend:

[13:21:42] PHP Fatal error:  Class 'DOMDocument' not found in /public_html/wp-content/plugins/picturefill/inc/class-picturefill-wp.php on line 109
[13:22:06] PHP Fatal error:  Class 'DOMDocument' not found in /public_html/wp-content/plugins/picturefill/inc/class-picturefill-wp.php on line 109

I will try to look into these errors when I find free time.

As per the highlight, unless you show me exactly what the problem is with the ‘hack’, I’m not planning to change it in the near feature.

There are performance penalties with JavaScript (freezes the browser for a few seconds), and compatibility issues (some users like to disable JavaScript alltogether). The other advantage of the PHP approach is to eventually implement your own excerpt-builder, centered around the found word. Because currently, the excerpt returned is always the beginning of the post: but let’s say this beginning represents one tenth (1/10) of the entire post. This means that 9 times out of 10 the excerpt does not contain the found word and is irrelevant to the search.

Of course, this requires a lot of work, which is why I was giving it as a suggestion for the “premium version”. The “free version” is great as it is, and I am very grateful that you’re providing it to us, and that you’re devoting your spare time to it.

Jan Dembowski already explained the downsides of the first method (the core files method). The second method (the translation method) doesn’t have downsides, because:

1. You don’t edit core files, just the .PO file.
2. The .PO file remains valid for future WordPress releases.

OK, here is the second and better way of specifying the font subset. The .PO translation file (and its corresponding .MO file) are found in:

/wp-content/languages/[your-language-code].po
/wp-content/languages/[your-language-code].mo

In your case, “vi.po” and “vi.mo” I suppose. Open “vi.po” with a text editor, and add at the end of the file:

#: wp-includes/script-loader.php:570
msgctxt "Open Sans font: add new subset (greek, cyrillic, vietnamese)"
msgid "no-subset"
msgstr "vietnamese"

Save the file in the text editor. Next, open the same file with the Poedit program (if you don’t have Poedit, download it from the Internet). Save the file (even though you haven’t made changes), so that Poedit automatically generates a corresponding .MO file. Upload “vi.po” and “vi.mo” to “/wp-content/languages/”.

OK, if you want a server-side solution, you can actually make Open Sans include the vietnamese font subset (by default, it’s not included, to save bandwith I suppose). You edit file:

/wp-includes/script-loader.php

And you replace line:

$subset = _x( 'no-subset', 'Open Sans font: add new subset (greek, cyrillic, vietnamese)' );

with:

$subset = 'vietnamese';

(There is a second and better way to specify the font subset. If you use a .PO translation file, you translate “no-subset” with “vietnamese”. This allows you to avoid editing the core files. But if you’ve never used .PO translation files, it might be hard for you.)

Browsers nowadays allow custom style sheets (to override the appearance of any website element). I don’t know what your browser is, but search on the internet for “custom style sheet <your browser>” and you’ll find how it’s done. Usually you create a .css file (a text file with a .css extension) and in the preferences of your browser you specify this .css file. (If you have trouble configuring your browser, you can even install a style sheet plug-in, like “Stylish” for Firefox and Chrome.) In your case, the custom style sheet should contain the following text:

.wp-admin #wpcontent {
    font-family: "Arial" !important;
}

Don’t forget to quit and reopen the browser so that the changes take effect.

@esmi: That’s exactly what we’re trying to solve. The website menu-bar is differently colored from the one in the dashboard.

Thank you for the clarification. Great plug-in, by the way!

To answer my own question,

Looking at the plug-in source code, JavaScript is only needed for the feature “Has the form already been submitted? If so, reset the form”. So for basic use, JavaScript is not needed. In fact, the programmer has provided a hidden switch to turn off JavaScript. You edit file:

/si-contact-form/includes/class-fscf-display.php

and you change $add_fscf_script from “true” to “false”.

Wow, thank you very much! You’re the most responsive plug-in creator out there!

I’ve been using this plug-in in a French environment almost since its creation, and I’ve never had encoding problems.