Forum Replies Created

Viewing 7 replies - 1 through 7 (of 7 total)
  • Okay, I think I’ve got a good ‘work-around/bug-fix’ [firefox seems to be interpreting the atom+xml mime type definition a bit differently than I — and they are probably right, considering the definition is written gobbledeegook]

    Anyway, the patch — edit the file ‘includes/default-filters.php’

    Near the bottom, you will see a section like this:

    // RSS filters
    add_filter('the_title_rss', 'strip_tags');
    add_filter('the_title_rss', 'ent2ncr', 8);
    add_filter('the_content_rss', 'ent2ncr', 8);
    add_filter('the_excerpt_rss', 'convert_chars');
    add_filter('the_excerpt_rss', 'ent2ncr', 8);
    add_filter('comment_author_rss', 'ent2ncr', 8);
    add_filter('comment_text_rss', 'htmlspecialchars');
    add_filter('comment_text_rss', 'ent2ncr', 8);
    add_filter('bloginfo_rss', 'ent2ncr', 8);
    add_filter('the_author', 'ent2ncr', 8);

    Add:

    add_filter('the_category_rss', 'ent2ncr', 8);

    (and make sure to reload your ‘live’ firefox bookmark — open the bookmark menu, and right-click on the entry for your feed)

    The problem is with firefox —

    I downloaded your feed to my computer (you can do this by going to /feed/atom/ on your site), and when I look at it directly in firefox, I get an error —

    XML Parsing Error: undefined entity
    Location: file:///home/geoff/var/downloads/ax1gnxga
    Line Number 44, Column 15: <dc:subject>V&aring;rvinter vid Tjol&ouml;holms slott</dc:subject>

    specifically — the <b>&aring;</b> ‘å’ is not recognized by firefox. And yes, it should be!

    So first, you can complain to the firefox development team.

    But in the meanwhile, the question becomes — is there some way of not using entities when they represent valid UTF-8 characters. And the answer is…I dont know, but I doubt it.

    good point ?? And glad i could help!

    Perhaps they would enable phpsuexec for you? (with the understanding that you would not complain to them if things weren’t working — other users would not be able to run it, unless they specifically enabled it)

    np!

    Is 775 secure? No, not very at all — consider for a moment the file ‘wp-config.php’. The one that holds your database password…it should (ideally) to 600, so that not even apache can read it (if apache can read it, then [maybe] other users can too)

    I’ve recently signed on to dreamhost.com (two weeks ago — not long enough to vouch for their service, but long enough to vouch for their offering). They run phpsuexec, and have WordPress one-click-install, and more (MUCH MUCH more).

    https://wiki.dreamhost.com/
    https://discussion.dreamhost.com/

    (forums — so you can see the good AND the bad)

    On the other hand, customer service seems vital (for the sake of your client) — and if podz can vouch for that, you might just want to go with site5.

    PS: (if you DO decide to sign up [with dreamhost], you might want to know about their affilate program. It uses promotional codes, the “enter this code when you sign up and get $50 off” You can spot them in some signatures on the discussion board)

    No, and yes —

    No, its 755 or lower IF your server is running phpsuexec. Otherwise, the server cannot write to the directory. The server runs as ‘nobody’ or ‘www’ or ‘apache’ or some such — not ‘root’ and not your uid. If the directory is set to the same group as the server, and group-writable, then the server can write to it.

    Yes, it is *much* more secure to use phpsuexec (assuming you are on shared hosting) By making a directory 775, other users might(could) be able to write to it, via *their* cgi scripts.

    Most ISP’s batton down what they can (php for example, can be restricted), and most people who pay for hosting are not going to go hacking, given that they are known by the hosting company. But still….

    EDIT: (realized i was talking too much ‘geek’, so will add a touch of clarification, for any reader who is confused by chmod)

    In the number, say, 750, the first ‘7’ applies to the user, the middle number (‘5’) applies to a group of users [each user belongs to one or more groups], and the last number (‘0’) applies to everyone else.

    The numbers themselves are formed by adding:

    +1 == execute (or access a directory)
    +2 == write
    +4 == read

    So, 750 means the owner can read/write/execute, anyone in the file’s group can read/execute, and everyone else is out of luck

    755? Shouldn’t that be 775? (assuming, that is, the directories in question are gid ‘www’ or ‘apache’ or whatever)

Viewing 7 replies - 1 through 7 (of 7 total)