Leaderboard

I do it essentially the same as what @TomPich said, but on the first move from local to remote I find it's a lot faster and more reliable to compress all the website files to a ZIP archive, upload that to the remote server, then extract it on the server. If you're using cPanel then the included File Manager is a convenient way to upload and extract. And when using a host that doesn't include a file manager I like to use TinyFileManager, although you need to take due care with security - as extra protection I rename the containing folder to include a dot prefix to prevent access when I'm not actively using it.

Just to update, it didn't really take me long to get the hang of the basics of Processwire, I found the Hello Worlds tutorial really useful to get the general idea, and also found the docs were pretty good. I'm pretty sure I'm only using Processwire at a tiny fraction of its capabilities, but I've managed to make a site for a client where they can update their blog themselves, and didn't have any issues I couldn't resolve by searching the forums, the community seems really great and looks like it has been great for years. Thanks very much to everyone for your helpful advice and pointers.

It is. Next revision will truly be passthrough in that it adds HTMX and then returns the FormBuilder instance so you can continue to use all of the built in methods, including rendering FormBuilder scripts and styles- so a true drop-in replacement. Appreciate your feedback and help with making this module better!

Great stuff! Thanks for this @ryan! I think that another great thing to have would be custom repeater item actions. As far as I understand, we now cannot add any of these. But they could be as useful. Especially for repeater matrix based content builder setups.

If you prefer one-liners: <?php // https://processwire.com/api/ref/wire-array/each/ echo $pages->find('template=faq')->each("<div><h2>{question}</h2>{answer}</div>\n"); ?

FieldtypeFormSelect lets you create fields to select from forms created using the pro FormBuilder module. Features: Create select fields that allow for choosing forms when editing pages Fully compatible with FormBuilder, render forms using native methods Choose which forms will be available to choose from, each field is configured individually Choose how form names will be presented in select elements Compatible with FormBuilderHtmx FieldtypeFormSelect lets you create fields like this, configured as desired. Choose which forms will be present. Including forms where names start/end or contain a value allows you to create a form select field once then use form names to help group them together, or add/remove them from form selects without editing the field. This is also a pretty simple way to allow end users to create forms that will be selectable without having to edit a field configuration. For example, this field will only allow you to choose forms having names ending with "request", so "customer-support-request" and "consultation-request" will be included, but where forms with names like "newsletter-signup" and "call-to-action" won't. Choose how you would like the form names to be presented in the select element. They can be shown as they are originally named, as spaced words, or as capitalized/spaced words. Rendering in your templates is straightforward <?php $page->select_a_form; // => A form ID, or null if no form has been selected // Render using the native FormBuilder method echo $forms->render($page->select_a_form); // Alternate method. Selected form will be rendered, if no form is selected output is null. echo $page->render('select_a_form'); Form select fields store the ID of the selected form and FieldtypeFormSelect makes use of ProcessWire's built-in field rendering to keep things simple. The fields you create will always be up-to-date with the forms as they currently exist. If a form is deleted that has been selected in one or more fields, those values will be set to null so you won't experience any issues with references to form IDs that no longer exist. Your templates and pages stay free from errors. My primary use is to have a form select field available for blocks created in the RockPageBuilder module by @bernhard. I want each section on the page to contain an option to choose any form that will open in a modal to put the power of choosing forms in the hands of the user. RockPageBuilder is not required, but makes for a powerful example. Contributions and issues are welcome on Github, or stop by here for some help! Install as a ProcessWire module Install via Composer Download from the Github repository Cheers!

Nowadays, I might not be a huge fan of how ProcessWire evolved outside the "composer ecosystem", I also feel it might drive people away too. To put an example, popular http clients. Those seem to be very prevalent in its use along a plethora of projects (Guzzle/Symfony HTTP) and their "ergonomy" sometimes is almost like a standard ( i mean some part of it is with PSR haha), I feel PHP devs in general might get turned off very much a project with their own implementation of HTTP client, where they have to figure out how to use it or implement their own modules outside of the PSR-18 scope. Talking about PSR compliance, that could be another topic in itself. Personally, none of this matters to me much. I was kind of "raised by ProcessWire" and it always felt very empowering to be able to read the ProcessWire source code, this is the main thing I've always personally liked about ProcessWire's cohesive (?) and self contained core . Maybe a more experience dev would call me naive? Maybe the lack of experience working on larger teams/codebases, biases my opinion to not care (THAT much) about being more "embedded into the php ecosystem". All these issues probably fall beyond my expertise , I just have a lot of fun building things with ProcessWire ?, need no more than that. Edit: Also let's put in perspective that ProcessWire is older than composer. Would love to hear the opinions of others as well!

@Sanyaissues Indeed. It had been working in my use case, but this issue came up with another person using the module and I'm working on a fix. So, fix and improvements are on the way.

I don't think it's off, because in ProcessWire we have both the Frontend and the Backend. As far as my research took me I don't think that Strapi offers that, does it? So you have to build your frontend on your own, add another tool and tech stack...

I guess static really takes you long ways don't you think?? Kind of the same reason why ProCache is so successful and clouflare is a go-to solution to make any site faster. Regular PHP can get resource intensive, I've experienced this a bit when having to do this 404 optimization , being hit by some bot still crawling wp-content/whatever.jpg it can choke a small server with relatively few concurrent requests. I'm nowhere close an expert at server optimization and leave this all to a 3rd parties like ploi when I can, so there's that too to consider along my experiences. Maybe I'm just cheap on servers ? How to make PW more compatible with JS Frontend Frameworks? Seems like similar CMSs with data-first approach like ProcessWire are using GraphQL for this purpose, and the modules in the ecosystem implement GraphQL queries too. In general the whole static js sites, api first approach seems way out of the league of the things I do, small to mid size corporate sites. Just thinking of adding a whole static project, with it's own dependencies, etc, it starts adding to the maintenance list lol.

(deleted)

Hello @dan222 and welcome to this forum! To push a site online : go to your db manager on laragon and export your db as a sql file then, from your hosting control panel, create a db (or empty it if it already exists) and import your local db with FTP, copy your local files in your hosting folder for your site (don’t forget to change the database config in /site/config.php file) And that’s all. ? Now, you can be a bit more efficient by using an "if" statement for your database config, so that you don’t have to worry about changing them when you push your site online (see below) using ssh/rsync to synchronize your local and distant files I’m sure you can optimize database export/import too, I didn’t dig in yet... // db config online / on localhost if ( $_SERVER["HTTP_HOST"] === "my-online-url.com") { $config->dbHost = '...'; $config->dbName = '...'; $config->dbUser = '...'; $config->dbPass = '...'; } else { $config->dbHost = 'localhost'; $config->dbName = 'my-local-dbname'; $config->dbUser = 'root'; $config->dbPass = ''; } $config->dbPort = '3306'; I generally need 4 minutes to pull or push a website after or before working on it, if it involves db update. If it’s only changes in files, it’s done in 10-15 seconds.

I was playing around with this today. A few things I noticed. ->styles and ->scripts return null, but I could pull the original form output and use the extractions from there. I get an AJAX response and the submission works, but the parsing of the whole page object returned didn't seem to work (the whole page replaced the original form on the page). I don't have any PR yet, just going to tinker now, but thought I'd report my findings. I should comment - I am using latte templates for output. I may need to hook into output markup somehow.

This week the core dev branch version remains at 3.0.239 but relative to last week, it contains several optimizations and improvements. Details can be found in the dev branch commit log. I've also moved two Textformatter modules out of ProFields and into GitHub and the modules directory. These include: Auto Links This Textformatter module automatically links your specified phrases/words to your specified URLs. This is a potential SEO and accessibility tool for creating automatic contextual links with little effort. If there are pages that you commonly link to in your site from your textarea/rich text fields, then this Textformatter can save you some effort, automatically linking to those URLs. Text Blocks This Textformatter module enables you to assign a name to any block/region of text in a Textarea field. They are defined by typing start_name where you want the block to start, and stop_name where you want the block to stop. The block(s) of text can then be shown in any other Textarea field at runtime (site-wide) simply by typing the block name on its own line in the format show_name. Note that the word "name" in all of these examples would be whatever you've decided to name the block. Both modules have been updated just for public release with a new version. Both are considered Stable, as they have both been running without incident for several years. These modules were moved from ProFields to the public modules directory for three reasons. First is that they don't consume hardly any support resources, so they don't need to be commercially supported modules anymore. Second is that I'd like to keep ProFields focused more on field related modules (Fieldtype, Inputfield, and related) rather than Textformatter modules. Though admittedly the TextBlocks module does blur the line a bit, as it promotes potential greater reusability with existing Textarea/TinyMCE/CKEditor fields. Third is that there's already a lot in ProFields and I wanted to make room for new modules, such as the recently added PageEditChildren, which is part of ProFields at least in the short term. The FunctionalFields module may come out of ProFields well, as it hasn't required much in terms of support resources recently, though it is a useful Fieldtype/Inputfield module that is very much in keeping with the theme of ProFields, so I'm still debating on that one. Thanks for reading and have a great weekend!

@mel47, currently the PW core does not support showIf or requiredIf in custom fields for files/images. See this issue: https://github.com/processwire/processwire-issues/issues/1889 And even if that issue is resolved, the way the core is handling showIf/requiredIf at the moment means that it will only evaluate the showIf/requiredIf based on values of other custom fields for the image/file item, not fields in the page that is open in Page Edit. But I've just updated the CustomInputfieldDependencies module so that it should handle your case. Please update the module to v0.3.0 and test it again.

Hey @netcarver and @gebeer great news for you (and all RockFrontend users) I've fixed an issue with ajax endpoints not replacing ALFRED markup (thx for the report @gebeer) and while working on that I got quite a lot of errors in the console about the livereload stream having a wrong mimetype, which has also been observed and reported by @netcarver some time ago. So I fixed that as well ? Please try the latest version on the dev branch, which will be merged to master in some days. LiveReload only reloads the visible tab. This is to avoid endless loops where one window reload causes the other one to reload as well and vice versa. In older versions you had to reload the tab manually once you switched back to it. In the latest version it will wait and as soon as you switch back to the tab it will be reloaded automatically if a file changed in the meantime ?

Hello @Andy The issue is fixed now inside Form.php Please replace this file with yours, if you do not want to wait until the next update: https://github.com/juergenweb/FrontendForms/blob/main/Formelements/Form.php BTW, the version on GitHub is actually 2.1.78 with a lot of new additions, but I have not updated the version number, because it needs a little bit more testing. So it is really cool, if users like you discover some problems before the version number will be updated ?

Hello @kaz, Conditional Check within the Included File (businesshours.php). try to Modify businesshours.php to check if the current page ID should display the address. <?php if (!isset($global->businesshours) || $page->id != 1127) { // Display the business hours content echo $global->businesshours; } ?> Use an if statement before the include to check the page ID. kynect <?php if ($page->id != 1127) { include('businesshours.php'); } ?> If you have multiple places where you want to conditionally include or exclude the business hours based on the page ID, consider modifying businesshours.php for a reusable solution. If this is a one-time case for page 1127, using a conditional include might be simpler.

Also want to point out how the video clearly shows that if you write PHP, a very fast and expensive sports car will show up in your garage. You can't argue with that, it's right there next to his big reaction face.

I'll go ahead and invite myself to share some JS thoughts nobody asked for... The don't-reinvent-the-wheel message in the "Do not use React Server Components" video is good, but I think there's a lot more to it when it comes to full stack JS overall. Not only are JS devs largely solving problems that have already be solved, the JS ecosystem is constantly solving problems that it causes for itself. Obviously new features can cause issues to address- but it feels like JS really takes the cake on this one. Hydration and rendering issues were pretty much inevitable when you start overloading the front end and forcing the browser to do so much heavy lifting. Wait... sending a blank page that waits for JavaScript murdered your SEO?! Rendering pages on the server is relatively simple, rendering them in the browser- boy howdy... So then the JS devs cheered when it invented server side rendering... for JavaScript. Then there's the bundle sizes, which is noted in this article about React Server Components: So now they're solving for asset sizes, another layer of complexity to solve an issue that didn't exist (at the level it does now) until massive front end frameworks caused them. We used to worry (showing my age here) about jQuery library sizes... React is excited about saving 240k while the entire jQuery library is 85.4k (uncompressed), and all you have to do is redesign your app architecture with server side JS! BRILLIANT! Before someone interjects to correct me, I'm not saying that React and jQuery are the same, or comparable in functionality and purpose. I am saying that the JavaScript-first approach allowed a lot of people to accept compromises to create the Next Hot Thing™ and a lot of problems with it. JavaScript on the server pretty much just made this more complex by providing increasingly complex ways to make itself more complex- lol, recursion. "But", the full stack JS dev will say, "you can use the same language everywhere so there's consistency." My brother in Christ, you don't even import code between files the same way in Node and and client side ES6. So when I read this in that video: This is from a developer who goes to bed at night thinking about how their Next.js application codebase might be outdated by the time it launches. Then I go back to feeling like this: I used to kind of stress about not pursuing full stack JS, then I realized that I'm happy. Having a front end (whether SSR or a JS framework) and a back end (CMF or non-js app framework) keeps me sane. I know where things go, what they do, and why. There's consistency between projects. It's easier to maintain best practices. My NPM headaches are smaller. My PHP doesn't need nodemon or pm2 to restart the server application if there's a JS error. The amount of documentation I read that has a big red box in the middle saying "Note: this thing that you've built several apps with and know well is going away. We're destroying it because someone on Github said we need to move to stateless functions. Soon there will be pain, and you will cry." is very limited. I made that one up, but you get the idea. I'm not dragging front-end JS frameworks per se, but making the case for why they should not pave the way to the JS-ification of all that is holy and aren't automatically better. Maybe putting JS everywhere has made SPA solutions worse because they didn't leverage how well traditional server side languages worked already. Went off on a tangent here, but I've had a few moments of zen this year about being a PHP developer and wanted to share the energy. All that aside, to answer your question @wbmnfktr I've wanted to pair up a front end framework with PW but haven't had the time or right project to give it a try with. I do like the idea of using PW as a JSON delivery backend in general.

Since this thread was started a hasPage property has been added to Inputfield instances in PW. So you can do this: $wire->addHookBefore('Inputfield::render', function(HookEvent $event) { /* @var Inputfield $inputfield */ $inputfield = $event->object; $page = $inputfield->hasPage; if($page) { // Use $page bd($page->name, 'page name'); } });