Version 1.21 #866
Merged
Version 1.21 #866
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Global usage not replaced yet, since it has the side effect of adding a a view to its $views property from the parsed content. Gotta hate side-effects :(
Now that it's not a list (see b95cb93) "add" as a verb makes more sense.
We now get to keep TWO parallel request states. Hurray! </sarcasm> The GravityView_View_Data method calls around the old codebase are now ready to be stubbed out... but be wevy wevy cawful...
The system-wide 4.5.0 is too damn old. We're requiring 4.8 for anything under PHP 5.6, so let's actually use it.
The global mode doesn't seem to allow us to use it, probably due to a missing PATH.
Looks like `gravityview` was defined regardless of shortcircuit returns in the include... dangerous stuff.
Implicitly.
Move GravityView_View_Data::get_default_args to \GV\View_Settings::defaults, stub out all usage in our core.
And deprecate \GravityView_View_Data::view_exists
...in the \GravityView_View_Data class It used to return an array of sorts that is considered a "view" structure. Now it returns a legitimage \GV\View instance that can still be accessed as an array against those "old" keys. This ensures back-compatibility. Next - we switch out old array-based usage for the simple cases of "id" and "view_id" around our core.
...but only during tests. This will help us find, cover and fix code that still uses array access. At this point we're limited to a couple of simple keys. Running the tests only produced one exception, in a test case, which speaks to our meagre code coverage.
Completely forgot about our `GV_NO_FUTURE` tests which resulted in an error in a couple of "future-fixed" spots. Added conditionals.
Revamped wrappers for the Gravity Forms backend and future backends. These can start seeping into the code now bit by bit.
/tests/ and /vendor/ should not be covered, this should give us a nice bump in code coverage, and is technically more correct
Furthering our way to mocking out the GravityView_View_Data class the form is now built into the view. A lot of functionality is failing, however, due to the low test coverage on the old core :(
...if the view is not in the old GravityView_View_Data structure then it has to be loaded.
We're breaking compatibility if we return a \GV\View from the \GravityView_View_Data methods, since a lot relies on it being an array (and \ArrayAccess doesn't help with foreach, array_keys, etc.)
Retraces some steps and to fix \GravityView_View_Data expectations
This reverts commit c7cf6eb. This was a bad idea to begin with, the old APIs should be 100% compatible, even though deprecated. It's the callers that should not call them. Add some \GV\View::as_data() variables back.
This will be used instead of wp_parse_args and shortcode_atts, via the ::as_atts() method.
+ a bunch of other compatibility fixes, moving around and making things work overall. Hopefully.
Otherwise context is not setup correctly in many cases.
In \GravityView_frontend::set_context_view_id()
No need to repeat ourselves so much at this point.
These are all run in our tests, so it's pretty safe to stub them out without writing more tests. Right?
One of the easier places get_views is being used. And we still have no \GV\Entry class...
In `Entry_Collection` - total is the total number of available entries in the backend, while `count` is the number of currently loaded entries in the collection.
In line with our `->as_atts()`, etc.
Needed by the old codebase.
Needed to tack on filters from one to the next.
This is a must for loop detection, otherwise ::count() returns 0 and we keep on ever-fetching, ever-looping, ever-suffering.
Inside `GravityView_frontend::get_view_entries` in its finest.
Many fields have custom extra parameters that are set in the view. We were ignoring these in \GV\Field, until now.
We can't flush before the view post type and the entry endpoint are registered correctly. So call them explicitly before doing the flush to make sure the correct changes are persisted to the database. Fixes #863
For the extra parameters added for different fields, we need a nice way to access them.
Since we have internal sources, for fields like custom content and whatnot, we have to introduce a \GV\Source parent class, which \GV\Form sources will inherit. Plus a \GV\Internal_Source class that knows how to spew out values when needed. This is groundwork for the `\GV\Field::get_value()` function, which is ultimately required in the renderers...
While random sorts are a tricky subject from a performance point of view, correct implementations have the right to exist. We'll allow it.
These will be self-contained context (state) containers that can be passed around the different components as needed. The first such container is the `\GV\Field_Value_Context` which is passed to `\GV\Field::get_value` and contains everything a field would require to get a value (the view, the request, the entry, etc.)
This fixes the "When filtering by GravityFlow's Final Status field you can't view entry details" issue. Fixes GravityKit/Advanced-Filter#31
This adds additional reporting in a most excellent way. Also, I cleaned up the code and logic in a couple places. Oh yeah, AND I WROTE A TON OF TESTS. 🙌
Added `gravityview/search-all-split-words` filter, start of unit tests for search widget.
While we're ad it…
Getting ready for release once reviewed by @rafaehlers
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #748
Fixes #865
Fixes #863
Fixes gravityview/GravityView-Advanced-Filter-Extension#31
┆Issue is synchronized with this Asana task