While the skip-template option returns the items' data, it does not include all the raw data by default. You can tell Perch you want all the raw data with the raw option:
Hopefully this will return all the image data you need for templating.
What sort of data did you add to the database table? Just the default columns? Or did you add some custom properties as JSON in the memberProperties column? It would probably be helpful if you shared a sample of the data you entered.
Depending on your requirements you may choose to store the data in the database or even just save it in a parse-able format like JSON in a file. I'd consider the amount of data, how long you need to keep the data and whether you need to paginate and filter it.
Adding perch:content within a perch:input can cause problems when Perch parses the tags during validation, so make sure it is the last thing you add and after all other attributes:
Plus I wasn't aware you're only dynamically adding values (and not dynamically adding perch:input tags). In this case, perch_content_custom() or perch_form() should also work like Byron Fitzgerald suggested. Though I'm not sure whether the name attribute is required.
The file-type attribute filters existing assets in the asset chooser. I think the editor can still upload PDF files.
It's not ideal that Perch allows selecting PDFs in an image field. One option could be to add a conditional to not render the PDF files at all so the user is forced to pick an image instead:
The above doesn't really cover all cases because it will also match any file path of an image that contains .pdf like /perch/resources/my.pdf_elephant.jpg.
Upon submission, Perch checks the submitted data against the form fields in the form template. Perch does this to validate the form.
So when you add dynamic fields at runtime (on page load), these dynamic fields are not accessible to Perch for validation. As a result, they are ignored. It doesn't matter what function you use to render the form here.
What works is having your form and your dynamic options in a content region, and outputting the form with perch_content(). This works because the dynamic options are rendered and cached when you save the region. To elaborate, when you save the content region Perch renders perch:content tags, but does not render the Perch form tags (these are rendered at runtime). So the cached contents of your region should contain your Perch form tags, which Perch can access upon form submission.
I am fairly sure that I successfully added PDF assets for which Perch did not generate thumbnails.
Does the issue happen when you upload any PDF? Or are you only testing with the same PDF?
And where does this happen? In a content region?
Yes, this is possible. Are you looking to fetch data at runtime (i.e. every time the page loads) and render it on the page? Or would you perhaps like to periodically fetch the data and save it in the database?
Yes, there is. You can use $_POST or the perch_post() function:
You can use Perch Members to restrict access to content on the site.
The payment solution can be anything. You can always integrate something like Stripe without using Perch Shop so you don't have to deal with Perch Shop's current issues. If this requires a recurring payment solution, Perch Shop is not an option anyway.
Ah great! Thank you, Lea.
It's so weird of me to use `realpath` there! I'll update and publish a new release. I've opened an issue on GitHub (https://github.com/Pipits/reda…ine-perch-assets/issues/2), so hopefully I won't forget!
I tested in Chrome as I thought that could be the case and I received a similar error message but referencing JSON. I can dig this out if it helps?
This is probably the issue. Unsure why exactly it is not working for you as I have used this on multiple sites without an issue. I'll look into it and report back.
I'll be happy to help.
- Does this only happen in Safari?
- Does this happen when adding an existing asset or a newly uploaded one? Or both?
- Does the issue still happen if you remove the other plugins?
One of Perch's main selling points is to allow developers create bespoke websites with ease. While Snipcart allows you to easily add a cart to your site, you do give up some control.
I don't think a first-party e-commerce add-on is a bad idea. And while I agree that more examples would help developer (as Clive Walker said), I also think some developers in the Perch community generally underestimate what's required to build an e-commerce site with Perch Shop and end up being frustrated as a result. Familiarity with Perch as well as a good understanding of PHP would've made a big difference in those experiences.
Perch has always given developers a blank canvas more or less. And Perch Shop is no different. It is not a magic solution. You'd still need to understand how to implement and work with:
- User authentication with Perch Members, account area, basic member forms such as profile and password reset, password reset flow including emails
- Perch-templated forms
- HTML forms and what happens when something is submitted
- How PHP handles form submissions
- a list/detail pattern (that actually handles 404 for unmatched items; Perch never did this for you)
- user-filtered lists (forms/links often with dynamic values e.g. categories, and requires understanding filtering in Perch)
- being able to debug PHP issues
- and the list goes on...
I think Perch Shop feels incomplete and lacks in various areas, but I feel people point a lot of blame towards it (and Drew/Rachael) even when they may not have the required skillset to build an e-commerce shop with Perch Shop in the way they envisioned.
It is possible that Perch here excepts all the files to be directly in tempaltes/pages/attributes/. I think the next logical step would be to try to remove the sub-directories and see whether the issue persists:
Creating well-thought-out region that uses blocks seems to be the answer for me.
The default master page for most of marketing sites I build on Runway nowadays is literally just this:
You can enforce design rules and follow brand guidelines. And you're not restricted to content templates. For instance, you can create a "global" block that allows the editor to select a global section (e.g. featured products, latest blog posts, forms, etc): https://grabapipit.com/blog/a-global-block
So I feel what you're asking for is already addressed by Blocks (at least for the most part). If it falls short in some areas, perhaps it is better to explore those areas first.
(maybe even have a code ide built-in
Perhaps a textarea field with a lightweight code editor can be helpful. For example, you may set up a shared region for editors to insert analytics tags like Google Analytics. Or perhaps you have a blog and would like to add custom CSS to style some posts differently.
One of the reason I hated maintaining WordPress sites I inherited was how some of them would have HTML and inlined CSS code inserted via the control panel. I want a CMS to manage content, not code. I want to version control source code and I think storing source code in the database would cause more issues than it solves particularly for client sites.