visual-framework / vf-wp Goto Github PK

By default WP is attaching some styling that clashes hard with VF styles; see: https://www.embl.org/news/lab-matters/corona-updates/

Here .wp-block-button is resulting in:

Here's one possible approach to resolve: WordPress/gutenberg#11338 (comment)

Removing works fine for me with the following example:

wp.domReady( () => {
	wp.blocks.unregisterBlockStyle( 'core/quote', 'default' );
	wp.blocks.unregisterBlockStyle( 'core/quote', 'large' );

	wp.blocks.unregisterBlockStyle( 'core/button', 'default' );
	wp.blocks.unregisterBlockStyle( 'core/button', 'outline' );
	wp.blocks.unregisterBlockStyle( 'core/button', 'squared' );
} );

This script is enqueued via wp_enqueue_script( 'gutenberg-testing', plugins_url( 'editor.js', __FILE__ ), array( 'wp-blocks', 'wp-dom' ), time(), true );

David has made a foundational events plugin in #225 -- it will allow EBI Devs to begin integrating into the contentHub, but to complete the work we'll need some more fields.

Those fields will largely need to reflect the ones in the contentHub event content type:

And here's what it looks like with content:

Not all of these are strictly required, but this is a full list for informational needs.

As noted by @sandykadam, it would be good to import the taxonomy from the URL indicated in the by vf_api_urland then combine the string “pattern.json?pattern=embl-ontology&source=contenthub”

Believe a similar method is already done in vf-cache.php

When caching a response from the contentHub the vf-wp theme seems to be erroneously parsing HTML comments.

For example:

<div class="vf-content-hub-html">

   <!-- Generated by: http://content.embl.org/api/v1/pattern.html?filter-content-type=article&amp;filter-id=580&amp;pattern=node-body -->
   <div data-embl-js-conditional-edit="580">
   <div class="vf-banner vf-banner--phase">
   <div class="vf-banner__content">
   <!--<span class="vf-badge vf-badge--primary">BETA</span>-->
   <p class="vf-text--body-r">We're building a new website. <a href="https://www.surveymonkey.co.uk/r/emblbeta" class="vf-link">Complete our quick survey</a> to help us make it better.</p>
   </div>
   </div>
   <a class="vf-text vf-text--body-r vf-link embl-conditional-edit" href="https://content.embl.org/node/580" target="_blank">Edit</a>
   </div>
 </div>

Becomes:

<div class="vf-content-hub-html">
  <!-- Generated by: http://content.embl.org/api/v1/pattern.html?filter-content-type=article&amp;filter-id=580&amp;pattern=node-body -->
  <div data-embl-js-conditional-edit="580">
  <div class="vf-banner vf-banner--phase">
  <div class="vf-banner__content">
  &lt;!--<span class="vf-badge vf-badge--primary">BETA</span>--&gt;
  <p class="vf-text--body-r">We're building a new website. <a href="https://www.surveymonkey.co.uk/r/emblbeta" class="vf-link">Complete our quick survey</a> to help us make it better.</p>
  </div>

This particular example is easily fixable in the contentHub, but we'll surely see similar in the future.

Here are the error pages we use for Apache, would be ideal for WP to match:

• https://www.embl.org/info/error-pages/500/
• https://www.embl.org/info/error-pages/403/
• https://www.embl.org/info/error-pages/404/

Current WP one:

• https://github.com/visual-framework/vf-wp/blob/master/wp-content/themes/vf-wp/404.php

The current scenario:

• cache is empty, or stale
• a server-side request is made to the Content Hub
• on success: replace cache with new content
• on failure: replace cache with JavaScript fallback
• cached content (or JS) is served in the PHP template

Problem: if the Content Hub is inaccessible for the client-side request we're left with a lot of blank areas on the page because the old content was already lost. The JS fallback is also likely to fail.

Not really a bug because it's by design but it feels like one if the cache was not empty.

It would make more sense to toggle a flag on the cached content if a server-side request fails. That way we can serve the JS fallback alongside the old content rather than replacing it in the cache. Instead, JS attempt to replace it client-side. The next successful request removes the flag.

This change should serve the most up-to-date content without throwing it away to quickly.

The stylesheets are hard-coded into the EBI Global Footer plugin template causing CSS issues.

Move them to a WP enqueue hook before the vf-core and main theme CSS.

Paragraphs, headings, and lists need to be wrapped in a vf-content class.

We'd need to change the grid-column for vf-breadcrumbs for this not to break.

embl-grid adds vertical spacing which looks horrid for simple components like this, and as with the groups, like it seems the dashboard - vf-body is the parent so it could grab the grid from that.

Also - if vf-core has the grid changes making things max-width and margin: 0 auto it would tighten this up a little too

So, there's options.

I know things have changed for the embl-logo component. I think this needs updating in the group pages as there is now logo appearing at all.

Checked these sites to make sure it's not a 'one-off':

• http://dev.beta.embl.org/groups/bernabeu
• http://dev.beta.embl.org/groups/ebisuya
• http://dev.beta.embl.org/groups/ellenberg
• http://dev.beta.embl.org/groups/ephrussi
• http://dev.beta.embl.org/groups/eustermann
• http://dev.beta.embl.org/groups/galej
• http://dev.beta.embl.org/groups/garcia-alai
• http://dev.beta.embl.org/groups/gibson
• http://dev.beta.embl.org/groups/haase
• http://dev.beta.embl.org/groups/hackett
• http://dev.beta.embl.org/groups/hiiragi
• http://dev.beta.embl.org/groups/koehler
• http://dev.beta.embl.org/groups/korbel
• http://dev.beta.embl.org/groups/krebs
• http://dev.beta.embl.org/groups/lancrin
• http://dev.beta.embl.org/groups/loew
• http://dev.beta.embl.org/groups/marquez
• http://dev.beta.embl.org/groups/ries
• http://dev.beta.embl.org/groups/steinmetz
• http://dev.beta.embl.org/groups/zaugg
• https://dev.beta.embl.org/groups/ellenberg/
• https://dev.beta.embl.org/groups/gibson/
• https://dev.beta.embl.org/groups/koehler/
• https://dev.beta.embl.org/groups/loew/
• https://dev.beta.embl.org/groups/ries/
• https://dev.beta.embl.org/groups/zaugg/
• https://dev.beta.embl.org/groups/eustermann/

Unless I'm missing something?

Gutenberg block transforms provide a convenient way to convert blocks.

The vf/grid and vf/embl-grid both use similar inner blocks template with vf/grid-column as the only allowed children. Transforming between the two should be easy?

Consult the setColumns callback for merging columns.

The scripts bin/dev quick_group etc are failing to configure WordPress.

I was seeing a lot of errors:

Error: 'wp-config.php' not found.
Either create one manually or use `wp config create`.

It would eventually load a default unconfigured WordPress in the browser on the install page.

I had to add this to my .env file:

WP_SETTINGS_PHP=${RELATIVE_DOCUMENT_ROOT}/wp-config.php
WP_DEFAULT_SETTINGS_PHP=${RELATIVE_DOCUMENT_ROOT}/wp-config-sample.php

and then the setup process was able to bootstrap successfully.

Not sure if this the permanent solution I should commit?

The cache is caching the error message Error connecting to data source and never updating despite the vf/cache/update AJAX action running.

Related (out-dated) PR: #21

Widgets like WP_Widget_Categories need vf-list classes.

We're using filters with string/regex replacement on the widget HTML. Not nice but WordPress doesn't give us much option.

After updating to WordPress 5.3 blocks in the Gutenberg editor do not add or reorder properly.

Initial investigation suggests only a Firefox issue.

Chrome handles it (with new fancy animations).

Happens with WP core blocks alone, so not a bug we can resolve here?

From @sandykadam:

can you please call the API endpoint from the config options_vf_api_url instead of hardcode. because we are going to set it via VF config - https://dev.beta.embl.org/api/v1/

As spotted by @sandykadam: The new template defaults to the EMBL header+footer, which means EBI sites now get the wrong header+footer:

There are number of possible approaches:

1. have the template referance all 4: EMBL header+footer and EBI header+footer and then if a plugin is disable it just wouldn’t show
2. add an option to change the “default” one the deployment script would just have to edit the default post
3. others?

Probably will have to wait until @dbushell is back on the week of the 27th

In the theme's partials/vs-masthead.php include, the short description under the group name is from the Content Hub.

Todo:

• Use config instead of hard-coded API in template (https://dev.beta.embl.org/api/v1/)
• (idea) Move to EMBL Settings admin page with button to refresh cache
• (idea) store as standard WP blog description/tagline option?

Need to check if the vf-wp-news theme works with the new templating system.

Also remove unused files (e.g. /functions/ directory).

1. Too many borders around the preview
2. Missing new line after the "Number of Columns" label

Currently we can add pre-made vf-block or vf-container level components to the WP Gutenberg editor (that's great).

To build more dynamic pages we'll need to be able to add vf-grid and embl-grid container and then add Gutenberg blocks and vf-blocks inside that "grid container".

Documentation on the parent grid:

• vf-grid: https://visual-framework.github.io/vf-core/components/detail/vf-grid.html
• embl-grid: https://visual-framework.github.io/vf-core/components/detail/embl-grid.html

So the workflow might be like; an editor:

1. Adds a custom Gutenberg block: "EMBL Grid"
2. Selects type of EMBL Grid, in this case embl-grid embl-grid--has-sidebar
3. Adds a vf-label block to the left grid cell
4. Adds a vf-news feed to middle cell
5. Adds a vf-factorid to right cell

And a vf-grid scenario

1. Adds a custom Gutenberg block: "VF Grid"
2. Selects type of VF Grid, in this case vf-grid vf-grid__col-3
3. Adds a vf-label block to the left grid cell
4. Adds a vf-news feed to middle cell
5. Sets the middle cell to be vf-grid__col--span-2 (right most cell is then disabled/goes away)

The jobs listing sorts to show the first expiring job, we're receiving feedback that it's better to show the newest job instead.

I should be able to tackle this.

As part of the generic page building effort (project?), we'll need to be able to build pages that don't look like groups sites; that is:

Left: embl-boilerplate-page Right: embl-group-page

Currently all vf-wp sites are assumed to be like the right side, but we'll also need to do the left side. The main difference will be in (not) adding a couple of classes to div.vf-body and if a .vf-header.vf-header--inlay is shown.

So we could probably do this any of these ways (or others):

• Make the group look a child theme
• Add a per-page level option of "show as a group page"
• Add a theme level option of "is a group site"

ALSO, there could (perhaps) in time be a couple other options:

• Is an EMBL-EBI group
• We may need to support a difference in look/options between scientific groups and admin teams
• We may want also support embl-subsite-page

☝️ But those are still maybes

If you try to access https://wwwdev.embl.org/groups/dummy-embl-group/ in incognito browser, you will see cookie banner with green button, once you click on it you will get one more cookie banner with regular text. Please find attached screenshots.

With vf-core using Rollup and further integration in the works here #48 – it would make sense to use Rollup in vf-wp too to reduce the size of Node dependencies.

Alternatively, a custom Gulp task (or gulp-babel) would likely suffice.

Webpack was only used as a quick solution.

Issues:

1. Edit mode is now appearing in the styles window (fixed)
2. Styles preview is now "zoomed out"

Group homepage "About" description box which we show on hero banner overlaps on cookie banner on small screens when we scroll down if we don't close cookie banner.

When a query to the contentHub returns no results, it would be nice to have a "No results behaviour".

My initial thought:

No results behaviour

Options:

• Default (as specified in the plugin)
  • Might be: "No jobs could be found at this time."
• Hide the widget
• Use custom text

The built-in WordPress blocks like "Video", "Embed", "YouTube", etc do not support all services that require iframe embeds (namely, Mediasite and Panopto have been requested).

The "Custom HTML" block is not a user-friendly way to embed other iframes.

Idea: create a generic iframe embed block using the vf-video component.

https://visual-framework.github.io/vf-core/components/detail/vf-video.html

Attributes would be:

• url - iframe source
• ratio - aspect ratio for responsive resize (default: 16:9)
• width - (optional) default width for custom aspect ratio
• height - (optional) default height for custom aspect ratio
• maxWidth - (optional) do not resize above this width

Typographic blocks in the Gutenberg editor include:

• core/paragraph
• core/heading
• core/list
• core/quote

We're using the built-in WordPress blocks rather than reinventing the wheel. Unlike our VF blocks they're not sandboxed in an <iframe> with the vf-core stylesheet.

If would be nice if the WP Admin styles the blocks so that the whole Gutenberg experience ressembles the VF design (closer to the front-end) and not a hybrid.

The theme functions/admin.php enqueues an admin stylesheet. Move this action to the vf-gutenberg plugin?

After #48 is integrated it will be easier to include the relevant Sass. Additional selectors will be necessary to scope or override existing styles.

The code that allowed the header to be set as EMBL Green or EBI Petrol I believe is no longer used (or needed) with the new vf-masthead, at least for the vf-wp-group child theme.

If so, we should remove the configuration option and code.

This relates to visual-framework/vf-core#758 and the vf-masthead (sort of) no longer supporting colourisation.

The @visual-framework component packages will soon contain precompiled Nunjucks templates. Use those instead of the local versions:

wp-content/plugins/vf-gutenberg/blocks/templates/*

They can be removed from this repo alongside the Gulp tasks to generate them.

Gutenberg block transforms provide a convenient way to convert blocks.

It should be possible to transform between similar blocks like wp/button and vf/button.

This would be a nice feature because we don't necessarily want to remove the core WordPress experience.

This task is to investgate which transforms would make sense.

The tags could be made a bit nicer on the news site.

Currently:

Suggestion:

• make the "tags" header inline
• remove comma from last item

Continuing and closing #29 (FEATURE - Support non-group pages), we have need of a "generic" child theme for higher level EMBL-branded pages; as David said in #29:

I plan to develop another child theme – maybe vf-wp-boilerplate – that has various customisable options and more templates.

There's a need to be able to do a bit more with people querying:

1. Query by custom team

Probably an easy-ish enhancement to the existing vf-members logic to not query for the current team, but to "show me all the members of Web Development"

2. Show a specific person(s)

This might need to be a new Gutenberg block to show vf-person and query for a specific person by name or UUID ... "show me Ken Hawkins as vf-summary--large or --medium"

When a server-side rendered block updates the height resets to the minium causing a "jump" in the content - persist the height between renders?

We're currently using 5.8.0-beta3.

Some time back I tried to update to beta4 but that broke things as cache.php had been removed.

I had started a ticket with the maintainer but have shamefully not followed up ... and it may have been resolved it the latest version (I'd try again, but I can't seem to find the user/pass for the pro version — but looking at the release notes it doesn't seem like the cache has been added back).

My "report":

With the beta.4 we noticed that includes/cache.php has been removed -- we were previously using functions like acf_disable_cache().

If cache.php wasn't accidently removed, is it not recommended to use acf_disable_cache()?  

Response: 
 

We made changes to our "cache" functions in version 5.7.11.

These changes have been included in the latest 5.8.0 beta-4.

Can you please provide some more info/context on why you were using those functions?Perhaps they are no longer needed? Or perhaps we need to add them back in.

Maybe David's already changed his approach or found a workaround.

Should utilise the contentHub for notifications and disable the hardcoded single message.

When changes to visual-framework/vf-core#687 get merged in we would need to update the CSS for vf-wp and also remove the vf-grid surrounding the ContenHub vf-banner for the questionnaire.

Parts of a theme that exist as PHP templates – e.g. the vf-masthead – can adapt to customisation changes because the PHP is rendered on every page load.

There is a problem with Gutenberg blocks that are rendered with Nunjucks templates.

Say we add a vf-factoid block to a page within the Gutenberg editor. The factoid.njk template is rendered as the page/post is edited. HTML is saved to the post content. When that post is visited the pre-rendered HTML is outputted.

If the theme is later customised and vf-factoid blocks require different markup (e.g. a new modifier class), we cannot update those within post content. Only when each post is edited again will they be rendered with the new template.

This is because Nunjucks is a JavaScript library and it runs client-side in the browser.

Possible solutions

1. ❌ Find a way to run Nunjucks server-side. This is not practical without a PHP library (which doesn't exist). Running Node on the server is a big ask. Also keeping track of which post content contains out-dated templates is not trivial. Then updating all posts after each customisation change would be an expensive operation.

2. 🤮 Update posts client-side. This would require a lot of AJAX in the WordPress admin. We cannot guarantee the process will complete, and all the same problems as above.

3. 🤔 Do not use Nunjucks and do not save rendered HTML to the post content (only the block attributes). Instead use PHP templates to render server-side on each page load. This would require a PHP version of the component .njk templates – in vf-core or vf-wp – either way adding to the maintenance.

4. 🤷 Ignore the issue. Assume customisation will be done once when the theme is set up and therefore changes are unlikely. Posts will require a manual edit/save to update.

Thoughts

1 and 2 are non-starters. 3 would be easy to implement (in the theme at least). I'm leaning towards 4 for now until we know just how often the issue might occur.

There may also be some blocks where the style variant is chosen independent of any global theme customisation. We need to account for this use case too.

The React build process for the vf-gutenberg blocks is potentially quite fragile.

Look at the feasibility of using Jest.

Look at how WordPress packages integrate Jest tests.

I was going through some recent code changes and noticed

v0.0.37...master#diff-a0b59d636fa79df20ff152ebec396c7eR119

with lots of vf-text vf-text-heading-- shouldn't these options be whatever the component is? A 'single event'? Also noticed main in there… that's the only <main> on the page, right?

WordPress 5.3 introduces the "Block Example API":
https://make.wordpress.org/core/2019/09/24/new-block-apis-in-wordpress-5-3/

which is basically just a list of example attributes:

example: {
      attributes: { 
          content: __( 'Content of the block' )
      },
      innerBlocks: []
}

Should be simple enough to add examples to VF blocks.

Image blocks (and others) have the default alignment attribute:

Right now this is ignored by the vf-gutenberg plugin which re-writes the markup here:
vf-gutenberg/includes/core/core-image.php

We should either remove the align options if unsupported using block filters to alter the supports attribute. Or update the new markup to account for this option.

See Utility Classes: Float in vf-core.

Todo: list all default WP blocks that include align support.

We have recently moved to update the levels of design fanciness' naming to better match what is used in Mortal Kombat which gives us the benefit of curtailing any potential confusion.

These need updating in vf-wp for (at least) the vf-hero.

The new levels are now

very-easy replaces easy
easy replaces normal
normal replaces medium

problem:

When testing things in IE11 on a refresh developer tools would 'pause' because it has no idea what a promise is.

potential fix:

I think vf-wp needs to include https://www.npmjs.com/package/@visual-framework/vf-polyfill-js in it's package.json

The current implementation of page caching is slow.

Here's what currently happens when the cache expires ($max_age = 300):

1. Stale items exists in cache
2. Page serve request
3. Cache is dumped if $cached_age > $max_age
4. Cache is refreshed (can take 10+ seconds)
5. Cache filled
6. Page served

Conceptual improvement:

1. Stale items exists in cache
2. Page serve request
3. If cached items exist, regardless of age, page served
4. Cache is dumped if $cached_age > $max_age
5. Cache is refreshed (can take 10+ seconds)
6. Cache filled

The masthead colour override setting outputs this CSS:

.vf-wp-theme .embl-group-page--vf-header--bg-color {
 background: #000;
}

The method the VF expects has now changed and needs to be updated to output:  

.vf-masthead {
    --vf-masthead__color--background: #00;
}

The vf-wp ecosystem is maturing and we're preparing to use it in production

As we get through the sprint on the week of 27 April, we should:

• move to stable/alpha/beta releases v1.0.0-alpha.1
• regularly update version numbers of vf-wp's themes and plugins
• note any releases that will require database or deployment changes