Suggest Agenda Items for Apr 8th 2010 dev chat
Recent comments
newtonsongbird on Suggestions Kim Parsell on Core Contributor Handbook Lance Willett on We’re getting very close… Muhammad Abdi on Core Contributor Handbook Maor Chasen on We’re getting very close…
Peter Westwood 8:47 am on April 4, 2010 Permalink
String freeze date for 3.0
Otto 6:04 pm on April 6, 2010 Permalink
Is there any plan to make the Woo menu system not so restrictive? Right now, it appears that all a menu item can possibly be is a name with a static URL. If my URL changes, my menu is now broken. If I add a new Page, it’s not reflected automatically in my menu.
Why so limiting? Why make a menu able to call a callback function? Why is this not more like Widgets, where I can make a “Page” menu item and then configure it to automatically show it’s children as sub-menu items, and then put this in my menu?
The menus idea is very, very cool, but this implementation is extremely disappointing. I was thinking it would be something totally better, like sidebar widgets, but for menus.
That might be worth some discussion.
demetris 9:39 am on April 8, 2010 Permalink
If there is interest, I have a few thougths about Twenty Ten I would like to suggest for discussion:
http://core.trac.wordpress.org/ticket/12902
Peter Westwood 8:21 pm on April 8, 2010 Permalink
In future could you create separate tickets for separate issues.
One ticket which lumps together a lot of suggestions is hard to manage.
Andrew Nacin 1:28 pm on April 8, 2010 Permalink
I have spoken with Dion, jjj, and others about issues that arise when we force /blog on the root blog of a new MS subdirectory install. Say I’ve had a blog on WP for a long while, and now 3.0 comes out, I upgrade, and I decide to move to MS. So I upgrade with subdirectories, and I find that most or all of my old links on my main blog are now broken, because I have /blog forcibly prepended to my permastruct.
This is a huge problem, and in my opinion a blocker. I’ve previously only thought about it so far in the context of existing MU installs, or fresh 3.0 installs.
I again cannot make the meetup, maybe I can be in by 5pm eastern, but I think this should be discussed. (jjj says he will be there.) There are a few things we can do to fix this:
1. We can give them a big warning in network.php. (jjj: “Ohai! Noticed you may nuke your site; here’s a suggestion.”)
2. Proper redirection to the new /blog URLs, which is more or less impossible for cases when MS catches the URL first.
3. Actually implement a way to rid /blog. That means confirming that the path requested is a blog instead of assuming so in ms-settings.php (line 70) by querying wp_blogs. That means page slugs cannot clash, that category and tag bases cannot clash, etc. We would need a unique_site_slug function, and if the person has %postname% as a permalink, that could work okay, but unique_post_slug will need to confirm it is a unique site slug for is_main_site(). Someone may not be allowed to register if the slug conflicts with an existing root blog page, I’d think. And in network.php, we should identify problem permalink setups. And there’s probably a lot I haven’t thought about yet.
Yes, I know it is by design, but this will be seen as a major architectural flaw once 3.0 is out and MU gets introduced to the masses, whether we hide it with WP_ALLOW_MULTISITE or not.
John James Jacoby 1:55 pm on April 8, 2010 Permalink
+1 to wp_unique_site_slug function.
Anything that could potentially be a root conflict needs a method to do a slug check. Even user_nicenames may want a pass-through, for situations like where profiles.wordpress.org uses BuddyPress but skips the ‘/members’ root slug. If my nicename is “hootie” and there’s a page named “hootie” on the root blog, and I want my own blog named “hootie,” right now it’s all possible without a cross-check.
WordPress core needs to be smart enough to detect a slug conflict and prevent it in a real way. At the very least, it needs to stop a poor, unsuspecting tinkerer from blowing their right leg off without some kind of warning that the gun is loaded and the safety is off.
John James Jacoby 1:57 pm on April 8, 2010 Permalink
For back compat, I think prepending ‘/blog’ to the root site should also be a site option with a nice p.description that explains why they might want to turn it on or off.