Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add programming language support. #207

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

herregroen
Copy link

@herregroen herregroen commented Dec 9, 2018

For the parent trac issue please see: https://meta.trac.wordpress.org/ticket/3063.

In order to add the Gutenberg JSDoc into the code reference we'd want to be able to differentiate between JS and PHP functions, classes etc.

I've written a simple JSDoc template at https://github.com/herregroen/jsdoc-parser that converts JSDoc into a JSON format compatible with this plugin's import.

But importing that could potentially lead to conflicts as PHP and JS functions/classes might have the same names. This PR expands the structure of the plugin to support multiple programming languages. For now it's just a simple direct approach that needs further testing but I wanted to share it as soon as possible in order to gather input.

I've chosen to explicitly add php as well which means that all existing posts would have their name changed as well. Which means migrating would be a concern.

  • Should the plugin automatically move any existing functions / classes / hooks to the PHP language?
  • As the URL of these things will change to include the programming language should the plugin take care of redirects to those?
  • Should other taxonomies be language specific? Is the JS since the same as the PHP since? Especially namespaces are a likely candidate for something that should be language specific.

@joyously
Copy link

joyously commented Dec 9, 2018

Why does the language need to be in the URL?
As a reference, it's more useful to see all the code that works together for a particular component than it is to see all the PHP and all the JS.
Couldn't the language just be part of the content of the page? And maybe prefixing the page name for the new JS pages, instead of changing all the old PHP ones would eliminate name conflicts.
There are a lot of existing links to the current code reference pages.

@herregroen
Copy link
Author

Because there might be functions in both JS and PHP with the same name ( for example: __ ).

These are different functions that would have documentation as to their usage specifically for that language ( The JS __ loads it's translations in a very different way that the PHP __ does ).

Both functions would require their own page as they're different functions. So they need different URLs to account for that.

@joyously
Copy link

joyously commented Dec 9, 2018

Both functions would require their own page

Of course they need different pages, but you wouldn't need to change the existing ones. Just put the language in the new ones.

@pbiron
Copy link

pbiron commented Dec 9, 2018

Both functions would require their own page

Of course they need different pages, but you wouldn't need to change the existing ones. Just put the language in the new ones.

Yes, adding the programming language to the URL is not needed for existing PHP docs, but I think doing so makes sense architecturally...as long as the 301 redirects are handled at the sever config level.

@herregroen
Copy link
Author

In a long-term view I also believe it's preferable. PHP may be the defacto default when it comes to WordPress development right now. But I don't think that will remain the case.

In the future the unprefixed functions being PHP is not going to be as obvious to newcomers as it is now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants