Leaderboard
Popular Content
Showing content with the highest reputation on 04/17/2023 in all areas
-
Hello, We've recently been researching how to use ProcessWire in a horizontal scaling environment (multiple server instances using a load balanced, read replica databases), and ran an experiment using AWS Elastic Beanstalk. Getting read replica databases up and running was easy - it's built in to the core: https://processwire.com/blog/posts/pw-3.0.175/#how-to-use-it-in-processwire Using multiple server instances throws up one big problem: how to keep the filesystem on multiple instances in sync given that ProcessWire doesn't currently support using an external service (like s3 or EFS) as the filesystem. The solution that we came up with is to use various Cloudflare services (R2, Stream, Images) to serve file assets, and we've built a module to facilitate this: We're not using this in production yet, but our tests on EB were successful, and we're confident this will solve the main part of this problem. However the Cloudflare Images service is still quite new and there's still features to be rolled out (e.g. webP for flexible variants) so it can't be considered a complete solution yet. Additionally, we use ProCache and this presents an additional multi-instance problem - if the cache is cleared on one, how can we clear it on all? Our solution is to log clears in the database and use this to sync up clearing. We built another module: Again this worked well in our test, but isn't yet being used in production. The main purpose of this thread, aside from sharing these potential solutions, is to ask for and discuss other experiences of hosting ProcessWire in a horizontal scaling environment. What solutions did you come up with (if you want to share them) and are there other potential issues we maybe haven't thought about? Cheers, Chris5 points
-
A module for ProcessWire CMS to integrate a user registration/login functionality based on the FrontendForms module. This module creates pages and templates during the installation for faster development. The intention for the development of such a module was to provide a ready-to-use solution for user management, which can be installed and put into operation in a few minutes. It works out of the box, but it provides a lot of configuration settings in the backend: Highlights "One-click" integration of an user login/registration system without the hazzle of creating all pages and forms by hand "One-click" switch between login or login and registration option Double opt-in with activation link on new registrations Option for automatic sending of reminder mails, if account activation is still pending Option for automatic deletion of unverified accounts after a certain time to prevent unused accounts Option to use TFA-Email if installed for higher security on login Mutli-language Select if you want to login with username and password or email and password Select the desired roles for newly created users Select, which fields of the user template should be displayed on the registration and profile form (beside the mandatory fields). Fields and order can be changed via drag and drop functionality Offer users the possibility to delete their account in the members area using a deletion link with time expiration Customize the texts of the emails which will be send by this module Usage of all the benefits of FrontendForms (fe. CAPTCHA, various security settings,...) Support for SeoMaestro if installed Lock accounts if suspicious login attempts were made Support of Ajax form submission This module runs on top of the FrontendForms module, so please download and install this module first. UPDATE 03.11.2023: The module is now available inside the Processwire modules directory: Frontendloginregister This module is early Beta stage, so please do not use it on live sites at the moment. If you discover any issues, please report them directly on GitHub ?. Thanks!3 points
-
Extends Pagefile to use Cloudflare Images, Stream and R2 storage to serve files. https://github.com/nbcommunication/CloudflareAssets The main purpose of this module is to allow ProcessWire to be used in an auto-scaling multi-instance environment. By serving file assets from Cloudflare, it is not necessary to have all file assets copied to all instances and we also get the benefits of serving assets from a CDN. How it works When a Pagefile is added in the admin or via the API, it is uploaded to Cloudflare's R2 storage service. Additionally, if the file is an image, it is uploaded to Cloudflare Images, and if the file is a video it is uploaded to Cloudflare Stream. When a URL for the Pagefile is requested e.g. $pagefile->url(), the appropriate Cloudflare URL is returned. As ProcessWire's admin still requires the file to be available locally, in a multi-instance setup if a file is not available it is downloaded from the 'master' copy in R2. This module is not yet being used in production. There may be changes to how Images work in the coming months as features are still being rolled out to this Cloudflare service. Cheers, Chris3 points
-
Purge the StackPath CDN cache when ProCache clears. https://github.com/nbcommunication/ProCacheStackPath If you use StackPath's CDN to deliver your website, you need a way to clear its cache when ProCache clears. This module connects with your StackPath stack via the StackPath API and when ProCache clears it requests StackPath clear the cache, attempting to respect the specific rules (Parents, Family, Children etc) set up in ProCache. This module is being using in production but only for a couple of sites that just clear the whole cache when a page is saved. The implementation of the Parents / Family / Children rules haven't been fully tested, and it isn't clear from StackPath's documentation whether their 'recursive' option only works from the root URL or from internal pages too. Hopefully it does and I'll hopefully get it tested soon. Cheers, Chris2 points
-
@artfulrobot There's different ways you could go about it, but what you described should work. The way I built the comments form (here) for the example I linked earlier was to use a FormBuilder form for the comments/reviews form and just used the comments API to add comments. (In that example the "Rate more details" link at the bottom opens a bunch more fields). I mainly used FormBuilder because there were so many different fields and photo uploads, etc., that it went beyond what I wanted to do with extending a CommentForm class. Though a manually written regular HTML form would have also worked fine. I use CommentForm more often when it's more typical blog-type comments with the built-in optional stars, votes, etc., as it can save a lot of time since it's nearly turn-key. If you only need to add a field or two, that's probably the quickest route. Btw, I also see no harm with using pages for comments either, but just that you'd be building a lot from scratch with regards to spam prevention, comment approval, etc., and also just as a personal preference, I like to keep anonymous user generated content out of the page tree.2 points
-
https://www.bmt.net.nz/ This project began as a project to convert a 20 year old Microsoft Access membership and musical production database to a cloud based system. I completed that over a year ago, but then the organisation realised they wanted a new website, and much of the data was already in the system I'd built for them to manage their membership and shows. Building the public frontend required adding a few more fields on the backend, and reorganising some of the data, but most of it was there already. I've used Lister Pro extensively in this project and it's also my first project using RockMigrations. RockMigrations has proved really helpful in adding new fields, testing, then applying to the live site, and although there's a bit of work to go, the aim is to use RockMigrations to enable the whole setup to be installed as a module on top of a clean ProcessWire installation, as I suspect the setup should be useful for other groups, either with or without customisation of the frontend. Other modules I used were Formbuilder Pro for a membership form, Import Pages from CSV (to import exported data from Access database), Wiremail Gmail, to enable emailing to gmail addresses. I also wrote a custom dashboard module and updater. I wrote a modified version of the ListerPro action Send Email to enable sending HTML formatted emails.1 point
-
@kongondo I'm trying to hook Padloper::updateCart so I can grab a discount code from an input field named 'discount_code' in cart-edit.php so I can set it to the users session if the discount code matches however I can't seem to hook this. It looks like it's hookable, but have tried hook, hookBefore and hookAfter and simply stuck a bd('Test') and wire('log') in there to check but not getting anything. Am I going about this the wrong way. It would be nice to show the user their discount in the cart before proceeding to checkout you see. Then I can hook PadloperCart::getProductPrice to apply the new product prices like in your example code.1 point
-
@zoeck you’re right, disregard everything I’ve said in this thread. It appears I have bought too many ProFields for myself ?1 point
-
Hey there, I have an image field, that only can have one image. Is it possible to change the image description without change the uploaded file? I want upload an image in the frontend and set a description. But I need the possibility to change the description without upload the image again. $p->setOutputFormatting(false); $p->image->description = "Test"; $p->save() $p->setOutputFormatting(true); This returns: Error: Exception: Item 'description' set to Pageimages is not an allowed type And ideas? Best, Kai1 point
-
@Andy I will probably thinking over to add this feature (support for image upload). Technically, uploading an image without image manipulation should not be a problem in this case. At the moment I am quite busy on creating a new module for a contact form based on FrontendForms, but if I have more time left, I will probably give this feature a chance. Best regards1 point
-
Hi Andy, Maybe you are thinking of profile images? I have thought about it, but my experience in the the past has shown me, that users do not upload profile images. A few years ago I have created a user registration with the opportunity to upload a profile image, but no one has used it... so I dont think so, because it would only make sense if you can manipulate (crop, position,..) the image after the upload to get the best fit for the image. This is very complex to implement. Best regards1 point
-
Thank you for the hint @eydun I have added the requirements to the docs.1 point
-
Found it! - it is php 8.1.1 point
-
@artfulrobot Comments are a kind of turn-key fieldtype focused just on comments (like you might use in a blog) or reviews, and their purpose is pretty specific and different from that of a page. So the point is more to be focused on solving a specific thing than to be flexible in the way that pages are. And actually, this is the purpose of most Fieldtypes. If what you are needing is the ability to build your own custom type then that's what pages, templates and fields are for, and maybe that's what you need, I'm not sure. But if you are needing specifically comments, then FieldtypeComments is also quite flexible for comment-specific needs. When it comes to custom data that you want to store along with the comment, there is the meta() method which you might find useful: https://processwire.com/api/ref/comment/meta/. This is what I use for storing photos and other Q&A with comments/reviews, like you see here: https://www.biketours.com/reviews/1 point
-
I'm testing with $config->debug="dev" and there are no major issues. Thanks for the update, @ryan I found these js files that might need some updates for the lastest jQuery (deprecations): /wire/templates-admin/scripts/install.js /wire/templates-admin/scripts/inputfields.js (focus) /wire/modules/AdminTheme/AdminThemeDefault/scripts/install.js /wire/modules/AdminTheme/AdminThemeDefault/scripts/main.js /wire/modules/AdminTheme/AdminThemeReno/scripts/main.js /wire/modules/System/SystemNotifications/Notifications.js /wire/modules/Process/ProcessRole/ProcessRole.js /wire/modules/Process/ProcessProfile/ProcessProfile.js /wire/modules/Process/ProcessPageEditLink/ProcessPageEditLink.js /wire/modules/Process/ProcessCommentsManager/ProcessCommentsManager.js /wire/modules/Inputfield/InputfieldDatetime/timepicker/jquery-ui-sliderAccess.js (upgrade to 1.6.3) /wire/modules/Inputfield/InputfieldDatetime/timepicker/jquery-ui-timepicker-addon.js (upgrade to 1.6.3) /wire/modules/Inputfield/InputfieldPageTable/InputfieldPageTable.js /wire/modules/Inputfield/InputfieldSelector/InputfieldSelector.js /wire/modules/Inputfield/InputfieldPageAutocomplete/InputfieldPageAutocomplete.js /wire/modules/Jquery/JqueryWireTabs/JqueryWireTabs.js (eq) /wire/modules/LanguageSupport/LanguageTabs.js /wire/modules/Jquery/JqueryTableSorter/widgets.js /wire/modules/Jquery/JqueryTableSorter/JqueryTableSorter.js (new version 2.31.3 also has issues with deprecated function calls) /wire/modules/AdminTheme/AdminThemeUikit/layout/source/stable/plugins/jquery.layout.buttons.js I would also update ckeditor to v4.21.0 and uikit to v3.16.14. EDIT: Ryan, I tested with this forked version of JqueryTableSorter: https://github.com/DavidAnderson684/tablesorter and there are no deprecations in the lastest version of jQuery. I'm attaching a zip file with the files to be replaced in /wire/modules/Jquery/JqueryTableSorter/ JqueryTableSorter.zip1 point
-
Go to Modules -> Configure -> AdminThemeUiKit. There will be a section called “Masthead + navigation” which you can click to open. Then under “User navigation label format”, where it currently says “{Name}”, enter “{title}” instead. Or any other valid template string you like, obviously. The field pretty much tells you what to do. Of course this only works if your user template has fields for the things you want to display. As you will notice, other admin themes have their own settings, so if you allow users to change themes, you’ll probably want to make equivalent changes to all of them. However, AdminThemeReno doesn’t use the same template string system and AdminThemeDefault has no setting for this at all.1 point
-
The custom user fields will be taken from the user template and mapped to the FrontendForms class. So PW fields will be re-written to FrontendForm fields. Take a look at https://github.com/juergenweb/FrontendLoginRegister#support-for-custom-user-fields Some of the values as set in the PW fields will be added to the FrontendForm fields too. Example: If you take the PW password field and you have set the requirements to at least "1 letter and 1 digit", this requirement will also be used in the Frontendforms input field for the password on the frontend. Validation will only be taken by FrontendForms. Does this answer your question?1 point
-
Off topic: htmx is in the first cohort of the GitHub Accelerator: https://github.blog/2023-04-12-github-accelerator-our-first-cohort-and-whats-next/1 point
-
Thanks to bernhard and Autofahrn i have come up with this example code and run it in TracyDebugger on a test page with a image field and it works beautifully. <?PHP /* get and save a new image to image field Pageimages array */ $page->of(false); $pageImages = $page->images->add('https://www.somesite.com/image_of_tree.jpg'); /* save the page (perhaps not needed but there for comfort.) */ $page->save(); /* get the last added image */ $lastImage = $page->images->last(); /* debug before changes */ d($lastImage, '$lastImage before changes'); /* add tags to the image and description */ $lastImage->addTag('test'); $lastImage->addTag('Tree'); $lastImage->addTag('Syren'); $lastImage->addTag('Sun'); $lastImage->addTag('Sunny'); $lastImage->description = 'This is a beautiful tree.'; /* debug info */ d($page->images, '$page->images'); d($lastImage, '$lastImage'); /* save the page */ $page->save(); ?> I used the following API docs and mentioned forums users help to accomplish this: https://processwire.com/api/ref/pageimage/ https://processwire.com/api/ref/pageimages/ https://processwire.com/api/ref/pagefile/ https://processwire.com/api/ref/pagefiles/ Just wanted to post this at the end so others who wonder about this could get a starting point.1 point
-
Hi all, I just switched to processwire from MODx and I am really impressed of how clean, fast and intuitive this system is. My first project with processwire happens to be a multi language site, and I am really happy that it can be done with a single page tree. However, I had to dig the forums a lot to find all information i needed to get everything working, so I thought I share my newly gained knowledge... The order of the steps is important, especially if you are working on IIS (which can inflict database damage if you add languages before you change the field types!) 1. Install the Language support modules: - Languages Support - Languages Support - Fields - Languages Support - Page Names 2. Change any existing Fields of types Textfield/Textarea/PageTitle to TextLanguage/TextareaLanguage/PageTitleLanguage You now will have an input field for each language you add. 3. Set up your languages under Setup->Languages (define a name and title for each language. For each new language, you will have to add a title to all the other languages in that new language) 4. Edit your homepage, set it to hidden and unpublished. UPDATE: don't set the homepage to unpublished, the first-child-redirect won't work! (I realized just now, because if you are logged in as admin, it does work) For each language, you have to define a unique name (e.g. "de" and "en") 5. Edit your "home" template to redirect to its first child: <?php $session->redirect($page->children->first()->url); UPDATE: this is not essential... as ryan pointed out, it might even be better not to do it (for SEO-optimization) 6. If you have something like $children->prepend($homepage); in the menu part of your head.inc, remove it (you don't want the home page to show up in your menu) UPDATE: if you left out the redirect option, you'll want to leave this out as well. 7. To switch languages, add this snippet to your head.inc: <ul> <?php $user_lang = $user->language; foreach($languages as $language) { $user->language = $language; if($language->name != $user_lang->name) { echo '<li><a href="'.$page->url.'">'.$language->title.'</a></li> '; } } $user->language = $user_lang; ?> </ul> Each language except the currently active one will be displayed in a list (of course, this can also be done with a select field). UPDATE: Ryan pointed me to a better solution for the langugae switch: http://processwire.c...s-urls/?p=33537 8. Done. Now your page urls should look something like path/to/root/en/my-page, or path/to/root/de/meine-seite It took me less than a day to set up processwire, install my html template and configure the site to be multi-language... this is so great, considering the pain multilanguage sites usually cause with all the other CMSs... Keep it up! UPDATE: I was a bit quick to post a tutorial just after one day working with PW... should have made some more research beforehand. Just got a little too excited there... I'm still impressed by the system and plan on digging deeper into it.1 point
-
Regarding Approach #1, I think you'd want to use the LanguageSupportPageNames module included with PW 2.3.0 dev branch. I'm responding to your special cases with that context: You have checkboxes next to each language page name. This controls whether the page is published in each language. There is no need to keep track of this since the URL structure dictates the language. This also makes it very SEO friendly. ProcessWire takes care of setting the user's correct language for you, based on the URL. That's what code internationalization is for. For example, an editable footer: <p id='footer'><?php echo __('Thank you for visiting. Copyright 2013 by Somebody.'); ?></p> The following is replying to approach #2, separate trees: The structure is up to you. Whether or not you start your root with an "en/" for your default language is based entirely on how you structure your site. So if you don't want to have "en/" (for example) for your default language, then don't built off a page called "en". Also not necessary since structure would dictate language. You would examine the $page->rootParent to determine language and set it at the top of some common include file (like a head.inc or init.php): if($page->rootParent->template == 'language-home') { // or whatever your template is called $user->language = $languages->get($page->rootParent->name); } else { $user->language = $languages->get('default'); } The same about code internationalization above applies here. Anything static text you put in a __() function becomes translatable. If something is translatable then it is also editable, even for the default language if you want. If you still didn't want to have text originate from the template, then you could always create a settings page in each tree. I would probably just add my "footer_text" as a field in the language-home page.1 point