profile
viewpoint

getkirby-v2/plugins 238

Kirby plugins from getkirby.com. Extensions, fields and widgets

fvsch/remarkdown 134

Styling HTML as if it were raw Markdown text.

fvsch/kirby-staticbuilder 109

Static HTML exporter for Kirby CMS (v2 only)

firefox-devtools/ux 78

Firefox DevTools UX Community

fvsch/kirby-twig 74

Twig templating support for Kirby CMS (2.x)

fvsch/kirby-bydate 13

bydate plugin for Kirby CMS

fvsch/devtools-svg 8

Proof of concept devtools extension that finds SVG symbols and images in the current page.

fvsch/monospace-theme 8

Minimalist Tumblr theme with a plain text look, based on ReMarkdown

fvsch/sass-mq-build 7

A bit like Custom Media Queries, but in Sass

fvsch/scripts-and-snippets 7

Not very organized collection of scripts and snippets I wrote, mostly CSS, JavaScript, and whatever I use.

delete branch fvsch/kirby-staticbuilder

delete branch : v3

delete time in a month

issue commentdistantnative/retour-for-kirby

Allow redirects for existing pages

This looks great :)

hdodov

comment created time in a month

issue commentdistantnative/retour-for-kirby

Access to content representations get logged as failures?

I'm getting failure hits when accessing those routes myself.

Tested by:

  1. Clearing logs
  2. Loading mysite/feed.xml twice in a browser tab
  3. Loading mysite/feed.json twice in a browser tab

I'm getting two hits for each content representation:

Screen Shot

Good thing if it doesn't happen in Retour 3. :)

fvsch

comment created time in a month

issue openedgetkirby/kirby

Panel: tab title is not updated when navigating to a plugin's page

Describe the bug

When the Panel navigates in JS to a plugin's page, the page's document.title doesn't seem to be updated and ends up stale, showing the title for the previous route.

To Reproduce

Tested using the Retour plugin by @distantnative. I suspect other plugin pages show the same issue, but haven't confirmed yet.

  1. When logged out, load /panel/plugins/retour -> get redirected to /panel/login.
  2. Log in -> get redirected to /panel/plugins/retour.

Or:

  1. When logged in, load /panel/settings.
  2. Then use the main menu and click the plugin's entry -> navigates to /panel/plugins/retour.

Expected behavior

In both cases, when on the plugin's page, the tab's title would say something like: "<Plugin name> | <Site name>".

Actual behavior

The tab's title is the title of the previous page.

Screenshots

When coming from the Login page:

Screenshot

When coming from the Settings page:

Screenshot

Kirby Version

Kirby version: 3.3.6 Retour version: 2.3.1

Desktop (please complete the following information):

  • OS: macOS
  • Browser: Firefox
  • Version: 79 (Nightly)

created time in a month

issue openeddistantnative/retour-for-kirby

Access to content representations get logged as failures?

Hi Nico and thanks for a great plugin! The "Failures" log in particular is super helpful to catch issues such as dead links (internal and incoming).

My logs seem dominated by accesses to:

  • /feed.xml
  • /feed.json

Both are content representations of a single page (/feed), and seem to work fine in my tests when accessed directly or through several feed readers.

Screenshot

I haven't seen this issue reported before in this repo, but I guess it could be an upstream bug you already reported.

created time in a month

issue commentdistantnative/retour-for-kirby

Request for /api/retour/stats/ (with trailing slash) can be redirected on specific setups

For any passerby interested in the Apache rewrite rules, they look like:

# Redirect URLs with trailing slashes to no-slash
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !api
RewriteRule ^(.*)/$ https://domain.tld/$1 [L,R=301]
fvsch

comment created time in a month

issue openeddistantnative/retour-for-kirby

Remember pagination choice

By default the Retour UI shows 10 requests/fails at a time. I tend to bump it to "50" or "all", but on every page refresh it's back at 10.

It would be great if Retour could remember my preference, maybe in localStorage? Another option would be to add an option like 'distantnative.retour.itemsPerPage'.

created time in a month

issue commentdistantnative/retour-for-kirby

Allow redirects for existing pages

I kinda agree with @hdodov, I have this use case (some routes that match a real page that exists for technical reasons and which I want to redirect), and it's puzzling having those redirects not work. I think I opened an issue thinking Retour had a bug ^^ (#155)

On the other hand I see the concern about performance. Some sites can have thousands of redirects, and at least a couple hundred is realistic for lots of sites.

to allow redirects for existing pages, I would have to pump all redirects as routes in the main router

When defining routes manually it's possible to add a single route for the (:all) pattern as a catch all, do some further matching in the action function, and call $this->next() if not matching anything. I wonder if that would be doable here. Might be more performant to have a single route checking 200 patterns than to add 200 routes.

Other possible solutions, each with their own downsides:

  1. A global setting that tells Retour to handle all requests and not just 404s, off by default.
  2. When defining a route, defining if it should work on unhandled requests (default) or on all requests.
hdodov

comment created time in a month

issue openeddistantnative/retour-for-kirby

Request for /api/retour/stats/ (with trailing slash) can be redirected on specific setups

This is kind of an edge case. I have a .htaccess redirect that redirects all non-folder requests ending in / to the non-slash equivalent.

The redirect seems to make the request for /api/retour/stats/ fail (I think the redirection might be loosing the session cookie in my case, but maybe it's only because the redirection is badly set up and redirects to HTTP then back to HTTPS -> the origin change probably looses any cookie).

It looks like Retour doesn't use trailing slashes for requests to other resources, including /api/retour/redirects and /api/retour/fails.

Not sure if the extra slash in /api/retour/stats/?… is worth investigating on your side. Feel free to close this bug if not. :)

created time in a month

issue openedgetkirby/ideas

Ability to create a default page model?

Page Models are IMO a better construct than custom page methods, but models always applying to a single page type can be frustrating. Would it be useful to have a built-in mechanism for defining a page model that applies to all classes?

I’ll try to explain my concern with page methods, what I’m doing with page models and how it might be improved with built-in support. It makes this post a bit long, which I apologize for in advance.

Custom page methods vs. page models

Page methods have a few downsides:

  1. You need to declare a plugin, which feels a bit awkward when it's part of the "core" features of your site or theme. You have to pick a plugin name ('projectname' doesn't work, you need 'somenamespace/projectname'), copy-paste or write some boilerplate code.
  2. They’re closures that rely on the $this object to access the page object, and editors cannot know what $this refers to and provide completions and validation.
  3. They can't override methods of the Page class, and when you try to do it, it fails silently.

They’re a bit hidden away in the "Reference > Plugins" documentation, compared to Page Models which are described more proeminently in the Guide. The page methods docs also compares page models and page methods:

Custom page methods vs. page models

Page models are a great way to create an extended version of the default page object with additional methods and functionalities. But a page model is tied to a specific template, while custom page methods apply to all page objects. If your use case is based on one specific template, a page model might be the better solution. If you have methods that should be available for all page objects in all templates, a custom page method is the way to go.

For these reasons, I tend to favor Page Models:

  1. Easier to create (less boilerplate)
  2. Good typing/intellisense support!
  3. And the ability to override a parent method if need be.

The only downside is that when you do want to add a method to all page types, you need to go back to plugin page methods.

A workaround for a 'base' page model

One way to share functionality between page models is to use class inheritance.

<?php // site/models/common.php

class CommonPage extends Page {
  // some methods here
}
<?php // site/models/article.php
require_once 'common.php';

class ArticlePage extends CommonPage {
  // other methods here
}
<?php // site/models/product.php
require_once 'common.php';

class ProductPage extends CommonPage {}

This works well and fixes all the issues mentioned before, but introduces two new issues:

  1. We have to explicitly require site/models/common.php (which can live anywhere)
  2. If we want the CommonPage methods to be available for all page types, we have to create a page model that extends CommonPage for every single page type, even if it's an "empty" one (like ProductPage in this example). In setups with half a dozen page types or more, that can be verbose.

A built-in way to have a "base" or "default" page model?

Kirby has fallback mechanisms for:

  • Templates: use site/templates/default.php (required)
  • Controllers: use site/templates/site.php (optional)

I propose introducing a fallback or "default" mechanism for page models as well.

For instance, Kirby could:

  1. autoload site/models/default.php
  2. then, for a page whose intendedTemplate is 'article', look first for an ArticlePage class then for a DefaultPage class.

Developers could then decide to:

  • create a DefaultPage class or not;
  • make their other page models extend Page or extend DefaultPage, depending on whether they want to inherit methods from DefaultPage or not.

Downside: that's a bit magical. But the way page models are loaded and defined (with conventions for file names and class names) is already a bit magical, this would fit the current model and using 'default.php' as a fallback has some precedent with templates.

I wouldn't give plugins an explicit way to define a 'default' page model though. Doesn't feel right, but I haven't thought about it much.

What do you think? Good idea? Too complex or too magical?

created time in a month

issue commentfirefox-devtools/ux

Clarify disabled-pausing state

Personally I don't find Chrome's icon a good solution. Pros: there's a clear distinction between the two states because the shape of the icon changes, not just its color. Cons: a blue breakpoint does not convey "Breakpoints are currently disabled" to me, at all.

Chrome, breakpoints enabled: Screenshot

Chrome, breakpoints disabled: Screenshot

IMO we should:

  1. Revise our icon states, but not follow Chrome. We talked about using red for the "on" state of buttons that disable stuff (like the "Request Blocking" icon in Network's toolbar).
  2. Add a warning bar, implementing Victoria's design.
  3. Optionally and like Victoria suggested, remove the graying of pane content because its raison d'être has been superceded by (1) and (2).
digitarald

comment created time in 2 months

issue openedsveltejs/svelte-repl

Could the REPL show the component's state?

When doing the later steps of the tutorial, e.g. https://svelte.dev/tutorial/each-block-bindings, I find that I'm missing a way to inspect the current state of components.

I don't know if that would be possible, and a good fit for the REPL?

Tangential: it seems Svelte doesn't have an equivalent of the React and Vue DevTools extensions either.

PS: Svelte v3 is great, excited to use it. :100:

created time in 2 months

issue commentfirefox-devtools/debugger

Visually distinguish the skip-all-pausing state better

I like it: looks clean, adds needed information, and the Enable button makes sense. No opinion on yellow versus gray.

These banners might make it unnecessary to have a gray color over the entire breakpoints section. It would look nicer to go back to just disabled checkboxes.

Works for me. Me made this style because users would miss the "Deactivated" state (active footgun), but the banner could fix that. And as implemented the current overlay style has a few quirks that I'm not happy with, e.g. you can still interact with everything and add/remove breakpoints, Event Listener breakpoints, etc., and we special-case adding or enabling a classic breakpoint to force-enable breakpoints again BUT only do that for classic breakpoints.

How should interactions with the content work when breakpoints are deactivated?

  • Block everything? (No CRUD operation on any pane.)
  • Allow everything, and re-enable breakpoints on any change?
  • Allow everything, and don't change the "Deactivate breakpoints" state when changing something in the panes?
digitarald

comment created time in 2 months

issue closedmdn/sprints

CSS <color> page has no compatibility information for different color syntaxes

Request type

  • [ ] Please close this issue, I accidentally submitted it without adding any details
  • [ ] New documentation
  • [x] Correction or update

Details

I was trying to find information on the browser support for comma-less rgb() and hsl() syntaxes, which are described on this page: https://developer.mozilla.org/en-US/docs/Web/CSS/color_value

The page has a compatibility table for a feature named color, and the feature name links to this page: https://developer.mozilla.org/en-US/docs/Web/CSS/color which seems to have the exact same compatibility table

It looks like mdn/browser-compat-data does have the information I'm looking for, and it can be found with a careful search on Can I Use: https://caniuse.com/#feat=mdn-css_types_color_space_separated_functional_notation

Should https://developer.mozilla.org/en-US/docs/Web/CSS/color_value have compatibility rows for each feature in https://github.com/mdn/browser-compat-data/blob/master/css/types/color.json ?

I'm seeing the following features:

  • css.types.color (<color>)
  • css.types.color.alpha
  • css.types.color.alpha_hexadecimal_notation
  • css.types.color.currentcolor
  • css.types.color.floats_in_rgb_rgba
  • css.types.color.hsl
  • css.types.color.hsl_function_accepts_alpha
  • css.types.color.keyword_color_values
  • css.types.color.rebeccapurple
  • css.types.color.rgb_function_accepts_alpha
  • css.types.color.rgb_functional_notation
  • css.types.color.rgb_hexadecimal_notation
  • css.types.color.space_separated_functional_notation
  • css.types.color.transparent

I would expect a table with a row for each feature. Does that sound sensible?

closed time in 2 months

fvsch

issue commentmdn/sprints

CSS <color> page has no compatibility information for different color syntaxes

Yes, it's the fix I had in mind :) Thanks for the update.

fvsch

comment created time in 2 months

issue commentfirefox-devtools/ux

[Toolbox] "Active Footgun" icon in panel tabs

We may need to add something in the Debugger panel itself too.

Because otherwise it will be:

  • "Hmm there's a warning in the Debugger" -> switch to Debugger
  • "I'm not seeing anything strange here, what was the warning about?"

Should we reuse the "pause reason" block (WhyPaused component)? To say something like "Hey, JavaScript is disabled. Want to enable it again?"

digitarald

comment created time in 2 months

issue openedmdn/sprints

CSS <color> page has no compatibility information for different color syntaxes

Request type

  • [ ] Please close this issue, I accidentally submitted it without adding any details
  • [ ] New documentation
  • [x] Correction or update

Details

I was trying to find information on the browser support for comma-less rgb() and hsl() syntaxes, which are described on this page: https://developer.mozilla.org/en-US/docs/Web/CSS/color_value

The page has a compatibility table for a feature named color, and the feature name links to this page: https://developer.mozilla.org/en-US/docs/Web/CSS/color which seems to have the exact same compatibility table

It looks like mdn/browser-compat-data does have the information I'm looking for, and it can be found with a careful search on Can I Use: https://caniuse.com/#feat=mdn-css_types_color_space_separated_functional_notation

Should https://developer.mozilla.org/en-US/docs/Web/CSS/color_value have compatibility rows for each feature in https://github.com/mdn/browser-compat-data/blob/master/css/types/color.json ?

I'm seeing the following features:

  • css.types.color (<color>)
  • css.types.color.alpha
  • css.types.color.alpha_hexadecimal_notation
  • css.types.color.currentcolor
  • css.types.color.floats_in_rgb_rgba
  • css.types.color.hsl
  • css.types.color.hsl_function_accepts_alpha
  • css.types.color.keyword_color_values
  • css.types.color.rebeccapurple
  • css.types.color.rgb_function_accepts_alpha
  • css.types.color.rgb_functional_notation
  • css.types.color.rgb_hexadecimal_notation
  • css.types.color.space_separated_functional_notation
  • css.types.color.transparent

I would expect a table with a row for each feature. Does that sound sensible?

created time in 2 months

issue commentfirefox-devtools/ux

Polish Headers Side Panel

For the URL params when there are many:

This could work, though the expanded query string part could end up being pretty massive

One option is to truncate and, rather than expand, add a button that sends the user to the "Params" tab where we already parse and display the URL parameters.

janodvarko

comment created time in 3 months

more