Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    David Towoju
    @davexpression

    Hi @davexpression , at the very least I'm going to need the stack trace in order to help.

    It's a PHP 8 issue, it works in PHP 7

    Calvin Alkan
    @calvinalkan

    @atanas-dev Hello Atanas, I can't get JSON responses to work for web request. The header is always empty. I debugged the entire HTTP Kernel.

    For example:

    App::json(['foo' => 'bar'])

    renders correctly in the browser. But the header is empty. Ie content type is not set to application/json altought the kernel supposedly called `sentHeaders()``

    Atanas Angelov
    @atanas-dev

    Hi @calvinalkan m

    Just to be absolutely sure the header is missing, could you please run this and paste the results:
    curl -i YOUR_JSON_ROUTE_URL

    Calvin Alkan
    @calvinalkan
    Hi @atanas-dev . It was a weird issue with some chrome extension I had installed that for some reason in chrome dev tools headers where not reported and that prevented the json form being rendered as json. curl -i gives the correct output and Mozilla also renders it as json. All good :)
    Calvin Alkan
    @calvinalkan
    @atanas-dev I think it might be worth adding to the docs, that in order for admin routes to work that one has to define a callback in add_menu_page
    // This will not work
    add_menu_page( 'test', 'test' , 'manage_options', 'test' );
    
    // Forth parameter is optional in Wordpress but its needed to work correctly
    add_menu_page( 'test', 'test' , 'manage_options','test',  function () {
    
                    // Nothing.
    
                });
    If you skip this Wordpress will not fire the hooks wpemerge relies on admin requests
    Atanas Angelov
    @atanas-dev
    This message was deleted
    Interesting - I'll look into it
    Calvin Alkan
    @calvinalkan

    The reason for this is that inside wp-admin/admin.php Wordpress checks if there is a hook callback registered for the current plugin page. If no hook is present it takes a different path inside the gigantic if elseif statement that wp-admin/admin.php is.

    Instead of dispatching the normal hooks wordpress then tries to load the content from a plugin file and if it cant find any matching file an error is thrown.

    And that hook only gets added if you add a callback to add_menu_page. Annoying.
    Calvin Alkan
    @calvinalkan

    @atanas-dev Can you explain what is ment by this in the docs

    "You should use query() on routes which do not match any valid WordPress URL or your WP Query will consider the request as a 404 - Not Found. You can find more information on this in the dedicated Query API blog post."

    What is considered a "valid Wordpress Url"
    Calvin Alkan
    @calvinalkan

    Am I right that the only reason for using query() is to have to global WP_QUERY query posts correctly?.

    Because thats the only use case I can see. If I dont need WP_QUERY ( which I dont ) I cant see any benefit over just composing everything with controllers and views.

    Atanas Angelov
    @atanas-dev
    Basically, yes.
    There's benefit in having custom URLs be associated with a given post in the case where you want to not have to do extra work for meta/SEO/third party plugin integrations to work on your custom URL.
    There's also the use case of modifying a query for an archive page to show a subset of the posts based on some arbitrary custom logic, for example.
    You could do a /random endpoint that uses ->query() to make the global $wp_query load a random post, for example. While not practical it just shows that there are some extra cases where it can be useful.
    Calvin Alkan
    @calvinalkan

    I see, this then also means that any conditions that use WP_QUERY like post_id condition or post_type condition only work when using query() in the route.

    Which makes sense. Thanks for the clarification

    Atanas Angelov
    @atanas-dev
    No, quite the opposite actually. Conditions that rely on WP_Query (post_id, post_type etc.) can't have ->query() called on them because the conditions require the query to have been executed in order to match (i.e. you can't test against the current post id if the main query hasn't resolved what the current post is yet).
    By default, ->query() usage is limited to the url route condition only as that condition can be evaluated before the main WP_Query has executed.
    Here's an example of what a normal post_id route looks like:
    App::route()->any()->where( 'post_id', get_option( 'my_special_page_id' ) )->handle( 'MyController::myMethod' );
    Calvin Alkan
    @calvinalkan
    Yea, I misphrased my thoughts a bit. I ment that all of these conditions will not work if the url you are routing to is not a "normal" Wordpress URL
    Atanas Angelov
    @atanas-dev
    Yep :)
    except is_404 I guess :D
    Calvin Alkan
    @calvinalkan
    :D

    the condition

    \App::route()->get()->where( 'query_var', 's' )->handle( $handler );

    Only matches default query vars defined in WP_QUERY right?

    Something like this did not work for me for "non WP Urls".

    https//example.com/page?foo='bar'

    Atanas Angelov
    @atanas-dev
    'query_var' uses get_query_var() so it matches its' behavior
    Calvin Alkan
    @calvinalkan

    got it.

    Im customizing wpemerge more and more to fit my own needs for a big project.

    Im very curious about one thing. When you generate an url condition why do you sha1 the placeholders?

    Atanas Angelov
    @atanas-dev
    Honestly it's been quite some time since I wrote that so I can't tell from the top of my head. Most likely, to avoid preg_quote()-ing the special characters in the parameter syntax used in the url at that stage
    Calvin Alkan
    @calvinalkan
    @atanas-dev
    have you ever considered more performant regex routers like FastRoute which would built the regex in one shot instead of all individually or do you think performance gains would be non noticeable respecting all the WP overhead anyway?
    Atanas Angelov
    @atanas-dev
    I have. I believe there were some limitations last time I checked in terms of possible features and general support - nikic/FastRoute#173
    The common case should be that WP conditions are used (post_id, post_template etc.) rather than custom URL ones so in general this is not too much of a focus for me (unless an obvious performance bottleneck is demonstrated, of course).
    If someone is so inclined, I'm sure there's a way to sneak in a custom solution which passes routes with UrlCondition conditions to FastRoute. Not sure if ::routeUrl() will work though, since reverse construction is not supported in FastRoute
    As for the current performance in WP Emerge - I have not benchmarked it against other solutions but I doubt there's a significant difference in performance when dealing with less than 100 routes, for example, which is the common case.
    Atanas Angelov
    @atanas-dev
    Benchmarking would also not be too accurate since the WP Emerge router supports more than just plain URLs as it covers WP-specific needs thus changing how the whole thing works internally (e.g. the whole route condition abstraction is not present in other URL-only solutions).
    Calvin Alkan
    @calvinalkan

    @atanas-dev FastRoute is still maintained and in fact 2.0 is soon to be released. Nevertheless 1.3 is stable and feature complete. Lumen, Slim and other still use it.

    I could not resist myself and got this done. I have a working version locally which works like this now: ( note that this is basically a complete rewrite of the router and condition factory. )

    • UrlConditions are not needed anymore. They are replaced by FastRoute.
    • All Routing features are still available
    • When a request is dispatched first, the url is matched with FastRoute. Then custom "wp conditions" are evaluated.
    • The router now works with a RouteCollection that is cacheable like in laravel. So neither WpEmerge nor FastRoute will be processing any route creation in production.
    • Everything is lazy loaded and resolved from the service container. Handlers, Middleware and Conditions are only instantiated when a route has matched. Right now as things are all custom conditions get created for every route on every request.
    • Reverse routing to named routes works just like before.

    I assume performance will be a lot higher for sites with many routes but I dont have the time to benchmark things right now and Im also not that experienced in setting up proper benchmarking.

    Ofc I dont have any expectations of this being merged ever ( required php 7.3 ) but Ill share you the repo if you want when Im done, maybe you ll find some ideas for WPEmerge aswell.

    rherault
    @Romaixn
    Hello here ! There is a function to get a custom post type inside a shortcode ? (or good old wpquery ?)
    I also had a question about controllers, how to use them in WordPress? In what cases can they be used?
    Atanas Angelov
    @atanas-dev
    Hi @Romaixn ,
    No, there's no special added functionality for this - WP_Query is the way to go.
    Controllers are used to do any extra request validation or processing for custom routes. More information can be found here: https://docs.wpemerge.com/#/framework/routing/defining-routes
    @calvinalkan happy to hear you got it to work. Feel free to share the repo if you'd like :)
    Calvin Alkan
    @calvinalkan
    @atanas-dev I ll share it when I consider it production ready :) Still some things left and I need to look for a way to implement query() routes.

    Right now I have a suggestion for you tho, maybe you overlooked this at first.

    Whoops has an option to open files directly in the editor of your choice.

    Its as simple as doing this.

    $pretty_page_handler->setEditor('phpstorm');

    Might be a nice addition, the value would then come from the user config of course

    Calvin Alkan
    @calvinalkan
    Also, why did you choose to replicate the Whoops layout files in a custom ? Is there any reason for that that I overlooked. Because it looks like its an exact duplicate of the Whoops HTML
    Atanas Angelov
    @atanas-dev
    The whoops internals are easily accessible via the container so you are free to set the desired editor in your project.
    The files are not 1:1 with what Whoops has bundled. There are some key adjustments necessary in order to have Whoops render without issues when embedded in /wp-admin/ inside WP's admin chrome.
    Calvin Alkan
    @calvinalkan

    Yeah I did that, just thought it might be a nice addition to have this in the config for users who dont read all the 3rd party library APIs like myself :D

    Got it, I had not thought about wp-admin.

    Arthos
    @taliesinpenbardd
    hey all, hope you're doing fine. i'm building a website with a quick booking system, using Laravel Cashier to get the first part of the payment. my ReservationController works fine until now, but the /reservation page has "Page not found" as a title. Obviously it comes from myapp_get_index_404_message() but i'm struggling on how to detect a page that is not going through a page template, a page or anything from WP (since it's built by the controller...). anything i've tested so far works (is_page(), is_page_template(), is_archive(), etc). any idea on how to intercept that? thanks :)
    Atanas Angelov
    @atanas-dev
    App::resolve( WPEMERGE_ROUTING_ROUTER_KEY )->getCurrentRoute() may be of help it will return a route object if a WP Emerge route matches or null.
    Arthos
    @taliesinpenbardd
    Thanks, i'll try that
    Calvin Alkan
    @calvinalkan
    you need do include the html meta tags in your view if you are using routes that use pure url matching
    if not wp considers this a 404 and prints the appropriate meta tags when using get_header()
    Calvin Alkan
    @calvinalkan

    @atanas-dev hey atanas, just wanted to let you know a possible bug I found while working on my own version of wpemerge. Right now when you render a view its almost impossible to catch expection while rendering the php file. Because the __toString() methods gets called recursivly output buffering also gets turned on end off everytime. This results in all the html before the error being print to the screen while everythings after the exception doesnt.

    IMO the output buffering should be one level above the the rendering logic inside the toResponse() method on the PhpView class.

    This way you can properly render exceptions without the view output. Maybe this is due to an edge case in my version but Im pretty certain I have not modified anything relevent inside the view related classes.

    Anyway this is what fixed it form me.

    // Inside PhpView
    public function toResponse() : ResponseInterface {
    
                ob_start();
    
                try {
                    $this->toString();
                } catch (\Throwable $exception) {
    
                    ob_end_clean();
                    throw new ViewException();
    
                }
    
                $content = ob_get_clean();
    
                return ( new Response( $content ) )->setType( 'text/html' );
    
            }
    Calvin Alkan
    @calvinalkan

    Just confirmed this also happens on a fresh install of wpemerge.

    Given the following view:

    <?php
    
    
    ?>
    
    <h2> Foobar</h2>
    
    <?php
    
        non_existing_function();
    
    ?>

    and the following route:

     \App\App::route()->get()->url('foo')->handle(function () {
    
            return \App\App::view('view.php');
    
        });