Leaderboard

I still use 2012 code from time to time, it make me also smile when it happen. About the tutorials, a real website, it depend what you call a real website. (I am not being rude, and I get your point, but I think that the tutorials need be done by the community, maybe we should follow an official guidelines). For example, for me, you would need to put your hand in Vite, Svelte, and how to mix them with ProcessWire to get data which mean to build a module that will inject custom headers, or use an internal API, and make yo call ProcessWire Headless cms things. For others devs, it could be other stack / frameworks, and we all know there is a ton of them. So you end up in what PW is the best => freedom, and I think IMO that it will be hard to satisfy everyone. ? For beginners, there is some good up-to-date doc, like https://processwire.com/blog/posts/starting-with-the-blank-profile/ and also tutorials - https://processwire.com/docs/tutorials/ - and for a real damn good example real website, the update profile SkyScraper which can be visited there http://demo.processwire.com/ , downloaded, dissected and modified. Maybe, again, the real need is to organize better what's already exist.

Hi, I get the impression that we're missing a "proper" tutorial here. In my opinion, what we have here are bits and bytes that are out of date. It would be nice to have a "complete" and updated tutorial on how to build a "real" website. What are your opinions? Cheers, B

There is a relatively new official solution ? https://processwire.com/blog/posts/language-field-export-import/

Never used that CRM before, but looking briefly at the Zoho docs I've found something you could take as a starting point, maybe? https://www.zoho.com/crm/developer/docs/php-sdk/v2/user-samples.html?src=add_user

@gebeer there you go: https://github.com/davidhellmann/tailwindcss-fluid-type https://play.tailwindcss.com/TegGD6vkSM

You could use it with your RockFrontend UIKit setup because that is based on LESS. But you would have to introduce npm based packages into RockFrontend Unfortunately, they don't provide a pure CSS version of RFS. So I can't integrate it with RockFrontendTailwind since that purposefully uses pure CSS in a PostCSS based build pipeline. Thank you for the links. How would a living Tailwind implementation look like, defining the calculated poly fluid sized font sizes in tailwind.config.js? I like that pure CSS approach. Well thought out. Personally, I also base font sizes, paddings and margins on rem in most cases.

@BrendonKoz Container queries have been on the CSS agenda for a long time. At present the @container rule has limited browser support but it's definitely on its way. See https://caniuse.com/?search=%40container

Until we might have a native method for migrations, I encourage you to checkout the great RockMigrations module. With the module you can have one or multiple migration files, that handle all the stuff mentioned above, like adding fields, adding templates, creating pages with content and setting roles. As the migrations are file-based they are also version-controllable. It is also a hassle-free setup and very easy. This makes it easy to work on a feature in a different branch which requires to have other fields/template than in the main branch. Now you can switch between branches and always have the required fields and templates. This is a huge time and workflow improvement. @bernhard steadily improves his module, and me and other contributors try to enhance it, or give feedback.

Typography is not a simple topic but I'll try to explain how I use it. But first, the difference between EM/REM. Generally, an EM got it roots in print where it refers to the width of the upper-case M. When css came about, they changed it to refer to a relationship of the parent element. By default, one EM generally is 16 pixels in the browser world. The REM (Root EM) is in relation to the root (usually the HTML definition if no ::root{} is defined) font size as you have defined in CSS. Some inconsistency -- You can use both EM and REM in margin/padding definitions. However, when using EM as the unit in a margin definition it looks only at the current element; It does not refer back up to a parent. This is not the case with REMs. The REM declaration is always looking at the root. // EM html { font-size: 16px; } article { font-size: 20px; } p { font-size: 1.1em; margin-bottom: 1em; } <article> This is 20px. <p>This is 1.1 x 20px. The bottom margin is 1.1em regardless of parent font size setting.</p> </article> // REM html { font-size: 18px; } article { font-size: 20px; } p { font-size: 1.1rem; margin-bottom: 1rem; } <article> This is 20px. <p>This is 1.1 x 18px. The bottom margin is 1 x 18px.</p> </article> The viewport width/height (VW/VH) allows for a 'fluid' scaling. However, the drawback is that smaller devices will not zoom in or out should the font size scale too small. Also, on very wide screens this scaling would likely make the text way too big, to the point of interfering with other content. My method: I define my base font size as 16px (usually the browser default). I also include variables to make future changes very simple. I put my font size break points at the top of my css file (usually after ::ROOT{} ) so that I don't have to go hunting should I need to change something. To avoid the confusion between parent references, I define all font sizes, margins, paddings, widths, etc. in REMs, except for the base ::root{} definition which is in pixels. :root { --fs-norm: 1rem; // defaults to browser's font-size definition --fs-big: 2rem; --fs-hdg: clamp(3.5rem, 10vw + 1rem, 14rem); // This sets the min and max font-sizes and scales in between } @media (min-width: 40rem) { :root { --fs-norm: 1.125rem; --fs-big: 3rem; } } body { font-size: var(--fs-norm); line-height: 1.6; } h1 { font-size: var(--fs-hdg); text-transform: uppercase; } I hope this helps. Like I said, this isn't a simple topic where you can say, "Use x because...". ps. Not a front-end guru so others may have a better reply.

@maddmac Yes. Though currently they are a FieldtypeOptions field, but can be changed/added to just as easily. Still, maybe I should convert from Options to Page fields for stuff like this. @MarkE A module is something you might integrate into an existing project. I see this instead as a separate app and not something that you integrate into an existing website or project. Though extending it into a new project, using it as a starting point, building on top of it, etc., is definitely the purpose of any site profile. Though this particular site profile is one that you might use as-is, or extend it, depending on your needs. @fuzenco I currently have 2 versions of the default invoice template. One is using Uikit 3 markup. The second is using email-friendly plain HTML and a tool that converts class attributes to inline styles at render time for broad email compatibility. When you send an email, it uses the invoice email template and when you view or send the client the URL it uses the Uikit template. Either can be printed to PDF in your browser, but generating PDFs isn't built-in to the site profile (at least not yet). Yeah these are already features of Stripe. Handling payments isn't really my expertise and other than that I know how to work with Stripe reasonably well, so that's the direction I'd take for that. Though all my clients pay by check or bank transfer so not sure I'll be using the feature myself. @dragan I don't know anything about VAT, so am not sure what that entails. Though I understand it's something tax related and think it would be fairly simple to integrate tax related things. I'll have to research it further, though that may be something we leave for people to add on their own according to their own needs. @teppo That's an interesting idea! I'll have to look at what Antti did with that. Though I do wonder to what extent people need payment processing with invoices. It hasn't been part of the invoice services I've used to date. With an online store it's very much connected, but with an invoice it kind of depends how you bill or whether you use credit cards at all. I don't use credit cards for client billing because it's not worth the fees. If I charge $5k for a web development project, then Stripe's cut would be $200, which is significant. I'd rather just have the client send me a check or bank transfer, no fees. But for smaller stuff, I do think it would be nice to have the credit card option built-in.

When I use the menu-builder then I have to give a link to a page for each entry. In this case I give the link to the startpage in the specified language e.g. /startpage/en for english language. I found no way to stay on the active page but in a different language. In the past I used the language switcher that you proposed. But it can not be part of the main menu. That is the problem.

Hi everybody. I refresh this old thread because I had also the same issue. For the solution I have found (don't remember where*): echo $option->getTitle(); For me it works fine, hope to be helpful. *found here, thanks @schwarzdesign :