Posts by chipbennett

4 posts
  • Exclusive Author
  • Has been a member for 2-3 years
chipbennett says

Sorry guys, but I thing that all of you are wrong. Should data be available to users after they switch a theme? No doubt. But is that a responsibility of theme developers? No.

If a Theme registers a custom post type, then it absolutely is the Theme developer’s responsibility to ensure that user data created using that CPT is available to the end user.

They register post types. They never unregister them.

End user statistics regarding Theme switching refute such an assertion. Theme developers must assume that any given Theme WILL be deactivated at some point, because the end user WILL switch to a different Theme at some point.

Just Wordpress is suffering from amnesia.

No; that’s how the PHP execution loop works.

Theme never offers access to custom post types…

Um, what…? If it is the Theme that registers the CPT , then what is it, if not the Theme, that “offers access” to that CPT ?

but WordPress handles the process of creating, updating and retriving post types…

No. It is not WordPress core that calls register_post_type(), but rather the Theme.

...so is its responsibility to keep doing so until custom post types are explicit unregistered.

When a CPT is registered via a Theme, then switching Themes is an explicit unregistering of that CPT .

So, solution lies in hands of WordPress developers. Make custom post type registration persistent and solve this issue not only for the future themes, but for older themes too,

WordPress already has a way for custom post types to be persistent through Theme activation and switching: register CPTs via Plugin, rather than via the Theme.

Your argument makes absolutely no sense, given the way PHP and the WordPress Plugin API works. If a Theme registers a custom post type, then when the Theme is deactivated, that CPT no longer gets registered during the execution loop. You’re only furthering the argument for not registering CPTs via Themes, but rather via Plugin.

About shortcodes. How they work? The writer types [column_one]...[/column_two], the Wordprress saves this in database, then the redear requests a post and Wordpress processes shortcode and serves results to the reader. After that, a second user makes the same request, Wordpress processes again shortcode. Waste of energy, bad for tropical forests. Why? Wouldn’t be more logical to do_shortocode before the post is saved and to save the result of shortcode, not the shortcode itself in the database? I know, there are shortcodes that produce dynamic output, like a list of latest posts. But in this case the user no longer edits a post, he/she becomes a developer and is editing a template. And if so, a proper tool should be provided to them.

That’s an argument to take up with the core WordPress developers. Otherwise, it is the responsibility of Theme developers to support core’s implementation of a given feature, including do_shortcode(). As it is, do_shortcode() is parsed at runtime, so Themes should be developed accordingly.

Your end users are far better served by developers who develop against what WordPress is, rather than those who develop against what the developer thinks WordPress should be.

4 posts
  • Exclusive Author
  • Has been a member for 2-3 years
chipbennett says


In my experience, most problems of the sort being discussed in this thread originate from using some custom code implementation rather than supporting WordPress core functionality. If you were properly using the WordPress Settings API , you’d have no need for using Base64 encoding in a custom options object.
Sometimes it’s better to read all settings in one call. Wordpress setting api sets individual options – asking from it 30 settings can look pretty heavy.

That one setting (actually, that one DB entry) can and should be an array of Theme options. If you, for whatever reason, need explicit type-casting, you can do it in the register_setting() sanitization callback.

Same thing with custom fields – If you need to display 10 posts and every post has 10 individual settings – I think is better if those 10 settings are placed inside a single post custom field.
I really like the options that wordpress gives by default, but sometimes you pretty much need to optimize the data reading actions.

Custom post meta data can also be retrieved as an array of key->value pairs, or as a single-key value. No need to reinvent that wheel, either.

4 posts
  • Exclusive Author
  • Has been a member for 2-3 years
chipbennett says


As for your specific example: Base64 encoding doesn’t belong in Theme PHP code, period. Base64 encoding is not necessary for implementing a Theme options export-import feature. Exporting/importing as plain text works just fine. (I’ll give the benefit of the doubt, and assume that you’re using best practices, by using the Settings API , and by having a single options array as a single WP_Options DB table entry? How difficult is it to export/import a single array?)

In my case it belongs. I am doing a serialization of an custom options object and I need this. Exported data is a plain text.

Why is this a problem?

Why do you need a custom options object?

In my experience, most problems of the sort being discussed in this thread originate from using some custom code implementation rather than supporting WordPress core functionality. If you were properly using the WordPress Settings API , you’d have no need for using Base64 encoding in a custom options object.

4 posts
  • Exclusive Author
  • Has been a member for 2-3 years
chipbennett says




Documentation in the Codex is great, but utilising tools like Theme-Check is good too, because as the plugin is updated, authors are automatically conforming to any new guidelines.
Theme-Check plugin is a joke.
Would you be able to explain why you think Theme-Check is a joke? Comments like that without qualification don’t add much to the discussion. We need to know the problem before we can find the solution.

You can’t rely on a simple regex text search to unveil the intentions of the theme code, can’t you? Thing is – code is much more complex than this. Therefore, this plugin can be considered as a joke, or a dumb tool.

You misunderstand the purpose and use of Theme Check. The results are returned with a criticality rating of “critical”, “required”, “recommended”, and “info”.

The results returned as “critical” or “required” are a NO-GO result. The Theme will be resolved as “not approved”. The results returned as “recommended” are informational for the Theme Developer, to consider for implementation. The results returned as “info” are for the Theme Reviewer, as items that may bear further, human scrutiny: in order to ascertain the developer’s intent, and thus determine appropriateness.

As for your specific example: Base64 encoding doesn’t belong in Theme PHP code, period. Base64 encoding is not necessary for implementing a Theme options export-import feature. Exporting/importing as plain text works just fine. (I’ll give the benefit of the doubt, and assume that you’re using best practices, by using the Settings API , and by having a single options array as a single WP_Options DB table entry? How difficult is it to export/import a single array?)

http://themeforest.net/forums/thread/timthumb-script-and-theme-check-plugin/48408?page=1#447753 http://themeforest.net/forums/thread/code-quality-on-themeforest-items/67178?page=7#594200 http://themeforest.net/forums/thread/cant-find-thumbsdb/73196?page=1#635811 http://themeforest.net/forums/thread/theme-check-infos-errors/67715?page=1#596061

TimThumb doesn’t belong in WordPress Themes, period. Use the WordPress core Post Thumbnails functionality. You’re doing your users a disservice by using TimThumb.

The last link demonstrates the point about how Theme Check is intended to be used. Those two “INFO” results would be flagged by the Theme Reviewer, to examine the code to see how IFRAME and hard-coded links are being used.

by
by
by
by
by
by