php
Sidebar featured images only on single post pages
After updating to WordPress 6.x and updating my theme (Clean Black based) and then merging the customizations back in with meld (yes, I really should do a child theme but this is a pretty simple theme so meld is fine), I didn’t really like the way the post thumbnails are shown, prefering to keep it to the right. I mean clean black was last updated in 2014 and while it still works fine, but that was a while ago. Plus I had hand-coded a theme sometime in the naughties and wanted to more or less keep it while taking advantage of some of the responsive features introduced about then.
Pretty much any question one might have, someone has asked it before, and I found some reasonable solutions, some more complex than others. There’s a reasonable 3 modification solution that works by creating another sidebar.php file (different name, same function) that gets called by single.php (and not the main page) that has the modification you want, but that seemed unnecessarily complicated. I settled on a conditional test is_singular
which works to limit the get_the_post_thumbnail
call to where I wanted and not to invoke it elsewhere. A few of the other options on the same stackexchange thread didn’t work for me, your install may be different. What I settled on (including a map call for geo-tagged posts) is:
<div id="sidebar"> <?php if (is_singular('post') ) { echo get_the_post_thumbnail( $post->ID, 'thumbnail'); echo GeoMashup::map('height=150&width=300&zoom=5&add_overview_control=false&add_map_type_control=false&add_map_control=false'); } ?> <div class="widgetarea"> <ul id="sidebarwidgeted"> <?php if (!dynamic_sidebar('Sidebar Top') ) : ?> <?php endif; ?> </ul> </div> </div>
And I get what i was looking for, a graphical anchor at the top of the single post (but not pages) for the less purely lexically inclined that didn’t clutter the home page or other renderings with a wee bit o php.
Getting the postfixadmin 3.2 update to work with FreeBSD
Postfixadmin is a very nice tool for managing a mail server via a nice web interface that just went through an update to add some security and compatibility features, but at the current revision there are a few bugs (the maintainer says these will all be cleared up in the next release). A few work-arounds:
If you get:
pkg-static: Unable to access file /var/ports/usr/ports/mail/postfixadmin/work/stage/usr/local/share/postfixadmin/README.md:No such file or directory
Then run
# make config
and enable DOCS.
If you get
PHP Fatal error: Uncaught exception 'PharException' with message 'phar "/usr/local/www/postfixadmin/lib/random_compat.phar" openssl signature could not be verified: openssl not loaded' in /usr/local/www/postfixadmin/lib/random_compat.phar:8\nStack trace:\n#0 /usr/local/www/postfixadmin/lib/random_compat.phar(8): Phar::webPhar(NULL, 'index.php')\n#1 /usr/local/www/postfixadmin/common.php(72): require_once('/usr/local/www/...')\n#2 /usr/local/www/postfixadmin/public/common.php(2): require_once('/usr/local/www/...')\n#3 /usr/local/www/postfixadmin/public/setup.php(27): require_once('/usr/local/www/...')\n#4 {main}\n thrown in /usr/local/www/postfixadmin/lib/random_compat.phar on line 8
There’s a dependency that’s not built into the makefile yet.
Run
# portmaster security/php56-openssl
(adjust the PHP version to match, or the install command to suit your environment). Remember to run # apachectl restart
.
Also note that the directory the code is served from has been moved to the subdirectory /public for security. This may require updating URLs, DocumentRoot, or modrewrite as appropriate to the webserver environment to get to the login page.
After updating, navigate to public/upgrade.php to update the database automatically.
And because this is open source and not some horrible closed source product, it took a whole 2 hours for a fix.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231424
Thanks ports.maintainer@evilphi.com!
PHP Startup: Unable to load memcache.so
I noticed the warning
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/20090626/memcache.so' - /usr/local/lib/php/20090626/memcache.so: Undefined symbol "php_session_create_id" in Unknown on line 0
in my apache logs. Googling for it, some sites suggested that old php.in
files might the cause. But this is a pretty fresh install so I looked a little further and found a nerdstock note describing a similar problem. I checked my /usr/local/etc/php/extensions.ini
and finding that extension=session.so
came after extension=memcache.so
I moved it to the top of the file and the errors went away.
PHP default Lat Lon
Odd choice for the default lat/lon in php.ini
http://maps.google.com/maps?q=31.7667+35.2333+&hl=en&ll=31.766696,35.233305&spn=0.007799,0.007832&t=h&z=17
Postie Image Resize Seems Broken
I updated Postie for the first time in many years, and it seems my fix for ImageMagick is now obsolete, but another fix may be necessary.
It may be that Postie just doesn’t like the FreeBSD environment. The ImageMagick fix was mostly to point Postie’s hard-coded targets to BSD standard locations. This time through I haven’t found the right code yet as postie-functions.php has been completely rewritten.
A week of tweets: 2010-06-06
- 2 cars, 2 busses, 2 trains, 2 planes, and 23 hours to Santa Monica. #
- Fight the Cert Mafia! Visit https://www.cacert.org/index.php?id=3 with IE Ignore warns Click Class 1 Root PEM Choose install as trusted root #
- Coming home with some flotilla people. #
- Live, from SFO #
- Yum, It’s Tops with @semb & @bendybutterfly & @phragments #
Table Edit in Mediawiki
I just installed Ecoli Hub’s TableEdit into MediaWiki.
It went moderately smoothly, except the update_schema.php script failed to prefix the tables, which meant that MediaWiki couldn’t find them. It took me a little poking around to figure out what was happening, but I got an error that brtext_TableEdit_box couldn’t be found. Now an unfortunate prefix choice in that it looked to me a bit like br text… as opposed to brtExt, but once I figured that out I was on the way to a little editing with phpMyAdmin and everything worked.
TableEdit is a step in the right direction for interactive table editing, what I’d consider the biggest weakness of wiki’s at this point. It seems most of the information I’d put in a wiki would be more efficiently formatted as tables, and as a result I have lots of non-interactive spreadsheets; something that gets confusing on frequently updated, collaboratively edited text. WebDAV might be a solution for that, and maybe OpenOffice will get “open via sFTP” as an option soon, but until then EcoliHub’s solution is a step forward, though what I still really want is a viably speedy version of Dan Bricklin’s wikicalc.
Fixing ImageMagick resize in Postie
I noticed that postie was doing a terrible job at resizing images.
It turns out that the default GD library isn’t super good at resizing – it does a simple subsample and the result is quite jaggy (see the GD version of this image in this post)
I think the version above looks a lot better. It should have been as easy as just turning on the “use ImageMagick
” function in the postie config, but it wasn’t that simple. Two files were not where they were expected to be. The easy one is “convert
” which postie expects to find at /usr/bin/convert
, but under BSD is actually at /usr/local/bin/convert
. This isn’t a big deal as there’s a config option to point postie in the right direction. A bit harder is ImageMagick identify which postie expects to find at /usr/bin/identify
, but for which there is no config entry.
The fix for BSD is to edit around line 1768 of postie-functions.php and change /usr/bin/identify
to /usr/local/bin/identify
before the first run or by resetting postie to defaults. If you’ve already installed postie and don’t want to reset the defaults you may need to edit the postie config database (I did) using, for example, PHPMyAdmin and set the value of IMAGEMAGICK_IDENTIFY to /usr/local/bin/identify
.
And thus one gets nice, pretty postie thumbnails.