basically, I enqueue a PHP file, and that includes the stylesheets and writes a static CSS file if the existing one is older than the newest included file
solarized is not high contrast scheme, sure, but not everything about readability is about contrast. black on white with very high brightness is great contrast but hard on eyes
@Rarst I didn't really pay much attention to WP3.6. Then realised that the jQuery UI changes broke several things. Also they did something to mess up jQuery UI dialogs :/
> I’ve seen many designs intended to show upcoming events, only to sit most of the year as an ugly, empty section with no events to show. Wouldn’t it be nicer to show some default copy and markup to show information about events in general, if there are no upcoming events to show?
@kaiser cheers. EO has option for 'no events' message in widget. Otherwise templates are fully customisable. Brian is a Tribe fan so he's probably not tried EO (fully, at least).
The message for a duplicate question is wrong:
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
The correct action is of course improving the current question, not asking a new one. The misleading ...
>This frees up the root directory to include configuration files, allowing WordPress to interact more seamlessly with other applications and services like Travis CI and Composer.
Here is a list of special, unlinked pages (they may be linked in questions and answers) on Stack Exchange sites. Most pages listed here are work in progress. Currently, this list is incomplete.
/reputation - show your reputation and where it came from
/election - elect moderators
/posts/<id>/ti...
I am just coming out of long nap, but I have trouble following that new frontier post. what's the point? all stuff will now be in one larger SVN repo?..
I try to do JS every time I can, so I'm getting better. But backbone was way over my head. That's a completely different concept that any of the other things I've seen.
Other problem was that I couldn't anywhere find that point where WP and backbone communicate via that promised REST interface.
Looks nice and seems fast. But read in a side comment that fast doesn't only come from using backbone. Probably caching all the things, minifying, concatenating, nginx, magic, hats, rabbits.
Most current thing looks to be course or book material. And only other stuff is old and seems unfair to get judged by that. (Wonder why he never does clean up).
as I can read that it's mostly about caching, I guess @Rarst got in contact when writing partial cache plugin?
Nice. Congratulations, looks (more than just) good from the outside.
I've tried to get a bit into backbone.js and failed on a large scale. As I mentioned before you came: Where the heck is this RESTful JSON API connection to core happening?
However, if you load an archive page (in Collections this can be index.php or taxonomy-post-format.php) or a single post page (single.php) you will init a SPA
I did look into it for this project
It seemed like it would be overkill and possibly not as flexible
@tollmanz Ok maybe out of my depth here, but what if different pages are loading various javascript files? E.g. some pages may contain shortcodes which load javascript files and/or use wp_localize_script to print data to the DOM. How does /can it cope with that?
When a page loads, I track which scripts/styles are loaded
When I request JSON for the next requested page, I figure out what scripts/styles are needed.
I then compare what I have with what I need and load the needed files.
Couldn't ship without that as it would break SO many plugins. Granted, this theme will likely break some plugins, but it's hard to tell what the breaking points will be.
Just in short (without attacking you, @tollmanz ): You had to work around a lot of stuff in WP core, right? And it seems you have an edge case scenario on a lot of places like Permalinks, scripts, styles, template parts, etc. I thought backbone would be much more integrated in core. Somehow disappointed now. So after your current experience: What exactly is missing for a full integration backbone/WP?
@kaiser Yeah...this was totally a "can it be done" type of project. We built in such a way that if the SPA didn't work, we could scrap it and still have a theme. But it did work and turned out well. What can you say? You are turning a server side app into a client side app. You have to bend things. We have shortcodes so content must be rendered on the server before loaded on the frontend (although you can still use JS templates).
For full integration, we need to extract some functionality to the client
i.e., we need to be able to take rewrite rules and map them onto BB routers
@tollmanz Nice! I ask because someone using Event Organiser asked if it something like what you're doing was possible. I wasn't sure if it was. So you just load missing javascript files and keep the ones you have... You would have to trigger the 'ready' action on the document too, right?
@Rarst No, not at all. There's isn't any. You're completely free to do anything. But Bolt seems to re-introduce back/front end separation. But maybe that's needed to get on WP users :D
@StephenHarris I use a custom event "post-load". I use it because it's what Jetpack's Infinite Scroll uses, so it might be somewhat of a common thing. Other plugins that work with IS might then just work with this plugin.
@tollmanz Reason why I was so curious about it wasn't only core. I tried answering some JSON Rest API question here on WPSE some days ago and had never used that one before. As it was a good documentation and well written code, I thought you might have done pretty much the same: Mapping an endpoint somewhere around after_setup_theme, take the WP/backbone JSON connection (the one I was searching for) and then simply route everything to either get_template_part() or a backbone template, ...
...depending on an query arg to give different output to search engines or browsers.
Yeah...that more or less sums it up. Unfortunately, you pretty much still have to load all of WP to get the JSON data. The WP/BB JSON connection is a bad one at best. There is just so much you have to do for WP to give it a chance in hell of not breaking every plugin.
If I could just get a title or content or an author without having to worry about filters, shortcodes, and other plugins, it would be significantly easier.
tell me about it... :) WP Parser working on that (but its dev has been zigzaging like bat from hell and I gave up on keeping up), also there might be inline doc convention coming for hooks in 3.7... but it's not like WP even has functions properly documented inline
As @Rarst said: Dynamic/Contextual Hooks are the culprit.
You could have a hundred different pages and custom ones for plugins where the hook names changes, but current_filter() is only able to fetch the resulting string/name.
Things wouldn't even be disturbed during running. Hence I like plugins adding something via apply_filters() or do_action() over "public API" functions.
@Wyck Not that I've ever heard of that. Only things I remember are some place where _doing_it_wrong was added if some filter wasn't already passed.
After reading all that things that should happen for 3.7... MAN! How gracefully will that fail?
@kaiser a lot of it is done enough to be ticked off by adding a json text file here and a json file there. The other half is purely political/management from what i see
redefine what it means for a trac issue to be closed and hey presto
@Rarst One of the rare moments where cynicism fits.
@TomJNowell Wondered about the fast progress of those tickets. CSS Pre-Processor is the most interesting that might be the bottle neck and fail or glory.
I mean contributing is mess enough between subversion and patch files. throw in installing and getting Grunt running into that? especially since asset patches are kinda designer thing, than developer
Composer ticket seems to be waste of time unsurprisingly. can make it work without composer.json anyway...
The message for a duplicate question is wrong:
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
The correct action is of course improving the current question, not asking a new one. The misleading ...
