David Levine

Seems you beat me to it over at https://github.com/wp-graphql/wp-graphql-acf/issues/372 ??

Hey @ferdausalom,

The core WPGraphQL plugin only exposes GraphQL data for WordPress.

For ACF, I suggest you check out the beta WPGraphQL ACF extension. Support for that plugin is provided in that repo, and the #acf channel in the WPGraphQL community Slack.

• This reply was modified 1 year, 3 months ago by David Levine.

Hey @fograinfall,

Since the PostObjectConnectionResolver uses a WP_Query() behind the scene, the easiest way to debug this would be to pass those filtered $query_args to a new WP_Query() call and compare the results. If your own query is also coming back bad, then inspect those args to see what’s going wrong.

If the manual query comes back valid, then it’s likely something else in your stack (custom code, 3rd party plugin, etc) modifying the query. In that case you can go the tried and true “disable, then reenable your plugins one by one” or enable SQL query logging in the WPGraphQL Settings to see what’s actually being requested in order to help you narrow it down.

Thanks @otto42 .

I can’t help shake the feeling that we’re talking on different wavelengths, and you’re trying to convince me to apply the GPL to my own code, when that’s not my motivation and I’m coming from the opposite direction. Of course WordPress should encourage open source and the correct – or even minimal – adherence to the GPL. The fact that there’s significantly more than a handful of docs (albeit outdated) describing the importance and application of GPL to distributed code attests to that interest. The fact that all hosted code on .org must be GPL (as you keep repeating) is similar testament.

As such, the fact that there’s a significant uptick in premium WordPress block themes and plugins potentially not adhering to the GPL – whether intentionally or out of ignorance due to outdated official recommendations – should indeed be of interest. Such as when they only release their compiled JS (despite using WordPress libraries) or possibly CSS. These actors anecdotally includes several premium offerings who’s (compliant) free versions are hosted on .org.

Regardless, I appreciate your answer to my question about the *existence* of up-to-date resources on the topic, and I’ll go ahead and open a ticket requesting a refresh with the docs team.

(the resolve checkbox isn’t working from my mobile, but feel free to close this ??)

• This reply was modified 1 year, 8 months ago by David Levine.

@otto42 let me perhaps ask in another way: Has .org or leadership provided any direction or guidance on GPL in themes either in direct relation to block themes/ FSE or even just chronologically after 5.0 fundamentally changed how WordPress uses non-PHP assets?

I’m asking from an ecosystem/docs perspective, not looking for legal advice on a specific product. As a champion of GPL, I’m finding it puzzling that all the official WP guidance I can find is extremely outdated (such as the referenced link in my OP) even though I’m sure these conversations must have happened some time over the last 4+ years.

• This reply was modified 1 year, 8 months ago by David Levine.

Thanks @otto42 and @jdembowski for the quick replies!

I am aware of the .org requirements, just requesting clarification about the actually GPL applicability for themes distributed publicly outside of the the respective directories.

@jdembowski does that exception only apply to standalone CSS or also those which use one of WP’s build tools to compile them (the practical implication being whether a theme would be required by GPL to make the src files available)?

Also, does that mean that .html files are also not automatically covered by the GPL (since GB comments are ignored similarly to design tokens)? And where does theme.json or block.json files fit in?

@galbaras AFAIK 5.9 and below, WP6.0 added that extra parameter…

Is there a way to add the created <Context.Provider> higher up in the DOM? Because otherwise, it won’t be passed to the InnerBlock, since it’s a slot, and not an actual child element (which was the issue with trying to use React.createContext natively)

• This reply was modified 2 years, 11 months ago by David Levine.

The solution was to use the the isSelected attribute in edit.js

issue was a typo. apologies

@bordoni thanks for the quick reply and the workaround.
I actually came across this using the QL-Events extension for WPGraphQL.

Seeing as this is seemingly a known quirk, I’ll relay that there (no idea how feasible it is to use TEC’s orm instead of wordpress’ built in queries.)

Going to leave this ticket open for a little bit, and report back.

@sjnbham any word from them?
(Id contact them myself, but we use the nonprofit license, so we’re limited to free support…)

Please post back if you hear anything before they respond here! ??

Persists in v5.0.1

@vikings412

I have activated the v2 views, and the monthly calendar and all of the other views on the calendar page are update. However, if you go and click on an individual event the single-event page still looks like the old design.

This seems like a different issue. For me, when v2 views are activated no tribe views shows at all, the_content() just returns blank.

PS: Not all views were updated with 5.0, and it seems that single events are still using the old templates (single-event.php if it was created in classic editor, and single-event-block.php if it was created in the block editor).

• This reply was modified 5 years, 1 month ago by David Levine.