Core Dev Team Meetup Q&A

• Will we ever get a term meta table? This could be particularly useful for plugin/theme developers to add extra features on term archives. For example, an SEO plugin might allow users to input a custom title for category archives. Or, a theme developer might develop user-selectable custom templates for tag archives. One could always throw all this in the options table, but it doesn’t really seem like an ideal solution.
• I mentioned this in the 2011 discussion, but I’d really love to see sidebars handled like nav menus. Particularly, themes should be able to register “theme locations” and have users assign custom-created sidebars to these locations. It would definitely solve the losing widgets when switching themes issue in an elegant way.
• Post-to-post relationships?
• Finish custom post statuses (#12706)?
• Custom comment types API?

Will there be a development path that leads to a reduction in the amount of style sheets that can be called upon on load in WordPress?

I know you min the style sheets to combine as many into one but it still seems to be a lot of over head that unnecessarily can bog a site down and cause the web master more work than necessary to achieve page speed.

It would be nice if there were only 2 style sheets. 1 for the theme and one for all plugins to use. A new plugin would automatically get assigned it’s values to the plugin style sheet which maybe can be kept track of via database tag.

If plugin removed, database tag is drop entries of the plugin stye sheet is dropped. Something like that. It seems that if there was a core way to handle this then it would reduce the amount of extra plugins needed to achieve performance.

Please don’t get me wrong, they are very good plugins. The WordPress core runs blazing fast, but it doesn’t take to long for it to slow down to snail pace because of the functionality that is desired from plugins or themes.

If this would be address I think it would allow one common solve an issue that can cause a lot of extra work. It is not WordPress in itself that is the issue, but the extra.

I know you have to use common sense when plugins are used, but still a lot of time is used when adding those functions that the client might want and to move it along faster you use the plugins. Never ending circle.

I’m agree with Jeff Sebring’s question.

DVCS

From a social standpoint I think moving to WordPress to a DVCS would improve the plugin/theme experiences and user contributions. Github is more a social experience then strictly a repository. Moving WordPress into this revision style would be a nice step forward ( not necessarily git, I’m also a huge fan of mercurial).

So when ?:)

Media API

More developer love in the form of a Media API. Media (photos, video, etc) rules the web, and WordPress could certainly handle it much better, it is currently a pita.

Also when? ??

Some social improvements to www.ads-software.com itself, the idea that someone had (otto?) of plugin/theme developers working on the same project through an online social interface ( have a look at Cloud9 IDE formally from Mozilla). It’s time WordPress brought developer tools into a stronger social network.
Some thoughts would be nice on this subject, I think this was brought up at WordCamp Sf.

I guess my overall question would be: What is WordPress doing to integrate more social tools aimed at developers?

In the past year, we’ve seen a lot of plugins (or reusable snippets of code) that allow users to register custom fields/metaboxes and/or custom option pages, either via database or code. One of the main debates surrounding these plugins (and themes that implement them) is the lack of consistency in the UI that these different implementations have.

I (and many others) believe it would be beneficial to have a single UI that can be used and reused by plugins and themes.

What are (if any) the plans to implement core features to easily register custom metaboxes and options?

What other core features need to be added as WordPress embraces more CMS functionality? How about a GUI for Custom Posts and creating views for these such as:
https://wp-types.com/ Flexible ways to create and display content/data seem to be at the core of this.

At a higher level than individual features, I’d love to hear what the team’s vision is for WordPress in their ideal world; specifically, what will WordPress and its ecosystem look like 1, 2 and 3 years from now?

At many of the WordCamps this summer (culminating in WCSF) there was much talk of using responsive design techniques in the admin interface. How have the responsive design efforts in the 3.3 dev cycle changed or influenced this vision?

In addition to supporting very large screens, what about smaller screens? Do you see the admin interface scaling down to phones to give the full power of WordPress on-the-go, or are the relatively simple mobile apps going to have to stick around for the foreseeable future?

Some of the wording presented to users is not very professional. For example, wp-signup.php has ‘so create to your heart’s content, but write responsibly!’ and ‘Now have at it!’

ms-delete-site.php also has ‘Happy trails to you until we meet again.’

It’d be nice to have hooks to change the wording for these without hacking core.

I would like to see videos accompanying with the WordPress core themes (such as twenteleven or twentytwelve theme video) showing how WordPress Themes was created so that other (new) developers will have ideas on how (easily) create their own framework…

I think it will be beneficial to have video(s) from WordPress Team explaining how TwentyTwelve theme was created, logic behind its functionality, why its option pages was chosen that way, how TwentyTwelve parent theme was set up so that it could work with any child theme, etc… Thank you in advance.

It’s been over 2 years since we last saw a code update to videopress. Are we just plain stuck with what is there now, or are we going to get updates to bring us more in line with what the videopress site itself uses?

Also like many others, would love to see some major improvements to media in general in WordPress.

Will you or will you not implement a MULTILINGUAL core solution in a near future ?

You know how many WordPress users will be bothered by the extra bytes but what you do not know is how many people are waiting for this to happen in order to start using WordPress.

Will you or will you not make it easy to manage the media library by ordering it into intuitive files (eg. /post_name/media.jpeg) ?

Thanks for your answer.

CMS feature requests:
* multilingual

• provide multilingual support as a core plugin
• theme localization should not draw from backend localization file (separate completely)
• no hardcoded entries

* media

• media handling: organize files in folders with different access rights (file manager)
• search for / sort by file types / formats
• assign unique IDs to all files / entries (in the DB, no hotlinking for internal links to posts & pages)
• css from gallery thumbnail borders is hardcoded
• multiple galleries on one page or post

• always visible page tree for better page handling

BTW: Thanx for your hard work!

Please : just 3 things please :

1) A Google Plus or Facebook Like or WordPress.com Like Equivalent that can be used across all www.ads-software.com sites && that can be implemented by other sites for an individual site

2) Drupal Equivalent of CCK and Views, the two absent things for which we still need to use Drupal for some use cases

3) Seamless integration of WordPress activity stream in Buddypress : for example, comment from bp stream to a blog &/or comment in a blog that shows up in a stream

Last but not the least : remove all traces of FB and Twitter : they do not use you/your icon/piggyback on you/whatever … you got the point : Be unique!
Contrary to what u believe, this will actually get u more users ??

What specific accessibility topics are on the WP roadmap?
There’s https://make.www.ads-software.com/accessibility/ where people can discuss accessibility issues, but how much is getting major attention from the decision makers for new releases? How are these things being prioritized?

One tiny thing with a big impact would be to have the alt text field be mandatory – not title! – when you are uploading pictures. There could be a little UI snippet to help users know what to write – or a link to a good page of information.

If the core sets accessibility standards, maybe it can be a role model for all the add-ons and plug-ins people create.

how much is getting major attention from the decision makers for new releases?

Unlike other aspects of development, accessibility isn’t binary (black or white – right or wrong). https://make.www.ads-software.com/accessibility/ isn’t simply for discussion. It’s intended to allow those with the right skills to prioritise and refine accessibility issues so that these can then be presented to the core team as specific recommendations rather than vague requests.

One tiny thing with a big impact would be to have the alt text field be mandatory

Over my dead body! Are you serious? It is considered best practice to use a null alt text for decorative images – not a populated one. And there’s no way that any UI can automate an alt description – or even decide if an image should have one or not. This is way outside the remit of an UI. It can only be addressed by educating users.