• Hi folks,
    Is it intentional that static pages in 1.3a5 cannot have custom fields? Among other side effects, this prevents RunPHP from flagging a static page as containing PHP code.
    It would be helpful if PHP code could be executed from static pages — for example to enable a publisher to provide a page with links to all RSS feeds available in all three formats using wp_list_cats…
    Just wondering!
    Greg

Viewing 9 replies - 1 through 9 (of 9 total)
  • I don’t know about the custom fields, but my static pages use RunPHP jsut fine. I use it in my About page to get the post and comment numbers and in my Colophon to get the PHP version.

    Thread Starter GregM

    (@gregm)

    Hi ColdForged,
    Well that’s pretty weird…
    I’m not even sure where to start to trouble-shoot why it isn’t happening on my example page — but the source returned by the server is still full of PHP tags, even though ‘eval’ has been checked on the static page creation page. I wonder was your static page created with an earlier version, or with 1.3a5?
    Thanks,
    Greg

    Thread Starter GregM

    (@gregm)

    Hi ColdForged,
    Looking at it again, I see that wp_texturize (presumably) is utterly and completely botching my included PHP code anyway — turning the entire page into a complete mess. Of course, I could switch this ‘helpful’ feature off with any of a number of different plugins — however, that again requires being able to specify a custom field so the plugin will know to switch off the evil interference from wp_texturize.
    So, back to the original question: is it intentional that static pages can’t have user-specified custom fields?
    Many thanks,
    Greg

    Thread Starter GregM

    (@gregm)

    The plot thickens……………..
    After more testing, I’ve found that code is getting botched even with Alex King’s ‘Unformatted’ plugin enabled, so it’s not wp_texturize that’s responsible for completely nuking the code…
    Moreover, I’ve also found that there are at least 3 different versions of ‘Run PHP’, written by 3 different people — and the version I’m using (James Van Lommel) turns out to have trouble handling almost all examples of PHP I’ve tested it with *except* for permalinks embedded in anchor tags (which was the job I originally wanted Run PHP for)…
    So, more questions for ColdForged or anyone else out there using (some variety of) Run PHP with static pages under 1.3a5: *which* Run PHP are you using? What sort of PHP are you successfully getting eval-ed?
    Thanks again, and Happy Weekend,
    Greg

    I wonder was your static page created with an earlier version, or with 1.3a5?

    True catch there, mine were created under 1.3a4.
    wptexturize() may indeed be a culprit. I tend to have Textile 2 doing my post massaging, so that may be the difference. Please note that I am not doing the double-equals “turn off Textile processing” around my PHP invocations on those pages, though. It may be from the ordering of my add_filter() calls… Textile 2 is being added as a 6 on the_content whereas RunPHP adds itself as a 5.
    Maybe this helps?

    Also I just looked in my database and while there might not be an interface for adding custom fields to the static pages, they are still created if needed. For the aforementioned static pages that use RunPHP, I have the appropriate custom fields in the database.

    Thread Starter GregM

    (@gregm)

    Hi ColdForged,
    Hmmmm……..
    The fact that the code you supplied doesn’t work either is interesting: much like the other examples I had tried, a space is getting inserted between the initial less than sign and the question mark, and it’s all down hill from there — no eval.
    I haven’t been using any additional post massaging, but the really weird thing is that the space is getting inserted even when the ‘WP Unformatted’ plugin is enabled and the relevant custom field is set to 1 (in an ordinary page, rather than a static page). So WP is STILL getting to my post text and fiddling with the code, even with a plugin set to prevent that.
    I’m befuddled… Perhaps I’ll trying enabling Textile 2 to see if I can duplicate your success with your example code…
    Oh, one last question: would you be able to say any more about the ordering of add_filter calls? I can see these being declared in the plugins, but I don’t know what they do (and couldn’t find any mention of add_filter in the wiki). Could switching these numbers around a bit improve the chances of one thing not messing with another?
    Thanks very much, ColdForged. I’m away for the night for now (I’m in the UK) but shall try again tomorrow…
    Thanks again,
    Greg

    Thread Starter GregM

    (@gregm)

    ColdForged — Unbelievable!!!!
    I would have sworn that I shut this off days ago, but when I checked again tonight at your suggestion, Presto! There it was, enabled.
    I switched it off, and your code works, my code works, static pages work, and all is well!!!
    Thank you so much for persevering with all my questions. I probably would never have thought to go back and check that setting, but now that I have everything works precisely as I’d hoped!
    All the best,
    Greg

    That’s great news, Greg! Glad I could help.

Viewing 9 replies - 1 through 9 (of 9 total)
  • The topic ‘No custom fields for static pages?’ is closed to new replies.