Once topics have been covered they will appear here to allow the conversation to continue.
Some people like child themes. I’m not one of them.
Given that responsive design is pretty much a necessity these days, I tried some of the boilerplate themes as starting points, and none of them seemed quite right. Roots was good but over-complicated. I’ve cut it into something that works for me, but I’m convinced there is more that can be done.
And finally, a way to replace the ”Sample Page” that gets pre-populated with a collection of more useful content and pre-selected page templates and menus.
It would be really interesting to hear what other devs use as the ”starting point” and what they feel could be improved.
Spam and ham are a nightmare on any site. WordPress is specifically targeted and high traffic site suffer even more. Akismet is great for comments, but what about registrations, particularly if you are exposing profiles on the front end.
CAPTCHA is pretty much illegible and a massive user barrier.
These are some tools I have used in the past: Akismet, Cloudflare, BuddyPress Humanity, Stop Spammer Registrations, New User Approve.
It would be interesting to hear from others and see if there is the possibility of making something better.
I’m currently in the process of building a WordPress site that will be internationalised for several languages.
I’m already using WordPress’ built in __(); and _e(); functions for anything that isn’t editable in the CMS, I was wondering if there were any other things to look out for, or best practices to follow.
We’ll be using Multisite with domain mapping to serve the various languages to different territories, but are there any other solutions out there that handle i18n better.
Having so many others who had worked on i18n WordPress was great and made me consider a few things I hadn’t considered. Luckily I wasn’t going to far wrong, I had prepared some slides but arrived late so went with the markerboard instead.
Everything I had learnt so far was from the WordPress Codex page which is a great place to start.
Essentially all you have to do is wrap any strings you want to be available for i10n in the WordPress functions:
__('Returns hello world', 'my-namespace'); _e('Echoes hello world', 'my-namespace'); _x('Context', 'Gives a translator some context to the string, to differentiate between a noun or verb for example', 'my-namespace'); _n('Single', 'Plural', 3, 'my-namespace');
You then run your theme or plugin through a tool that generates a
.pot file that in turn can be used by a translator to generate a
.mo file for each language. WordPress offers a tool to do this, but I couldn’t get it working so used an online tool instead.
One thing I hadn’t considered was the slugs of Custom Post Types, but luckily you can use the
slug parameter when you register them.
When I came to actually translating strings I found you need to create a
languages dir in
wp-content that contains an
.mo file of the language you want to use, it doesn’t have to contain anything, but as soon as you put one there WordPress will give you the option to use that language.
Not sure what to call this but I want to share a problem I have when building most WordPress sites for my clients:
Many of my clients have new CPT’s created E.G.
- News (When using Posts as a blog)
- People / Staff
With each custom post type there is an archive page and for example the structure would be setup like so:
With each single post structured as:
The problems I have with providing the above in WordPress:
- How do I provide a menu structure that works with the above?
- If I’m using wp_nav_menu() or wp_list_pages() how do I get these structures to show?
- What about adding the right classes to the menu items such as current-menu-item, current-page-item, current-page-parent etc…?
- How do you show a breadcrumb trail that works?
- Make it simple for our clients, make it so they cannot break what has been set-up.
- Allow an easy way in the future to change the location of all the CPTs.
I have methods to achieve most of the above already but I’m not convinced it is ideal. I want to share my findings and see how others are dealing with the above and discuss on methods on making it easier.
Something that I’ve found hard to understand due to the lack of documentation is what custom post types’ rewrite rules, rewrite tags, and endpoints actually are. What are they, how can they be used, how should they be used?
This would need to be at an advanced level of custom post type use, beyond the basics. Calling Dr. Post Types…
As we’ve seen how well the WordPress menu system is now I’d like to see if we could come up with something just as valuable for Widgets.
It would be great to be able to easily create and manage widget areas in such a way that users could add, remove and manage them so they can used in themes and inline in content.
The end-game would be for it to eventually be adopted into core
I’m going to be doing a talk soon at WP London meetup, an intro to using Git with WordPress projects. This topic may not make it into that talk as I’ll try and keep it simple, but it’s something I’ve not tackled myself. I have plugins on GitHub that are also on the WP repo, and obviously it might be good to get some automated integration going on. I think Mark Jaquith has covered this to an extent but I’m curious if anyone else is doing this, and how.
I have a method already of doing this but I know it can be done better and would love an opportunity to discuss with you all to see how you would do this.
So giving more info on what I mean:
Lets say I have a custom post type called properties. Each property has a title (property name), post content (the property description), a number of custom meta fields storing price, bathrooms and bedrooms and a custom taxonomy storing the property location area.
The above is a cut down but I wanted to keep it simple for our discussion.
Now I can set-up the CPT using `archive => true` and set the rewrite `slug => ‘properties’` and that will allow me to navigate to `/properties` and see 10 of the latest posts (default WordPress behaviour). How do I now build my search that allows a user to:
- Order the properties by date ASC/DESC
- Order the properties by price ASC/DESC
- Order the properties by name ASC/DESC
- Filter the properties by price range E.G. £100,000 – £250,000
- Filter the properties by bathroom/bedroom range
- Filter the properties by area
The results should always show on the same archive page `/properties` and the users search must be maintained between page loads so that pagination works (using sessions).
The optimal solution I would say would be to alter the main archive query using the action `pre_get_posts`, remember my talk on You Don’t Know Query?
However looking for some really clever ways of achieving this.
If this topic gets picked for wp-hooked I will code up the CPT, meta boxes to capture property data, the custom taxonomy, the property archive page with layout and fill with sample data. The rest of the functionality will be then open to the group.
Thank you for reading.
WordPress’s datamodel is incredibly flexible and appropriate for a lot of content but not ALL content. I’d like to discuss the edge cases and in particular I’d like to talk about:
1. What are the cases or patterns for extending the datamodel?
2. What are the tell-tale rules of thumb that point to a need to consider bespoke tables?
3. Finally, what is the best way to extend? Are there design-patterns worth following?
Update post meetup
Thanks to everyone for participating in the discussion around Database Extension Tables. Here are the notes from our session along with some design notes that I came up with to describe a possible solution to this. I am very keen on finding a core group who might be interested in helping me develop this in an open source fashion. If you think you’d have bandwidth to do this please let me know. Ken
Sometimes I find it difficult to find out what is happening when writing plugins. This is particularly true when using the install / uninstall features of plugin activation / deactivation.
At the moment I tend to use the PHP mail() function to send debug code or to log when certain methods are used in the plugins.
There must be a better way of debug plugins or logging when things are happening.
This might also be great for working with and to log payment information. It would be great for all plugins to share a similar workflow / set of methods.
Notes from the meeting
The discussion of the debug idea involved lots of interesting ideas and it seems like lots of people have similar experiences.
The most common way is to add or into the code to create breakpoints whilst running the code. Speaking of break points, if a fully fledged IDE is being used (e.g. Zend Studio, Eclipse or Komodo IDE ).
Some useful plugins mentioned:
WordPress Hook Sniffer ( http://wordpress.org/extend/plugins/wordpress-hook-sniffer/ )
Although this was last updated in December 2010 it’s stil a great way of getting a better understanding of what’s going on behind the scenes of WordPress
Debug bar ( http://wordpress.org/extend/plugins/debug-bar/ )
Log deprecated notices ( http://wordpress.org/extend/plugins/log-deprecated-notices/ )
WordPress.org has a section on Coding standards, this can help to ensure that the code is properly formate to ease with maintanence. Chris Adams has a repo on github to help check coding standards within WordPress projects.
In relation to debugging plugins and themes, DXW demonstrated their PHP server specificially setup for working with WordPress. If you are running PHP 5.4 it would be worth the time looking at Whippet.
For more information in debugging in WordPress see the Codex page on WordPress.org.