Prototype iPhone apps with simple HTML, CSS and JS components.
Plugins are pretty popular, since it is easy to adjust your blog or website to your liking with Plugins. Less popular are Dropins.
WordPress alows to replace some functions with Dropins. The list of possibilities isn't big and not well documented. But I like to use Dropins to enhance the possibilties of caching, especially APC and Memcache. But also to adjust uploads, permalinks and similar things are a typical scenario for Dropins.
Most of the Plugins are in the WP Content Folder, normally
wp-content or via constant
WP_CONTENT_DIR or the URL in
WP_CONTENT_URL is defined.
// Custom content directory define( 'WP_CONTENT_DIR', dirname( __FILE__ ) . '/wp-content' ); define( 'WP_CONTENT_URL', 'http://' . $_SERVER['HTTP_HOST'] . '/wp-content' );
I use this in my dev environment or at my clients project for example, since I can access Plugins via FTP in different ways. See my WordPress Starter Repo on Github for more solutions and hints about this topic.
Only Dropins, which get loaded with a language key, aren't in this folder, instead they are in
/wp-content/languages. Alternatively you can define the folder via the constant
The Dropin for the German key de_DE takes that path. See the repo for read the source or find more information.
In Backend are Dropins listed since version 3.0, but only the following in the table and not the Dropin to the language key. Also you can not just deactivate or activate it via backend, that's why Plugins are preferred for some solutions.
Below is a table with all Dropins I know or I have found. The possible Dropins are echoing via the function
|File||Type of Dropin||Active since||Context|
||Advanced or Alternative Cache||Constant
||Own database class||Always||Single installation|
||Own database error alert||At DB Error||Single installation|
||Own installation routine||At installation||Single installation|
||Own maintenance message||At updates, maintenance||Single installation|
||External Object Cache||Always||Single installation|
||Before the WP Multisite Installation gets loaded||If constant
||Own message, when a blog gets deleted||If a blog gets deleted||Multisite installation|
||Own message, if a blog is set inactive||If a blog becomes inactive||Multisite installation|
||Own message, if a blog got suspended||When a blog gets marked as archive or spam||Multisite installation|
||functions at active language key||When language key set in constant
||Single & multisite installation|
Update: see the current solution for a custom maintenance mode on the post from Christopher.
© WP Engineer Team, All rights reserved (Digital Fingerprint: WPEngineer-be0254ce2b4972feb4b9cb72034a092d)
Apple recently changed its developer guidelines to indicate that it might not be so happy with apps that essentially replicate what the App Store already provides, in terms of providing lists of apps to buy. But another change in iOS 6 pointed out by a developer contact suggests that Apple definitely does want to encourage developers to help it sell mobile software: a new object available developers allows apps to display other items on the App Store, including other apps, for purchase directly.
From the Overview of SKStoreProductView Controller Class Reference, part of the iOS Developer Library:
A SKStoreProductViewController object presents a store that allows the user to purchase other media from the App Store. For example, your app might display the store to allow the user to purchase another app.
At the very least, this means Apple isn’t going to blanket ban apps that promote other apps for sale or download in the App Store. But this capability, which resembles the newly added option of making iTunes music and media available for sale in-app as well, doesn’t negate the fact that Apple seems to also want to ensure that customers aren’t confused about the difference between the App Store and software which essentially presents an app marketplace within the App Store to highlight certain content.
In the end, apps that promote quality App Store content, or link out to other apps from a user’s favorite developer and provide direct purchase access are a smart, organic way to promote App Store growth and help surface good stuff for iOS users. So it makes sense that Apple would make that even easier. But with great power comes great responsibility, which is likely why Apple introduced the guideline I wrote about yesterday alongside this powerful new direct selling ability, which you can bet will be looked at closely by Apple’s App Store submission review team.
For the last month or so I’ve been working on a patch to move the “stripslashes” functionality from the WordPress “model” API functions to the “controller” code (where it belongs). This change will mean that you don’t have to call
add_magic_quotes() around your data when passing it to
wp_insert_user(), etc. As hardly any developers know to do this anyway, we can pretty much consider this “fixing a bug” (which is how this patch approaches the change).
I talked this over with a few different core developers at WordCamp SF this year, and I’m very hopeful that we can land this in 3.5. Check out the ticket on Trac (#21767) to see examples and a bit more detail. Help testing and identifying any edge cases I may have missed is very much appreciated.
Having visited WordCamp UK over the weekend of the 14th and 15th of July in Edinburgh one of the talks spurred me on into thinking about my development environment and how I could improve it. The talk in question was “Totally Custom Theme Development” and was a panel discussion on how we develop themes etc. for clients.
Steve Taylor, Jonny Allbut and Rachel McCollin chaired the panel although there was a lot of audience contribution to the discussions. Essentially it came down to how we add common functionality to our themes. Most of use tend to use a theme to start with that is the same, and will contain a bunch of code that enables certain things in your site. Therefore the debate was had around either putting all this into a plugin or using a parent theme.
Previous to the debate I have used a start theme which I had developed over time. I then changed and altered this theme according to the site that I was building at the time. Jonny pointed out that this is often not the best way of doing things because if you wanted to update some of the functionality that you have in the starter theme it would mean updating all the sites that we built using that manually. Jonny’s workflow was to use a parent theme, in his case the Wonderflux theme framework and then build child themes off of that. That way if you starter functionality changes (in this case the parent theme) you need only to update each parent theme of all your sites. This works although still requires manual uploading of the parent theme on every site. The reason for this is that because the parent or starter theme is not in the WordPress theme repository then the auto update feature is not available.
This got me thinking about whether or not you could make themes (and plugins for that matter) auto update and get the updated version from another location rather than the WordPress theme repository. Then I thought about premium plugins such as Gravity Forms. These plugins are not in the WordPress plugin repository because you have to pay for them, however they still allow auto updates.
At this point I started searching the web for the solution to this problem and how to get themes auto updating from a set location. This is when I came across this Github project from Jeremy Clark. Jeremy has developed a handy chunk of code to do precisely this.
The instructions are very clear and having implemented this I can now host my own theme updates. When I make an update available on my server all of the sites that are using that theme as a parent theme will see the update in the WordPress dashboard and therefore they can auto update to take advantage of the new functionality or bug fixes. As long as the sites are running child themes then they should work just fine.
I am going to give this a go in my next project and see if it works as a development work flow. I have never been a fan of parent and child themes as my child theme always end up with lots of files that will not get updated when the parent theme is updated and therefore ruining the very idea of parent and child themes. Time will tell I suppose and I will blog again with my thoughts on the outcome.
Since we announced MyBB 1.8 back in April work towards making a public beta has been slow. This time of year is traditionally the busiest for the team members with exams, workloads and personal projects – not to the mention most of us enjoying the summer (or lack of, in some cases!) – often taking over from our usual MyBB duties. Where we were once working on the code every day there has been weeks without anything being done at all. This is, unfortunately, the perils of volunteer work.
We know you’re all just as excited about MyBB 1.8 as we are, and we haven’t told you everything that is changing yet, so we’re stepping it up a gear to put it all together as fast as we can without compromising our new features. We’ve tried setting deadlines (and failing miserably) and I know you’re sick of the usual ready-when-it’s-ready story so all I can say is please bear with us. We’ll be working hard to bring you this feature update and that starts with our move to GitHub.
Part of the fallout from when MyBB.com was partly taken over was to have an overview look at how we do things behind the scenes to see if we could improve our services. This understandably has a knock-on effect on our development; we decided it was best to drop SVN and move to GitHub ahead of the 1.8 schedule. MyBB 1.6 development also happens over there too.
We’ve briefly hidden the 1.6 repository so that our team can get used to this new service and for us to sort out some new standards for developers and contributors to follow. This is a pretty big change not only for users but for our team as well so we need to take some time to get used to it too.
That being said, we haven’t quite got rid of everything. We will still be using the development site – powered by Redmine – as the central place to report bugs and issues with MyBB and the Merge System. It is up and running but we are having a few problems syncing the repository on GitHub and our local copy here. We hope to have this – and the GitHub project – up and running soon.
Consistency in 1.8
A general trait that has been hanging over 1.8 during planning and early development is consistency; making sure everything we do looks and feels the same as though it is from the same product, system and service. Everything from MyBB.com to the install process on your own forums will be getting a makeover to the new upgraded style giving MyBB in general a clean modern look. We’ve replaced the popular FamFamFam icons with the equally popular Fugue icon set to give 1.8′s UX (user experience) a fresh appeal – meaning 1.8 uses CSS buttons and carries PNG icons instead of GIFs. We’re looking into providing sprite images too for the ever-conscious large forum owner as well as providing theme artists a new opportunity with this style of coding.
Alongside the jQuery update and base colours, 1.8 themes are sure to be some of the best in the series.
Full Feature Update
So, as you might have thought by now, MyBB 1.8 is going to be a bigger update than most people imagined. While not 2.0-esque, it will certainly provide a full feature update that will require careful planning and action. And, to settle the nerves of the plugin developers, there will be no major updates to the plugin system – meaning for the majority only the compatibility section of your plugins will need updated for them work in 1.8.
By providing an update like this we hope to extend the life of the 1.x series while also providing the tools and processes for developers to create even more amazing themes and plugins. It also gives us, as a team, a chance to rebalance our own structure to provide a better product for you all to enjoy.
Analyzing jQuery usage among the top sites
While we did the research for this post, we also looked at how popular jQuery is among the top 1,000 and top 100 websites in the world, to give some added perspective.
Want a bigger chart? Here it is.
The jQuery usage among the top 100 sites would probably be a bit higher if Google weren’t behind such a big portion of them. Google owns one in five of the top 100 sites, and those sites don’t use jQuery. This in all likelihood skews the number a bit.
Big sites that use jQuery
There are literally thousands of big sites that use jQuery, but a few examples are in order. So, here is a selection of some of the world’s biggest sites, all using jQuery:
WordPress.com, Pinterest, Reddit, MSN.com, WordPress.org, Amazon, Yandex, Microsoft.com, GO.com, Ask.com, ESPN, Craigslist, About.com, Go Daddy, Stack Overflow, Huffington Post, Instagram, Slideshare, Fox News, The Guardian, Etsy, LiveJournal, Weather.com and many, many more.
The most popular CDN for jQuery
Both Google, Microsoft and Media Temple have generously provided CDNs (content delivery networks) that site owners can freely use when they include jQuery on their sites. Site owners can of course elect to host the script(s) themselves as well.
So which jQuery hosting option is the most popular? Some additional analysis gave us the following result.
Larger version available here.
It should be mentioned that there is a certain amount of overlap in CDN usage. Almost half of the sites that use Microsoft’s CDN also use Google’s, for example.
It appears that the Google Ajax API CDN is by far the most popular CDN among web developers. A full 25.4% of sites that use jQuery include the script from Google’s CDN.
The other two CDNs listed on jQuery’s site don’t even come close. There are 35 times as many sites using Google’s CDN as Microsoft’s. Media Temple’s jQuery CDN doesn’t fare much better; 23 times as many sites use Google’s CDN. Google’s dominance is quite complete here.
That said, the majority of the sites with jQuery don’t use any of these three CDNs. Either they are using a different CDN, or host it themselves (the latter being more likely for most sites).
JQuery is in excellent health. It has powerful backers and contributors and a lively developer community. The popularity of jQuery has kept growing over the years, and deservedly so. We are proud to be one of the project sponsors.
We hope to revisit this post a year or so from now. Where do you think jQuery adoption will be by then? Judging by these numbers, it certainly isn’t likely to go down anytime soon.
Methodology: We downloaded the HTML code for the top 10k websites in the world, according to Alexa (on June 19, 2012), and scanned for any variation of jQuery script inclusion. We only tested the homepages, i.e. the initial page you get when you visit a site.
This was a post from the guys at Pingdom, a site monitoring service that makes sure you're the first to know when your site is down. Check it out for free.
Facebook today announced new security features for mobile devices, allowing users to confirm logins made from new devices, report unwanted content from their mobile feed, and more easily recover compromised accounts.
The social network updated its login approvals process to make it easier for Android users to authorize logins that are made on new devices. With the new “Code Generator,” users will be able to receive login approval codes from their Facebook app rather than having to wait for a text message. This is an improvement over the previous system, which didn’t work if a user did not have cellular or Internet access. Android users can turn on Code Generator here. Facebook says it is working to bring this functionality to other devices.
Users of Facebook’s touch-enabled mobile site will now be able to hide or report content from News Feed. This is done by tapping the feedback icon beneath a story and tapping the icon in the upper right hand corner. Facebook says it is working to bring this feature to native mobile apps as well.
The social network has also brought its account recovery tool, which was previously only available on desktop, to mobile devices. Users can review unauthorized logins, reset their password, and take other actions to regain control of their accounts from their phones. See Facebook’s note here for more details.
FBML apps are set to stop working today as part of the removal of Facebook Markup Language. Facebook also announced that it will remove the live stream plugin from the platform in favor of the comments box.
Some old page tab applications and very early canvas games that have not been migrated to the new format will have “FBML Removal” migration enabled today. It will be possible for developers to disable the migration and re-enable FBML until July 5, when FBML will be removed completely.
The shift away from FBML has been a long process for Facebook. The social network began recommending iFrames over FBML for canvas applications in 2008. The company further moved away from FBML in August 2010, when it decided to allow page tab applications to use iFrames rather than its own markup language. FBML was useful for some page owners who didn’t have much programming experience because it used uniform code snippets. However, iFrames allow developers to build both canvas and tab applications on the same programming model, and integrate more functionality through social plugins and the Graph API.
Beginning in March 2011, page admins were no longer be able to install new FMBL apps and developers were no longer be able to create them. Recently, Facebook has provided weekly reminders about the upcoming change through posts on its developer blog. More details about the removal here.
As for the live stream plugin, Facebook says it will be removed on Sept. 5 and replaced by the comments box plugin. The live stream plugin is a real-time chat widget that was released publicly in 2009. It had been used for apps and websites supporting live-streaming video, webinars, massively multiplayer games and other live events. Although the comments box allows users to log in with Facebook and add comments to a page, it does not support real-time updates. Users have to refresh a page to see new comments, which makes it less ideal for real-time events and conversations. Facebook also notes that live stream allowed publishers to have multiple plugins on the same page, but the comments box can only be used once per page. More details about the migration here.
Other breaking changes are discussed in Facebook’s latest developer blog post.
We’ve made quite a bit of improvements over the past few weeks. Although a lot of the changes are behind the scenes or fixing regressions, there are some exciting user facing changes, as detailed below! We’ve also been working with our Google Summer of Code 2012 student, wnayes, quite a bit to get him up to speed of how things work in Instantbird. He’s made great progress on understanding the code and has even fixed a bug (see the “top protocols” page, below)!
- The account wizard now has a “top protocols” page to allow users to quickly set up accounts that are most applicable to them. This is localizable as different instant messaging networks are popular in different regions.
- Tab Completion improvements:
- Names of people who have pinged you (i.e. said your name in the chat).
- Names of active participants.
- Names of inactive participants.
- IRC contacts (yes, you can add IRC nicks to your contacts list!) now have tooltips which show the results of a WHOIS command.
- Better support for tracking if a nick is online/away/offline.
- The topic UI now reflects whether you have permission to edit it.
Google Summer of Code Status:
To follow along with what wnayes will be working on this summer, you can read his blog (RSS feed) and check out his user repository. Additionally, he’s posted some general information (his application, timeline and a series of links) that he’ll be updating as the summer continues. (And of course you can stop by our IRC channel, #instantbird on irc.mozilla.org, and say “Hi!”)