A lot of this apprehension about Perch would be nullified if the communication just improved. I'm completely sympathetic to the situation – it's hard to justify time to a product that isn't currently sustainable – but at the same time, it's not unreasonable to expect the product creators to be a bit more active in the community. Answering a handful of forum posts every couple of days, tweeting a Perch thing or two, or dropping into the Slack room now and again is not too much to ask.
Moving the codebase over to Github and letting the community contribute would be a great way to help move things forward. Both Craft and Statamic (amongst others) are doing this with success. You could trial this with V3 while you work on V4.
I don't think you're alone Ryan – more and more of us will be considering our options over the coming weeks and months. The lack of communication is unacceptable now.
Unless we get an update and some reassurances soon, then going forward – as clients need updates – I'm going to have to advise that they move platforms. I've already got several big projects lined up for this year and I just can't justify choosing Perch at the moment.
format="M jS, Y"
Valid points, but I would add that they are now are having to change the pricing model as Perch as it is, is not sustainable which indicates something somewhere isn't working. And it's not always down to how you price your product or service.
This is of course all conjecture though, and like yourself and others have noted, Drew and Rachel are the only ones that know the details. Hopefully, if nothing else, this thread will help them decide on the way forward.
I understand why they've positioned it like they have, and why they chose to use that tagline. The low barrier of entry for less experienced devs is one of the things that sets Perch apart.
I do believe, however, that by combining the two products, they could easily market it as a CMS and a set of tools that lets you do the simplest of things very easily, as well providing the depth of utilities to build out more complex sites like we know it can do.
Absolutely, if the ratio of Perch-to-Runway is currently skewed towards Runway then this doesn't make much financial sense.
You make a good point about the tagline too – I think this probably does more harm than good.
Locking the licenses after a year is essentially the same as paying for updates after a year though isn't it? Or are you purely referring to how domain assignment should work? I wouldn't mind this, although I can think of some edge cases where a business wants/needs to change their domain; but I guess on those occasions we could reach out to Perch and request a license migration?
Some good discussion here but it's all irrelevant if the communication, support, and update frequency doesn't improve.
100% agree hus_hmd. Collections can already replace some existing apps but I like the idea of optional templates for less experienced devs.
Regarding the subject of monthly/annual subscription – by switching to a standard subscription model, I could see this being the final nail in the coffin for Perch. However, using the approach where you only pay to get updates à la Sketch and Craft, is a much better compromise I think.
I also think they should consolidate Perch and Runway. Have one price for the Perch product (somewhere in between standard and Runway as it is now) and you can then choose how you wish to build your site. They will lose a bit on runway licences but make it back on standard Perch, which I would hazard a guess is the better selling one anyway. This would also come with less overhead to manage two separate products, and let's face it, £50 for Perch is too cheap.
I'd like to echo everyone's sentiment here – I'll be more than happy to pay to renew a license every year to get the latest version – BUT, like Stephen says, I'd want assurances that support and update rates are going to improve. 1 update in the whole of 2019 is not okay in my opinion, especially when looking at competitors who are pulling further and further ahead.
I'm now choosing to work with other platforms out of concern for Perch's future but would love a reason to use Perch again more frequently.
Also, just a little bit of transparency goes a long way. You will lose more customers by staying silent, instead of just saying: "sorry folks, it'll be another 6 months, but here's a sneak peak of a new feature". We all work in an industry where it's commonplace for anticipated dates to slip but poor communication is far far worse.
Perch is a great CMS already and has bags of potential; and with a bit of TLC from the core team and the right tools for the community to build some amazing apps, it could start making ground on other popular CMS's in no time!
If this is seen by Drew or Rachel, then please consider a short reply acknowledging this thread (or even just a tiny blog post), it would certainly go a long way to reassure a portion of the Perch community.
Well you're in control of the block wrapper elements, so couple nth-of-type with the direct descendant selector and it can't break. I think you're right though, that it's not possible at a template level.
If you wrapped each pull quote block in a different tag than anything else, such as a q or section, it's not exactly semantic, but then nth-of-type would work.
What about using the :nth-of-type() css selector?
Yes, and you could get away with just allowing v- but lots of devs tend to use the shorthand for v-bind or v-on:
I'm looking to use Vue with the Forms add-on, however, when adding the v-model directive to a perch form input, it gets stripped out.
I know it's possible to pass through class names and data attributes but was wondering if you'd consider extending this to achieve the above?