Leaderboard

Hi Roy, welcome to ProcessWire! ProcessWire likes to remain “markup agnostic”, so it won’t really “generate” this sort of thing for you per se. This leaves you flexible to set up your site the way you deem best. For the carousel you would want to use a javascript solution such as Swiper.js or Slick.js. Whatever you choose will probably have its own expectation of what the markup should look like. On the ProcessWire side of things, it can be as simple as creating an multi-image field for your homepage template and uploading some pics. Outputting the markup for those images is very easy with PW, and PW will help you make sure the images are the right size, aspect ratio, compression and so on. It’s also great for managing further information about the images, such as textual descriptions, licensing info or links. Anyway, depending on your requirements, it obviously doesn’t have to be images from a multi-image field. ProcessWire makes it just as easy to have a carousel of each of your site’s subsection’s main image, or something. Or no images at all. The hard part then is making sure the javascript slider you chose interacts well with the rest of your site and works responsively. These frontend concerns are outside of ProcessWire’s scope. The other thing also depends greatly on your requirements. If you just want some testimonials on your homepage, you might use one of the multi fields (eg. the Repeater field). Editors will be able to add as many customer quotes as they like, and your site might randomly show some number of those. Again, ProcessWire’s role here is to help structure that data and make it accessible to your frontend code, but the HTML and CSS are up to you. Since you mentioned the ProcessWire homepage, I noticed each item has a link to some other part of the site for more information. There are plenty of ways to achieve this and you’ll have to pick the one that’s best for you and your client. ProcessWire’s homepage not only links to various pages but also to specific sections on those pages. Using the central repeater I suggested above, you might add a url field to the repeater and fill it accordingly. This gives you the most freedom: you can put anything in there, even an external link to Youtube. It’s also the worst user experience for your client, who now has to copy and paste stuff from the address bar around (it’s also error prone for this reason). Another option would be to use a page reference field. Now you’re bound to pages on your site and you can even control specifically which pages may be chosen. This will also enable you to select all pages that are referenced on the home page, if you ever need to. Pretty solid. An entirely different approach would be to store this information not on the home page at all, but on the detail pages themselves. You could have a couple of fields on every single page (“attentionblock_title”, “attentionblock_snippet”…) and if they’re filled, you show that page on the home page. It might even be a just checkbox.

@bernhard The YAML recorder and migration of the project.yaml look awesome. Any plans to release these additions to RockMigrations? I think this is a good way to make fields and templates version controlled. Having a feature like the YAML config and recorder added to the core would be a very good thing IMHO. The not programmable definition of fields and templates and migrating contents and structure to a live server is cumbersome (without RockMigrations) and led me to try out alternatives to ProcessWire in the past. I used Statamic and Kirby which both have configuration files for fields/templates, which can be version controlled and I really like the way it's done.

I don't think this is a fair comparison. You can easily create a form, have it submitted (including uploads -> to some tmp folder), create a page if happy with the uploads, save it, move your uploads to the file/image fields, then save again. No orphan pages. I believe your issue is because you are calling $page->getInputfields(). This calls all the fields on that page's template, including your image field. Being a new page, you cannot add (as has been pointed out) to that field unless the page is saved. One reason is that ProcessWire stores a page's files in the page's assets folder (site/assets/files). E.g., site/assets/files/1234/some_image.jpg. Without saving the page first, there is no folder 1234, hence there is no destination for your image. Unless I've forgotten something, this is one of the explanations. Above means that to get around this, create your own form with your own file upload field instead of relying on $page->getInputfields(). This way you can handle the uploads yourself and only create a new page when satisfied with the sanitisation and validation. Alternatively, call $page->getInputfields() with the $fieldName argument (in your case an array) that exclude your image field. I haven't tested this approach, but I think it should work.

Hello Padloper Alpha/Early Beta Testers. Shortly after this post, you will receive an email inviting you to access and test Padloper 2. Thanks! If you don’t receive an email within 2 hours, please let me know. A few things to note before you dive in. What to Expect Padloper 2 is a native ProcessWire module. It is not an SPA. A previous iteration powered by VueJS was discontinued. Instead, there is some sprinkling of htmx, alpine.js and Tailwind CSS here and there. Bugs: how many? We’ll find out soon. There are a lot of bd(), even db() calls left, deliberately, in the code. Most (all?) have been commented out. They have been left in the code for a reason; to help debug the product. A shop app that you can use incrementally. Many of the features are optional and can be left out (or added later) at install. Inbuilt invoice and PayPal payment gateways/systems. The latter uses V2, the latest PayPal SDK. What not to Expect Although it boasts a rich set of features in its current state, a number of features have not yet been implemented. Some have been implemented but not fully, so may not work as expected. In the expression of interest form I listed the features I’d want to implement next. I asked you to express your preference for these. I’ll be guided by your choices when prioritising the next set of features. Implemented but Incomplete Orders (backend) Manual order creation (creating orders via GUI) is incomplete. Actions including print invoice, mark order as complete, etc are incomplete. Products (backend) Product variants should lazy-load when the product is being edited. Currently, they are all loaded and can slow down the page if they are many. Checkout Settings (backend) Some of the settings including abandoned orders follow-up are not yet functional. General Settings (backend) The settings to limit allowed image and file extensions is not yet synced with the respective image and file fields. Shipping Zones (backend) It is not possible to prevent countries from being added to more than one shipping zone. Shipping Rates (frontend) If more than one shipping rate is matched for a customer for a given shipping zone, it is not yet possible to let the customer select their preferred shipping before finishing their checkout. A side note: matched multiple rates can be desirable in cases you want to offer more than one delivery method to your customers, e.g. a free but slower shipping and a faster but paid-for delivery. Downloads (frontend) Delivery of digital products is incomplete. Not Yet Implemented Access (backend) Access control via permissions and/or roles not yet ready. Other Desirables Not in any particular order and planned for future release(s). Bulk product images management Customer management Discounts Staff management Shipping classes Notifications management Detailed Analytics Additional in-built Payment Gateways (Stripe, etc.). Better management of abandoned baskets Invoice generation and management Known Issues PayPal showing lots of JavaScript console errors. These are all related to CORS as far as I can tell. PayPal struggling with some floats (prices). It will crash and payment will fail. Maybe this could be solved by charging in cents (in PayPal) but I haven’t yet found a way to do this in V2. If you have any questions please ask here. I will contact you later for where and how to report bugs. Please don’t use this thread for that. For generic issues, such as not being able to install, etc., please let me know in this thread. Thanks and happy testing!

Hi Jan Romero, Thanks for posting about swiper.js - really stands out from the usual carousel/sliders

Hi @adrian, I think this probably isn't a Tracy issue as such but I thought you might have some insight on it... If I edit a field's settings (in this case the headline field) and set it to Autojoin then when I get a page whose template has that field then I can see the field value loaded on the Page object. But if I don't set Autojoin in the field settings and instead I set the field to join for a specific find() operation then I don't see the field value loaded on the Page object. (I'm using $pages->get() here but I think it is the same behind the scenes and I also tried $pages->find() and found the same issue). Or the older way: If I request the field value before I dump the Page object then it is loaded. I'm puzzled about why this is. Surely if the field value is joined during the find() then it must be stored somewhere on the Page object? Do you know if PW is storing these joined values somewhere that is invisible to Tracy? Or is this maybe a sign that there's a core bug and the joined fields are not actually being preloaded as expected?

I've added it to the latest version. Thanks for noticing this - I think there might be other things that could have been confusing as it was, so I think this is a good improvement.

Sounds good to me, because although the cached pages are expected when you know how PW goes to the cache first before loading pages from the DB this might not be common knowledge and the expectation is probably that the Console is a "blank slate".

Turns out with your "get" version, you can also use getFresh() and it will work. Although I actually think this is kind of a bug in the Console panel. What do you think about me replacing line 73 of CodeProcessor.php with: $setVars = '$page = $pages->get('.$page->id.'); $pages->uncacheAll();';

You nailed it! I was trying that code from the Tracy Console while viewing the page in Page Edit, and so must have been getting the cached version of the page that was already loaded. If I use the Console on a different page or preceed the code with $pages->uncacheAll() then it works as expected. Thanks!

Hi @Robin S - not completely sure, but here's a little more insight: This version shows that it is theoretically joining the "summary" field, and if I look at the Selector Queries section of the Debug Mode panel, I see: which shows that it is being joined as expected. Now if I do this same find operation in a template file, I get: Sorry for the rambling, but I am posting as I try new things :) I've noticed that if I run this via the Tracy console it actually does work as expected depending on what page you are on. It seems like it works anywhere on the frontend and anywhere on the backend, except when editing a page (which is what I was doing for my first test above). For example, you can see it working when viewing the page tree. Actually, it even seems to work when editing some page, but not all. What page / view are you on when testing and does that impact what you see?

Hi Marco, It would be great to have a quick way to add "Paypal" as a payment gateway easily to Processwire and I am looking forward to trying out your new module when it is compete. In the meantime, I have been using an insecure method, but one that has not yet been abused to take a simple transaction with "Paypal". It does not handshake with Paypal, but does know the url of the site page that it is called from and appears to work quite well in practice. Although, it is not exactly comprehensive it does take you to a "Paypal" shopping cart that takes care of multiple instances of different products doing all the hard work. All you need is a "Paypal" email address a product description, a price and set the currency. Obviously, it does not remove stock or accomplish many of the more comprehensive objectives regarding taxes and shipping, but as long as you populate the fields, which could be dynamically from Processwire, you can make a sale and "Paypal" keeps all the records. The image for the "Purchase" is Bootstrap based, but you can replace this with your own image or styling. Here is the Processwire Paypal Gateway code to cut-and-paste into any page template :- <form target="paypal" action="https://www.paypal.com/cgi-bin/webscr" method="post"> <!-- Identify your business so that you can collect the payments. --> <input type="hidden" name="business" value="YOUR_PAYPAL_EMAIL_ADDRESS"> <!-- Specify a PayPal Shopping Cart Add to Cart button. --> <input type="hidden" name="cmd" value="_cart"> <input type="hidden" name="add" value="1"> <!-- Specify details about the item that buyers will purchase. --> <input type="hidden" name="item_name" value="YOUR PRODUCT DESCRIPTION - INCLUDE shipping in TOTAL"> <input type="hidden" name="amount" value="150"> <input type="hidden" name="currency_code" value="GBP"> <!-- Display the payment button. --> <input class="btn btn-primary btn--pp img-responsive" style="margin: 0 auto;" type="submit" name="submit" value="Purchase"> <img alt="" src="https://www.paypalobjects.com/en_US/i/scr/pixel.gif" width="1" height="1"> </form> This could be developed further if necessary to include more features, but maybe it is better to wait for your module? Regards, Hackasacka

@ryan - I wonder if it would be possible to also get the template name in the returned array? I need this to be able to group results. I also need to the know the parent template name - could it be possible to have a sub array with details about the parent included for each result? The other thing that I am struggling with is sorting the results. Obviously there are PHP ways to do this, but it would be great if PW's sort method was available here as well. To give you a bigger picture, I am trying to convert: $references = $page->references('has_parent!=1051, sort=template'); $references->sort('template, -date, -start_date, -year, -year_rt, -parent.month, title'); to use findRaw() with the new references option. For this sort to work, I actually also need to be able to sort via the "month" field in the parent. I am guessing you'll say that this is beyond the scope of findRaw() which might be fair, but I thought I'd provide a real world use case where this takes the query time from: 1260.47 ms, 14.2 MB down to 297.23 ms, 854.6 KB so it's a huge performance gain if it can be made to work.

Hi @rick As error says, a page should be saved before adding to or accessing files from it. Take a look at this thread Probably you have to check for $page->isNew() and $page->id or just save a page before doing somting with files field like $uploadpage = new Page(); $uploadpage->template = "upload-entry"; $uploadpage->title = date("d-m-Y H:i:s") . " - " . uniqid(); $uploadpage->save(); //save page before adding files $uploadpage->images->add($upload_path . $file); // save uploaded files to new page $uploadpage->save(); I don't know the context of your code as the code itself, so it quite hard to say someting more.

Hello, @Frank Schneider! The code is: $content = str_replace('xName', 'something', $content); Have a nice day!

@elabx Craft CMS ? I'm also trying to move towards static site generator and headless and/or git-based CMS (like Forestry or Netlify CMS). My personal websites are built with SSG and hosted for free on Netlify (processwire.dev & mehrlicht.photos) – though those don't use a CMS at all. But most of the tools for the SSG/Jamstack approach are built to accomodate version control from the ground up. I've been eyeing Prismic, hopefully I'll get a project soon where I can try that out. Though it's hard to find clients for static sites + CMS right now, most have never heard of it … @benbyf Drupal 8/9 has that as well, Configuration Synchronization, but it's a pain to use (like Drupal itself). Luckily I migrated the last Drupal project I had to actively support away from Drupal and to Craft CMS last year ? @bernhard Thanks a lot for the detailed explanation and all the code examples! For the next bigger ProcessWire project, if there is one, I'll be sure to use RockMigrations. Sounds like it solves my problem regarding project schema / config well. But there's still a cost associated with this – every developer needs to know how to use it and not shoot themselves in the foot. How does a new developer install and work on the project from the repository? Is it as simple as composer install, php craft install, npm ci, npm run build? Because every additional step is something we don't have to do when using a CMS with first-party git support. For example, how do you install ProcessWire in this case? Manually? That's work I don't have to do if I can just composer install. Sure, I can hook something up to install ProcessWire using composer scripts on install (in fact, I have done something like this for our starter template which is under version control). But now I have a custom script that I need to maintain, fix if it breaks. Or I put the core in my version control, which means I have to litter my version history with core files. (BTW I could use git submodules but somehow nobody knows they're a thing ?) There are more issues like this as I mentioned (e.g. the issue regarding default selected pages in page reference fields; folders containing a mix of files that should and shouldn't be in version control; modules that don't use composer, …). Every one of those can be solved. But every solve either comes with some trade-off (like keeping not project related files in git) or with a maintenance cost and learning curve for a custom solution. And that's a hard sell if there are systems that don't require all that work. Beyond that, I have zero guarantees from the core that all those custom solutions will still work with the next core version (the lack of semantic versioning for the ProcessWire core doesn't help either). There are also side-effects to there not being explicit support from the core regarding those setups – for example, if we want to outsource something to an external developer or train a new hire, we can't just point them to the ProcessWire docs, but have to teach 'the way' to them. For Craft projects, we just follow the standards. Besides the problems I mentioned, there are also advantages that come from the fact that Craft supports version control explicitly and is geared towards it. For example, the production site will not allow any configuration changes (new fields, setting changes, etc) by default. So I have a guarantee that that the configuration will be exactly as I left it so I can deploy with confidence from the repository. With ProcessWire, I don't have a guarantee that nobody has changed some field setting in production while I was on holiday. Of course, not changing stuff in production can be established as a rule, but it's again something to be consciously aware of and enforce, instead of having the system enforce it. I feel like there isn't one single answer to this debate. I hear you – it's easier to complain than work on solutions. Not every project needs a totally 'clean' version control. Trade-offs are acceptable and arguably what we are paid for. I think there's room for multiple CMS with maybe slightly different focus. Right now I'm in the planning stage for a new ProcessWire project that I'm looking forward to. It's just a matter of using different tools depending on the job, no need for a single CMS to rule them all ? Not sure I understand the problem; with Craft, the project config is always the source of truth and the interface is just window dressing to edit the project config. If you're using external modules, they have to be built to support project config, but most plugins are by now. I have said that myself ? After having supported a larger project with regular updates for a while now, which is a bit of a pain. Maybe it would go better if we'd used RockMigrations from the start! Hindsight is 20/20 … @Robin S I'll try to get around to that comparison between Craft CMS and ProcessWire, which would include all the issues regarding version control. But knowing me and my tendency of feature-creep for articles that might take a while ?

This would be some kind of a dream for me to have in ProcessWire. Wasn't there a Wishlist somewhere for features to include in PW that @ryan takes as a kind of inspiration? If I could I vote for something like that 100 times TBH.

@adrian Last year we've started using Craft CMS for some new projects, which has full support for version control out of the box. In terms of feature set it's quite similar to ProcessWire – you can define your own fields and entry types (similar to ProcessWire templates) and create custom field layouts. It's not a flat-file system, it does use a database. It also provides an API similar to ProcessWire's $pages to query for entries (pages) or other data. To keep track of schema changes, Craft saves all fields and entry type (and every other setting / config) as YAML files in a config folder. Those can be version controlled, merged and reasoned about easily. You can even read a pull request in Github and see what changes it introduces to field/entry type settings, it's great. It's called project config, here's the documentation. Particularly pleasant is that you can still use the backend to create fields and field layouts – every change in the backend is automatically written to the config folder. So you can just create field layouts in the backend and everything you need to track it in git is already there when you're done. To propagate changes between environments, the CLI has commands to apply the project config to the current environment (database). I was thinking about writing a comparison between ProcessWire and Craft CMS regarding feature set, support for version control and development experiences. There are some good ideas there that ProcessWire could really benefit from. BTW, if you want to track content in git as well as configuration – we also looked at Statamic, which does support flat files and can commit every backend edit to git. Haven't tried it though. @szabesz Not sure if it's that easy, making every aspect of ProcessWire version control friendly would require massive reworks. Including making ProcessWire and it's module installable through Composer and reworking the directory structure to have a better distinction between content and config, as well as dependencies and custom code. This would need to be ProcessWire 4 (at least). Not sure this can be done if ryan isn't looking to put massive amounts of work into this. I don't have the impression that this is the direction ProcessWire is going – though I'm happy to be proven wrong.

Welcome to PHP lol https://www.php.net/manual/function.preg-replace.php https://www.php.net/manual/function.str-ireplace.php https://www.php.net/manual/function.str-replace.php https://www.php.net/manual/function.mb-ereg-replace.php (just use this) https://www.php.net/manual/function.mb-eregi-replace.php (or this) https://www.php.net/manual/function.mb-ereg-replace-callback.php https://www.php.net/manual/function.substr-replace.php https://www.php.net/manual/function.preg-replace-callback.php https://www.php.net/manual/function.preg-replace-callback-array.php