Add an image to a post, type in a caption and set alignment to ’None’.
I’d expect the captioned image to be left-aligned with the main content column’s left, in line with <p>elements.
The image is left-aligned to the left edge of the screen. My attachment is a screenshot of a post with one uncaptioned and one captioned alignnone image.
All right, thanks for the response. As I said, the shortcode approach works just fine so I’ll have to stick with that, and create my own custom post type if/when necessary.
The description page clearly says the plugin features a ”Gallery custom post type”, but for the life of me I cannot figure out how to publish or even preview those posts. I can add galleries and use the short link on other post types, but the editor for galleries has no ”preview” functionality and there’s no way to view gallery posts on the front end on their own. I’d expect to be able to view the galleries at /(gallery_post_type_slug)/(gallery_post_slug).
Looking at the custom post type code (includes/class-posttypes.php), the ’public’ and ’rewrite’ args to register_post_type() have been set to false, which according to Codex documentation causes what I’m seeing. The args variable has a filter so I could override it; does this imply that I’m intended to add a filter to have the galleries work as a viewable post type and not just something used behind the scenes by the plugin?
Reading from the Codex page linked to, I think the value of ’field’ in the tax_query array should be ’term_id’ rather than ’id’: ”Possible values are ’term_id’, ’name’ and ’slug’. Default value is ’term_id’.” I’m guessing ’id’ only works because it causes a fall-back to the default.
Preventing ownership changes is not a filesystem/Access Control Lists feature, it’s a UNIX feature designed to prevent bad things from happening.
I suppose you could give the wordpress user the permission to chown via sudoers if you really wanted to, but I would question the reasons for trying to do this in the first place.
Hi,
I’m getting this entry in my server log when I open the latest post in single-post view:
Trying to get property of non-object in [...]/wp-content/themes/cover/inc/template-tags.php on line 61
It looks like the reference to $next->ID on said line is causing this; there’s no next post from the newest, obviously. There is a test for ! $next && ! $previous on line 51, but I’m guessing the block generating$next_img_array for next_post_link should also be wrapped with a separate test for the existence of$next, to suppress the error.
I would highly recommend Daniel’s much simpler solution over the one currently selected as correct:
$user = get_userdata( $user_id );
if ( $user == false ) {
//user id does not exist
} else {
//user id exists
}WordPress antaa säätää kommentoitavuuden postauskohtaisesti, eli jos julkaisit tuon ennen kuin olit ruksannut mainitsemasi valikkokohdan, siinä julkaistussa on vielä vanhan asetuksen myötä kommentointi suljettu (tuon yleisasetuksen muuttaminen ei vaikuta vanhojen postausten kommentoitavuuteen). Postausten muokkausnäkymässä, ylälaidassa on (suomenkielisessä wp.comissa) ”Näyttöasetukset”-namiska, jolla saa muokkauskilkkeitä piiloon ja näkyviin. Yksi niistä on ”Keskustelu”, jolla sen postauskohtaisen kommentoitavuusasetuksen (”Salli kommentointi”) saa näkyviin, jollei se jo ole.
— wp-status-net.php 2012-07-16 20:51:15.604960940 +0300
+++ wp-status-net.php.new 2012-08-01 21:04:36.392944461 +0300
@@ -700,7 +700,7 @@
function wpstatusnet_options()
{
- if ( 'save' == $_REQUEST['action'] )
+ if ( array_key_exists('action', $_REQUEST) && 'save' == $_REQUEST['action'] )
{
$options = array(
"apitype" => $_REQUEST[apitype],
@@ -931,7 +931,7 @@
{
if (function_exists('add_options_page'))
{
- add_options_page('WP-Status.net', 'WP-Status.net', 0, basename(__FILE__), 'wpstatusnet_options');
+ add_options_page('WP-Status.net', 'WP-Status.net', 'manage_options', basename(__FILE__), 'wpstatusnet_options');
}
}If your theme has a searchform.php, you’re probably hitting Ticket #16541: get_search_form() ignores $echo if searchform.php exists.
Your workaround is fine if you’re just echoing the search form anyway, but if you need to capture the output in a variable, you can work around this with output buffering:
<?php ob_start();
get_search_form();
$my_search_form = ob_get_clean(); ?>