-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Enhancement: Improve Documentation #278
Conversation
…ui-prototype Prevent input for non-text selections
…ui-prototype Use functions instead of commands where appropriate
…tyle. Also make it keyboard friendly (WordPress#136) * update the TinyMCE per Block prototype UI to match the Prototype UI style * Adding heading block * Adding a paragraph block and moving to React - preact has some state updating bugs * Allowing removing/merging components using backspace * Handling navigation using arrow keys * Adding a simple quote block
…hs, quotes, headings) (WordPress#148)
- Includes a new drag and drop mockup - Includes an admin with the sidebar closed - Includes an updated Sketch file that has the admin UI stuff
Update Mockups
…ui-prototype Tinymce single/mimic ui prototype
…ui-prototype Hide inline formatting toolbar along with rest of block UI
…ui-prototype Tinymce single/mimic ui prototype
…ui-prototype Start work on inserter
…ui-prototype Add undo levels for moving blocks
…ui-prototype Lighter UI: only leave align centre, clearer remove format icons
Note: It creates additional paragraphs when dragging non editable blocks. This reverts commit bef6be3.
These mockup updates include general refinements and polish, per Github and Slack discussions. Notably around: - Galleries. Props @j-falk for ideas here. Trash and edit buttons when selecting individual images in a gallery, and button for advanced gallery editing, where you'd also be able to add more images to the gallery, or rearrange, in the case of a slideshow version of the gallery. - Drag and drop. Props @iseulde for the idea of showing a blue line for the dropzone. The gray area is a ghost of where you're dragging from, so the blocks don't size around when you drag. - A new approach to inserting content. It generally happens on a newline, and the plus then shows up to the left, where the up/down arrows would show up for a non-empty block. We'd then have a permanent "insert" button somewhere in the Admin UI to go with this, for when you need to insert content between two letters. See also WordPress#78. - Added empty versions of Quote and Image block. Imagine the use case of _type type type, press enter for newline, type `/ima` to open inserter searched to Image, press enter, arrow down, type type type_. In that case you'd simply inserted an image placeholder block which you could later upload to, or pick an image from the media library.
Update mockups
Filenames with unencoded spaces worked yesterday. Suddenly it doesn't. No idea why. Will use dashes instead of spaces in the future.
Fix weirdly broken markdown
Adding plugin folder for the project.
This PR improves the internal documentation for index.php
/** | ||
* Plugin Name: Gutenberg | ||
* Plugin URI: https://wordpress.github.io/gutenberg/ | ||
* Description: Prototyping since 1440. Development plugin for the editor focus in core. | ||
* Version: 0.1 | ||
*/ | ||
|
||
// Hook. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My personal view is that a comment shouldn't exist to describe what exists, but why (more specifically in clarifying potentially ambiguous logic). In this case, "Hook" is already quite clear merely by the invoking add_action
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My intention of adding this comment is always to be liberal with documentation. It not only makes sense (to me) but helps the code look more clean.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My intention of adding this comment is always to be liberal with documentation.
There's an underlying assumption here that "more documentation is always better", to which my comment is primarily directed at disputing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you suggesting that we should not document this? Do you have an alternate suggestion here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you suggesting that we should not document this? Do you have an alternate suggestion here?
Right, it's fine to not have comments where comments aren't serving value.
/** | ||
* Gutenberg's Menu. | ||
* | ||
* @since 0.0.1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think @since
should follow the repository's own versioning, or that of what we expect the WordPress version to be upon integration? We may simply want to leave it out for future consideration.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, currently, I added it as per the repository's version but changing it to 4.8.0
does make more sense. Will go ahead and change it.
plugin/index.php
Outdated
/** | ||
* Scripts & Styles. | ||
* | ||
* @param [type] $hook |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[type]
should be defined. There should also be a description explaining what $hook
is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was not as clear to me, so I let it be to be reviewed and added at a later stage. I think the $hook
is going to be a string
value of screen name?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just addressed this one.
@@ -19,13 +23,26 @@ function gutenberg_menu() { | |||
); | |||
} | |||
|
|||
// Hook. | |||
add_action( 'admin_enqueue_scripts', 'gutenberg_scripts_and_styles' ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like that this was made consistent with positioning relative to its callback function with the one earlier in this file, but what's the pattern we should follow with regards to being above/below the function declaration? At least in twenty* themes and built-in plugins (hello.php
), it's placed below the function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having function and file level DocBlocks right after one and another makes less sense.
In what way does it make less sense?
The relative positioning doesn't really impact much since it works in either case. My point in bringing it up was in whether it may be at odds with expectations other contributors would have coming in being familiar with differing patterns found more commonly in other plugins and core code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here's a couple examples of the precedent I was referring to:
- https://github.com/WordPress/WordPress/blob/9f4bbcd/wp-content/themes/twentyseventeen/functions.php#L530-L542
- https://github.com/WordPress/WordPress/blob/dd6da70/wp-content/plugins/hello.php#L80
There's not a whole lot of examples in the core code itself, as callbacks are often defined separate from the hook itself or the hook is created in the constructor of a class.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Guess, that's what I ended up with on the merged PR>
Definitely good to be thinking about documenting functions. We should be striving to include these with any new code we introduce 👍 |
Just addressed the conflicts. See if this is mergable now? |
I think this needs to be rebased over the new master (to avoid keeping the old history) |
@youknowriad Should I add a new PR or rebase this one? |
What works best for you. I'm not an expert Git, if you want to keep this one, maybe @nylen could help |
@aduth and @youknowriad I have closed this PR. Was going to rebase it but I think the plugin files have been moved since then? Do you know where? |
yes, the root folder :) |
Damn, how did I miss that :P 👍 |
Sorry for the delay in responding. I'll add comments here, though understanding points have been reiterated and changes merged in #290. |
This PR improves the internal documentation for index.php