hey @Rarst. is add_action( "show_admin_bar", "__return_true" ); add_filter( "tts_can_switch_themes", "__return_true" ); supposed to be enough to let un-logged-in user switch themes
some day I want to make a list of things which people only learn halfway from snipetts so they have a reference for other half :) __CLASS__ qualifies :)
I don't... "static" classes are essentially fake namespace, which 5.2 doesn't have
if need real object instance still need to properly create it and WP doesn't have good place for it to go... thus global or perversions with singletons
I need to try writing plugin with namespaced functions some time
Hm. I must be doing something wrong... Need to merge two arrays. If the first one is empty, I don't need all the different merge logic in between. Now I got two options: Wrap it in a if ( ! empty( $array_one ) ) or do a goto... never thought I would be in the case where I would find a valid use case for goto. Feels wrong.
Yeah, I needed different joins for capabilities: A) "Full" join (all caps from both arrays), B) "Inner" join (intersect), C) "Outer" join (diff) and D)efault (only new ones).
Am I right that there's no API method or function that lets me assign additional capabilities to post types or taxonomies aside from assigning them during registration? In other words: No official way of adding custom capabilities to built in post types/taxonomies?
@StephenHarris I mean the seven additional primitive capabilities.
So you set map_meta_caps to TRUE, then assign a custom string for capability_type to then get those + custom names for the default primitive capabilities then get mapped to the default capabilities by core (but are not used by it).
@kaiser Looking at the function, it looks complicated... but that seems the only filter available to even get close... hmm
_post_type_meta_capabilities in post.php line 1460 is a private function Stores or returns a list of post type meta caps for map_meta_cap(). so.. yeah not much available to us
pffft... what a fucking mess. already forgot how much of a mess this is.
Seems like capabilities change on the fly depending on the post status. This will be fun with register_post_status() and custom post status.
@StephenHarris yes, caps are assigned to users. and they're assigned to roles as well. not sure why this needs to be this way. or if this needs to be this way at all.
@kaiser Ok, so for example an end user might what to allow users to be able to edit post type X if they have capability Y? And you want to change Y from 'edit_X' to any capability they choose?
@kaiser Ok, so map_meta_cap would be it I think. You can replace any capability (primitive or meta) with the new caps chosen. Meta caps at least will have the post ID passed to them via $args from which you can get post type etc.
@StephenHarris Well, for a role manager I won't be able to use map_meta_cap() as this "thing" considers different states and screens, while I'd need to have all of them available.
Freaking User and Role management is fucking crap...
Problem is that any sort of UI would need to have them available on a separate screen somewhere, somehow. But I wouldn't be able to retrieve them together at some page.
You know: WP sucks in a lot of corners. Roles & Capabilities is such corner. After hours of reading through core, I'm still not sure if it's enough to assign a capability to a role or if I have to assign it to a user as well. When you look at the predefined roles and a basic new user, the user got the role name plus the capabilities.
Stuff is spread between WP_Roles, WP_Role and WP_User and what not else...
for the plugin we wrote, we didnt add the capabilities until the filter was added, so they were checked and assigned at runtime, the roles system just wasnt flexible enough
@kaiser yeah it does, but edit_post, read_post, and delete_post are not supposed to be added to a user role, instead, you add to a role such caps as edit_posts, edit_others_posts, delete_posts etc...
just curious, you know on Rilwis Metabox, in some input types he has call to static function add_actions(), is it just me or is he adding multiple actions even if you call a file input 10 times? I'm just asking about efficiency here... (bit tired) thought you might know
@userabuser sorry, haven't done anything on or with it since ages. Currently looking into Pods again. Has some problems as well, but the architecture seems to be more robust, the thing over all more capable and has a better UI
Never played with Pods... always glossed over it. Thanks anyway, I was just inspecting his architecture amongst other APIs in comparison to mine. Finally had enough of using multiple classes for meta, options, standard forms...
@userabuser Just to make sure that there's something in common between every possible field type. Starting at input/text fields until Google Maps autocomplete fields.
btw I quit wptavern long before buy-out when Jeffro said he will cover things in line with "community" (dot org party line) without muddling them with pesky things like objectivity and personal take
@kaiser My Form API is a standalone form field builder of which extends a parent class that handles the additional WP logic and form definitions (metabox, option panels, standard). DI is something I am thinking but need to get mechanics in place first.
@Rarst until the recent buy out, I thought it's graphical clone of wp-hackers and therefore never looked :D
@userabuser would separate it much more. one class for meta boxes, one for options, etc. central controller. as much as I was a fan of extending stuff, I'm now after I've seen how much more flexible the DI scheme is.
@kaiser Agree this is route I am going, logic for metabox is in one class and for options in another, just need to decouple further. Will send to you when done for you to review, maybe can provide some design input.
Latest fields I had to do were for Widgets. I simply copy/pasted everything from one Widget to another. Fed up by trying again and again and again. Just too many cases, too many different things.
Your overall problem will be that you'll need scripts for classes -> WP Dependency. You'll need different MarkUp Wrappers -> WP Admin styles and politics. The list is just fucking endless.
Tables. Tables with two columns - one for label, other for field. Table with both in a single td. No tables. Descriptions jump around. Block separators, block descriptions. No labels, etc. etc.
@userabuser I even started to use DOMElement and similar stuff to become more flexible. But nothing's flexible enough when every fucking single admin page is hand coded MarkUp...
Considered DOMElement for building form markup, but not bothered with that now... But I was just going to use Zurb Foundation CSS framework form control styling in admin. Surely not a problem
It's already hard enough to get the MarkUp up and running as there're several field classes that only apply properly if you got the needed wrappers. So div#wtf surrounds div#wrapper to make input[type=number].small work.
And you'll want to stick with it as MP6 is ~4-5 month away from being brought into core.
Hi everyone! Got a question that I cannot ask on WPSE, since it's highly subjective: has anyone ever used a PSD-to-WordPress-theme service? codeinwp.com, psdtowp.com, pixelpress.co are among the top search results. Any experiences to share? I'm thinking about it at the moment: just looks so cheap and time-saving. :)
@userabuser @kaiser Beyond simple function wrappers for displaying an actual form element ( input / textarea / select / radio ), a form API for the admin is pointless. No consistency. As kaiser said each page is finely hand-crafted by the author to give it a unique quality - poetry, right? ;)
Before I tempt to ask the Lords of the Repository anyone care to chime in with an opinion... Can you include Creative Commons 3.0 BY-SA images in WordPress repository plug-in
@Wyck What's legal and what WP says it will allow are completely different things :). Repo rules say not to CC, but its not clear if that just refers to code....
@Wyck wait, still might be. Eurgh. Point is legally it is fine. GPL and CC don't mix as far as images are concerned. But I can't say the images are GPL (apart from the fact that doesn't make sense). And thats what repo want. Meh.
Ironically by being so staunchly GPL they're being more restrictive... yay for protecting my freedoms!
> Can you imagine WordPress without any CSS or javascript? So as before, we will only promote and host things on WordPress.org that are 100% GPL or compatible.