At time of writing, Spotify doesn’t provide a track’s artwork via its API.
So, I’ve written a simple function to get the image; but please note, not only is it quick and dirty, but it’s horribly inefficient and should be used sparingly — at the very least, make sure you cache the results somewhere!
You can access a public-facing web-page about a particular track using the following URL:
…where [TRACK-ID] is the last part of the track’s URI — so for example, for the track represented by the URIspotify:track:5fpizYGbi5IQoEraj6FP0R, the track ID would be 5fpizYGbi5IQoEraj6FP0R, and thus the URL to the page would be:
Just a quick one, but it’s something that I got stuck with for a while.
If you try and use Laravel’s pagination class with JQuery Masonry along with Infinite Scroll, you may find a problem. When you scroll down beyond what should be the last page, you’ll probably find that you keep getting the last page over and and over again, causing genuinely infinite scrolling. The reason for this took me some uncovering.
When Inifinite Scroll requests an additional page, it increments the page number, but gets the same content back — however, there is no reason why it should know that that’s the case. It’s because it keeps getting new content back that it keeps trying, but the issue is actually in the Laravel Paginator.
I haven’t blogged for a while, but I have been writing. I recently wrote an article for PHP Master (part of the Sitepoint family) on geolocation, called Targetted Geolocation with Geonames.
The article looks at how you can use a RESTlike web service called Geonames to take a user’s location and resolve it to a place name. In the article, I use the example of providing a prompt urging the user to go check out the cinema listings in their local town, whatever that happens to be.
I’m currently writing another geo-based article for the same publication, as well as some other articles for here and elsewhere — stay tuned!
If, like me, you often develop on a Windows platform and then host using a *Nix-based server, Concrete5 has a gotcha which will probably hit you when you come to publish your site. At some point no doubt you’ll reach the point where you’ve copied the codebase to your server, created a database dump and imported it into the MySQL instance on your *Nix-based server. Try browsing to your site at this point, though, and you’ll get a message a lot like this:
Fatal error: Uncaught exception 'ADODB_Exception' with message 'mysql error: [1146: Table 'mysite.Config' doesn't exist] in EXECUTE("select * from Config where uID = 0 order by cfKey asc") ' in /var/www/mysite/htdocs/concrete/libraries/3rdparty/adodb/adodb-exceptions.inc.php:78 Stack trace: #0 /var/www/mysite/htdocs/concrete/libraries/3rdparty/adodb/adodb.inc.php(1037): adodb_throw('mysql', 'EXECUTE', 1146, 'Table 'mysite...', 'select * from C...', false, Object(ADODB_mysql)) #1 /var/www/mysite/htdocs/concrete/libraries/3rdparty/adodb/adodb.inc.php(1012): ADOConnection->_Execute('select * from C...', false) #2 /var/www/mysite/htdocs/concrete/libraries/database.php(75): ADOConnection->Execute('select * from C...') #3 /var/www/mysite/htdocs/concrete/models/config.php(151): Database->__call('Execute', Array) #4 /var/www/mysite/htdocs/concrete/models/config.php(151): Database->Execute('select * from C...') #5 /var/www/mysite in /var/www/mysite/htdocs/concrete/libraries/3rdparty/adodb/adodb-exceptions.inc.php on line 78
Drupal 7’s block module can be a little limited in its permissions; “Administer Blocks” is a rather sweeping capability, and often it’s useful to be able to make it that bit more granular. For example, you may have a number of blocks throughout the site but once they have been placed in the correct region and the visibility correctly configured (which often isn’t the simplest of processes), you don’t want content managers to change those settings. You do, however, need to allow them to change the title as it appears to site visitors, and of course the content. This isn’t possible out-of-the-box; luckily, it’s not that hard to do. Inspired by kiamlaluno’s post on Drupal Answers along these lines, I’ve knocked up a simple module to make permissions granular enough for just a situation. It’s incredibly simple and somewhat limited, but it does enable to you to grant or deny access to each part of a block’s configuration, i.e.:
Having played around with Less for a while, I’m quite taken with it. Especially with useful tools such as Twitter’s newly released Bootstrap being optimised to work with it. Less works with CSS to provide all sorts of neat features such as variables, nested rules, functions and “mixins”, which means less code, and easier to maintain code. So, for example, instead of doing this each time you want a rounded corner:
One of Drupal’s weaknesses, I feel, is that out-of-the-box usability for administrators is a little poor (the Drupal team themselves would probably agree with me, however this is something that’s now being addressed in a big way). There are, however, plenty of ways to make the experience better through a set of Drupal modules which I’ll be covering in this post. However before even thinking about modules, it’s important you have a good admin theme — and there are a few good options. Rootcandy is a perennial favourite, and comes in three flavours; standard, fixed (i.e. a fixed width) and dark.
I’ve just spent hours trying to get an install profile to work, which was giving me this error:
**Fatal error: Call to undefined function db\_result() in [site\_root]/includes/path.inc on line 54**
Google helped to an extent; the problem, it seemed, cropped up with a number of installation profiles and it’s during the execution of hook_profile_modules() that it appears. The most common cause, it seemed, was to do with the JQuery UI module, and in particular the link to the library itself, which you have to download separately. I had no such problem, however — thanks to a couple of lines in my (Dush) make file it had already been downloaded, and removing JQuery Ui from the list of modules to install didn’t fix it. Nor did excluding date_api, another module with which this problem can occur. In the end I had to go through each of the modules I wanted my installation profile to enable for me — a lot of them — systematically in order to find the culprit. The culprit, it turns out, was robotstxt. Hope this is of some help to someone — I’ve wasted hours of today! (I should point out, by the way, that this probably isn’t the fault of the module in question!)
As has been commented elsewhere, when you’re programmatically inserting data the most reliable way of doing so is often to simulate form submission — that way, any validation rules are applied and other modules have a chance to intercept the submission to do what they need to with the data. This was achieved using the function drupal_execute:
drupal_execute has gone altogether from Drupal 7. Instead, you need simply replace any call to drupal_execute with the new function drupal_form_submit (see the documentation). Otherwise, everything (from the point of view of your syntax) remains the same. Don’t forget to use form_get_errors() to ensure that the form has validated.
One of the nice, lesser-known features of Drupal 7 is the ability to use additional databases and switch at ease. This might be useful for external databases, or if you have another database in an alternative format — perhaps you have an SQLite database that for performance reasons, you don’t wish to migrate. (Yes, Drupal 7 now supports SQLite!) The configuration can be a little confusing at first, so let’s look at a settings.php file set up to use two databases: drupal on Localhost, and db2 situated at db.example.com.