Note to self: The FB360 Encoder really wants its video files to be H.264 encoded and in mp4 containers.
Note to self: The FB360 Encoder really wants its video files to be H.264 encoded and in mp4 containers.
Turns out the problem I was having with everything except the front page was due to permalink rewrites not working. It seems three things were incorrectly setup.
First, the WordPress folder wasn’t writable by the www-user.
Secondly, this needed to be done:
You have to edit the Apache conf file (in Ubuntu 14.04: /etc/apache2/apache2.conf) and change the AllowOverride setting from None to FileInfo
<Directory /var/www/>
Options Indexes FollowSymLinks
AllowOverride FileInfo
Require all granted
</Directory>You may need to enable the Rewrite module:
sudo a2enmod rewrite
How to Show Comments on the Homepage of Your WordPress Theme
Quick note to self, since I will definitely wonder about this again. If I want to view my list of WordPress links as an OPML (i.e. wp-links-opml.php) and filter for a specific category, the way to do that is to add the ?link_cat=[category id]
suffix to the URL.
Yesterday I wrote about a problem that I’m having with a WordPress plugin that I’m working on, and I said that I think it’s a bug in WordPress. Here are some more information about it.
The plugin should cross-post/syndicate any new post to Twitter. There are a lot of plugins already that does this, but I wanted a few special features.
So far so good. This all works as intended. There is however one more thing that it’s supposed to do:
The plugin hooks into the publish_post action and early on in its code it checks if ( get_post_format( $ID ) == 'link' )
. If it returns true an XPath query retrieves the href of the first <a> element and uses this instead of the permalink in the Twitter post.
The XPath part works just fine in all my tests.
As long as I post from the WordPress Admin interface, everything works as intended. The problem occurs when I post using the Press This bookmarklet. When I post this way, if ( get_post_format( $ID ) == 'link' )
never returns true
, regardless of the post format.
If I create the post using Press This but instead of publishing I save it as a draft and then publish from the Admin panel, it works as intended.
If so, please let me know.
The code is available on GitHub but I’ve kept the repository private since I’m a little bit embraced by the code, but let me know if you’d like to check it out and I’ll add you to the repo.
I’m working on a WordPress plugin to syndicate my posts to Twitter. I know, there are lots of plugins that does that already but none of the ones I’ve found does it the way I want, so I decided to roll my own. I’ve got the basics working and have been using it on my site for quite some time now. However, I’ve encountered a problem. Here’s how I want it to work:
When I publish a link post, instead of posting a link back to my site to Twitter, it should post the link to the site that I’m linking to. The plugin ”knows” whether it’s a link post or not based on
1 2 |
if ( get_post_format( $ID ) == 'link' ) |
At first glance this works fine and it worked in development. However, ones I started using it on my site I realized that it only worked some of the times and other times it wouldn’t recognize a link post.
Tonight I’ve managed to narrow it down. It seems like the problem occurs when I post with the ”Press this” bookmarklet. If I do that, even a post that clearly has been givet the ”link” post format still returns false for if ( get_post_format( $ID ) == 'link' )
. If I post the exact same content using the WordPress dashboard the post is recognized as a link post and everything else works as intended.
Is this a bug in WordPress? I should investigate this further but right now I need to go to bed, so I’m throwing the question out to you, smart people on the internet, instead.
Christofer Vilander reposted this on twitter.com.
Henrik mentioned this on blog.henrikcarlsson.se.
This gets me every time I try to create a sharing extension for iOS. I follow along with the WWDC session ”Creating Extensions for iOS and OS X, Part 1” from 2014 and when I encounter this line, I get an error:
1 2 |
if ( [ itemProvider hasItemConformingToTypeIdentifier:( __bridge NSString *) kUTTypeImage ] ) { |
The problem is that kUTTypeImage
is unknown to Xcode. The solution is to import MobileCoreServices.framework
.
(For more on this, check out this StackOverflow thread.
Är det nån som känner till nåt problem med strlen i PHP och ”svenska” tecken? (å, ä, ö etc.) Verkar räkna fel.
@synvila Om det blandas ISO- och UTF8-kodade strängar/funktioner så kan du få spännande resultat. Kolla på mb_strlen().
@mikaeljorhult Tack, det ska jag göra. Lite förenklat så är det jag försöker göra:
strlen( $post->content );
i WP.
Wow, that’s an unwieldy title!
Anyway, during some spare time today I’ve struggled with something in Objective C and Cocoa Touch that I’ve been struggling with before. When a UITextField in an iOS app becomes ”active”, allowing the user to enter text, almost half of the screen gets covered by the software keyboard. That’s all well and good, but that keyboard is likely to obstruct the view of something, maybe even of the UITextField in question and that’s not good.
To avoid this problem, I the developer am supposed to move or resize (or something) the view. There are multiple questions about this on StackOverflow and multiple answers. After some digging and a lot of trial and error I came up with a solution that differed at least somewhat from all other solutions that I could find. As far as I can tell my solution works and it’s pretty short in terms of code, which I like.
I don’t know, maybe it’s a bad solution. If so, please let me know.
First, embed all the views that need to move inside a UIScrollView.
In my case I have multiple UITextFields that needs to move so I placed them all inside a UIScrollView. I then added the following property to my ViewController:
1 2 |
@property (strong, nonatomic) UITextField *activeTextField; |
This property is updated on textFieldShouldBeginEditing
like so:
1 2 3 4 5 |
- (BOOL)textFieldShouldBeginEditing:(UITextField *)textField { self.activeTextField = textField; return true; } |
Then , in my viewDidLoad
I added the following two observers:
1 2 3 |
[ [ NSNotificationCenter defaultCenter ] addObserver:self selector:@selector( keyboardDidShow: ) name:UIKeyboardDidShowNotification object:nil ]; [ [ NSNotificationCenter defaultCenter ] addObserver:self selector:@selector( keyboardDidHide ) name:UIKeyboardDidHideNotification object:nil ]; |
These will trigger the methods keyboardDidShow
and keyboardDidHide
when the keyboard appears and disappears respectively. It is in those methods that ”the magic” happens:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
- (void)keyboardDidShow:( NSNotification *)notification { // Find out the frame of the keyboard NSDictionary *userInfo = [notification userInfo]; CGRect keyboardFrame = [[userInfo objectForKey:UIKeyboardFrameEndUserInfoKey] CGRectValue]; // Calculate how heigh of an available content area we have now by // subtracting the keyboards height from the height of the main view. NSInteger heightOfAvailableContentArea = self.view.frame.size.height - keyboardFrame.size.height; // Make a point with a y that's the y of the activeTextField minus half // the height of the available content area and then scroll the // UIScrollView to this position. CGPoint scrollPoint = CGPointMake( 0, self.activeTextField.frame.origin.y - heightOfAvailableContentArea / 2 ); [ self.scrollView setContentOffset:scrollPoint animated:YES ]; } - (void)keyboardDidHide { // Return the UIScrollView to 0 position. CGPoint scrollPoint = CGPointMake( 0, 0 ); [ self.scrollView setContentOffset:scrollPoint animated:YES ]; } |
As I said, this works but it’s very possible that it’s a bad solution. If you like the solution, feel free to use it. If you think it’s bad, please tell me so and why so that I can learn and become a better programmer.
Today I started working on a WordPress plugin (I’ll tell you more about it soon). To do that I needed to brush up a bit on my plugin-writing skills. I’ve always found making WordPress plugins unnecessary frustrating but as I searched for some articles about it today I found this:
Since WordPress 2.8, building widgets has been a matter of extending WordPress’ own widget class, WP_Widget, resulting in your custom widget only having to focus on 4 main functions:
- Initialisation (__construct) – handles actions to take when the widget is first created such as enqueueing specific javascript or stylesheets in the output
- Front-end display (widget) – handles the generation of the widget’s HTML output
- Back-end form (form) – handles the generation of the form controls that make up the widgets edit interface in the Admin interface
- Update (update) – handles the form submission from the back-end form, updating stored data as necessary
I had completely missed this. In my mind plugins was still this boiler-plate filled bag of hurt. Instead all you got to do is subclassing WP_Widget and replacing a couple of methods. Wow!
As I took the approach suggested in the article and based my code on the sample code in it, I got up and running super-quick. A beta version of the plugin is actually running on my local machine already, after maybe an hours worth of work. The fact that it was so easy makes me very happy and gives me the urge to write more plugins.
Replies and comments
WordPress Digest
12 november, 2016 16:53WordPress Digest reposted this on twitter.com.
Michael McGinn
12 november, 2016 17:27RT: @synvila-Some more information on the WordPress bug that I think that I’ve found #wordpress blog.henrikcarlsson.se/2016/11/some-m… #waptug 41211
Mikael Jorhult
12 november, 2016 21:53Haft besök hela dagen men ska se om jag inte kan bläddra igenom koden. Vill minnas att jag stött på ett liknande problem tidigare.
Mikael Jorhult
12 november, 2016 22:39Fungerar koden via Press This om det är något annat Post Format? Typ image?
Henrik Carlsson
12 november, 2016 23:07Testade samtliga post formats nu och oavsett vilket jag väljer så returnerar get_post_format() en tom sträng via Press This.
Mikael Jorhult
12 november, 2016 23:14Även om du använder dig av $post->ID istället för $ID? Sneglat i core och Post Formats ska fungera med Press This.
Henrik Carlsson
12 november, 2016 23:25Det fungerar så tillvida att inläggen som publiceras får rätt post format. Det är bara det att det inte verkar vara satt i