Now I’m developing themes for wordpress and I noticed how bad it is in front of anchor when we’re talking about themes development. I could bring you plenty of examples to prove what I’m saying. Let’s start with the “comment form” function: why the developer who’s creating a theme must be forced to use the wordpress markup?
You aren’t, WordPress provides default markup, but you don’t have to use it. The input var names on the other hand are necessary for obvious reasons else the form won’t work, and a lot of the markup you dislike is merely the default value of several options you can pass into the comment form function being called.
I put this down to a lack of knowledge
Another example is when you have to retrieve the comments of a post… just incredible the way I’m forced to get those data, with all that bloated markup
There’s more than one way to do things, you could have total control if you did it this way:
$args = array(
// args here
);
// The Query
$comments_query = new WP_Comment_Query;
$comments = $comments_query->query( $args );
// Comment Loop
if ( $comments ) {
foreach ( $comments as $comment ) {
echo '<p>' . $comment->comment_content . '</p>';
}
} else {
echo 'No comments found.';
}
Not every API is low level, some are higher level functions for people who aren’t strong developers, or to save time with defaults, some are there for historic reasons and backwards compatability, etc
and also when you have to get the thumbnail of a post and WordPress instead of giving you the url of that image, returns with a whole img tag to use.
No, there is a function that does this, the_post_thumbnail, but perhaps you would get better results using get_post_thumbnail_id to find the post ID of the attachment that represents the thumbnail, and wp_get_attachment_url:
$featured_image = get_post_thumbnail_id( get_the_id() );
$url = wp_get_attachment_url( $featured_image );
echo '<img src="'.$url.'"/>
The funny comes when you have to adapt that markup to your needs and you have to pass configuration parameters (like arrays) to the functions. I see these things like a patch on a patch on a patch and honestly these are things that lead the developers to be incredibly constrained to the “rules”.
Perhaps you should use a lower level API, some of the higher level APIs that do a lot of things, and don’t require basic knowledge of how data is stored do have a lot of parameters for things like markup, e.g. wp_list_categories, etc, it sounds like you’d be better off using the lower level APIs such as the term/taxonomy classes/functions
All the things you’re suggesting WordPress do, already exist. There’s no 1 single way to do something in WordPress, each way is optimal for a different level of knowledge and use case.