Joe Dolson

It’s just the back-end display; it’s a known issue that I expect to ship a fix to in the next release. The actual dates are correct, they just aren’t displaying in the right timezone in the admin.

So, it’s possible that the issue you’re experiencing is a caching one; try adding your custom icons, then going to My Calendar > Settings > General and checking “Clear My Calendar fragment cache”, then saving settings.

Because replacing icons doesn’t have any corresponding database behaviors, it doesn’t have any mechanisms for automatically clearing the cache, so it may be that the images are fine, but the site is still reading from the icon cache, instead.

Is that file currently present in the directory? I checked the URL for where that file should be found, and did not find it there; but I don’t know that it is currently present.

@signorrossi Yes, that’s part of what’s very different in how Bluesky handles cards. Other networks handle cards centrally – they check the link, find the og data, and generate a card from it. Bluesky requires the agent that creates the social media update to create the card. When you post it on Bluesky, the agent is bsky.app, and they create the card.

Having support for cards will happen in the next release of the free version; it just won’t have image support. In my initial implementation of Bluesky support, I didn’t realize that this particular aspect was handled differently.

Error 0 means that the site failed to load the target page, which usually means that there’s a URL problem – you added a statement to this message that “the links in the header were still on the test site url”, and that would mean that it was trying to load a page that didn’t actually exist. If you’ve now changed the URLs in the new site, then you should be OK.

Yeah, I really really wish that media query max-widths accepted regular CSS variables. It becomes a lot more complicated without that. I have some ideas, but none of them are just trivial, unfortunately.

One option is that I could have multiple responsive stylesheets at different common breakpoints, and users could select what they want. Currently, I’m thinking that’s the easiest solution.

Most likely, I’ll only offer the image support in Pro. I don’t support image uploading in the free edition because – simply speaking – I don’t have enough time to support it at that scale. Image uploading is complicated, and there are a lot of edge cases.

Is it excessive? Possibly. But I only have so much time, and I have learned from hard experience that adding too many features to free plugins is a mistake. It’s a hard reality – but the free version of the plugin is *free*, and I earn nothing from it – but it still requires many hours of labor to maintain and support.

The Upcoming Events widget has a lot of settings, and the specific depend on what you’ve configured. That includes a setting to toggle between whether ‘after’ refers to days or to events – so what are the actual settings you’re using?

What is the name of the file you’ve added? That URL provides numerous ways to download the image, so I don’t have enough information to verify whether the path you’ve created is correct.

That’s interesting; it suggests that something was generating a new ID on each page load, because that would cause this problem. I’ll have to experiment and see if I can reproduce it.

Looks omitted, based on the code history. I’ll get this in the next release, which should be pretty soon.

I’m looking at this, and *probably* the issue is that My Tickets isn’t checking to verify that it’s inside the loop before rendering the cart. It checks whether it’s the main query, and in 95% of cases that’s sufficient, but it isn’t checking for the posts loop.

I’ll have to do some archaeology to see if there’s a reason I’m not checking that; I have many other plugins that do similar things, and they generally check for the loop, so I’m not sure whether this is an oversight or something that I did for a specific reason. If so, I should have left future me a note about it…

That page has been redesigned significantly since that doc was published, and you’ll find those settings at the bottom of the column of custom CSS variables.

If you’re asking about customizing individual event pages, that’s mostly not handled in the styles screen; what’s shown will be controlled by your settings at My Calendar > Settings > Display.

My guess is that there was a cache in place that was flushed when you saved the page; but that’s pretty much just a guess. Thanks for following up!

The width issue is a bug, and is fixed for the next release. The height, however, is caused by your theme, which sets the minimum height for select to 40px, but doesn’t do the same for submit inputs. You could add custom CSS to change this:

.mc-main input[type=submit] {
  min-height: 40px !important;
  min-width: auto !important;
}