Leaderboard

Hi everyone, I'm happy to present my latest project, which is a collection of guides and tutorials for web development with ProcessWire written by me. https://processwire.dev/ What is this? I have written several tutorials in this forum, and I wanted a central place to collect all my tutorials and put them in a logical order. processwire.dev is exactly that, a curated list of tutorials for different topics related to ProcessWire development. I have revised, updated and expanded most of my existing tutorials. There are also some completely new tutorials. Notable topics How to integrate Composer in your ProcessWire sites, and a general explainer for namespaces and autoloading. A two-part guide to using Twig with ProcessWire and adding custom functionality. How to create flexible content modules with Repeater Matrix fields and Twig. A general guide to performance optimization for ProcessWire. A starter guide for the "ProcessWire mindset" - how to structure your content. ... and much more! What's next? I hope this will be a useful resource to all of you fine people. Please note that these tutorials are very much opinionated, and they reflect my personal experience and development practices. So if you disagree with some of my conclusions, that's perfectly fine! I'm happy to discuss all my recommendations and approaches with you, so let me know if you have any feedback, suggestions or error corrections! I plan to expand this resource over time and already have some new topics planned. If you have suggestions for new topics, go ahead and post them here as well! Start reading now: processwire.dev

This week I’ve been continuing to work on the new ProcessWire modules directory, this time focusing on the front-end editing aspects for module authors. This is the part that deviates the most from the existing modules directory (and makes revolutionary improvements upon it), so none of this is on the production server yet, and it’s going to take a little more time to develop. LoginRegisterPro and FormBuilder are saving a lot of time in the development. LoginRegisterPro handles the account management side, while all module editing forms are powered by FormBuilder. By next week I’m hoping I might be able to launch the new editing features so that module authors can begin to use the system, but we’ll see how it goes. This week there have also been several updates to the core dev branch, including both improvements and issue fixes. By next week I also expect to bump the version to 3.0.169. For more on the modules directory improvements, be sure to also see last week’s post.

Good Day, I utilize Dreamhost VPS for all of my company related websites. My clients mostly utilize Dreamhost shared hosting services. I took note of your problem and took a quick look at my company related websites. I upgraded one website from ProcessWire 3.0.151 to 3.0.165. I then upgraded my PHP from 7.3.24 to 7.4.12 on that particular website. I am able to upload pictures to my image fields. The only problem I had was for images that had a resolution of 5312 x 6875 (5 mb) and 6741 x 4166 (796 kb). These would have the spinning over the image icon. I was able to upload a 4032 x 3024 (3 mb) image with no problem. Other images of lower resolution uploaded without any issues. I honestly don't know if this problem existed before on the VPS as I hadn't been loading high resolution images on any of my websites. On two of my client's website (on Dreamhost Shared Hosting), i am able to load the same high resolution images that I couldn't load on the VPS related websites without an issue. The websites that I could load the high resolution images were at PHP 7.4.11 and using ProcessWire 3.0.153 and ProcessWire 3.0.165

I'm about to release 0.7.0, which has the following changes: Bumps PHP minimum version to 7.1 (should be 7.2, but I'll do that next year) Bumps PW minimum version to 3.0.16 Fixes an issue with regards to null configs Sitemap cache policies Sets the correct installer directory for Composer

So... even though it will embarass me to new heights... I will post the details to this issue and the details to resolve them. I used and tried each and every measure @MoritzLost posted in his previous post BUT... NO RESULTS at all or as Moritz would say The module isn't running at all. His assumption was 100% correct. The module wasn't evoked, triggered or called at all. Lucky me... the jackpot. All debug-measures resulted in zero results. So... I went back to the classic debugging once again (which I should have done before). 1. module setup defaults - fine! 2. field setup defaults - fine! 3. module setup details, each and every possible setup option tried - fine! 4. field setup details, each and every Textformatter enabled/disabled - whooops!!! My body field (textarea, CKEditor) with Hanna, PrivacyWire and ALPT formatter didnt't play well together. Re-Ordering each and every textformatter didn't help. Removing all and re-assinging each of those, one after the other, worked out fine! In my case ... in all setups and versions (based on the non-working setup) this helped: Deleting all Textformatters from field -> save field Adding ALPT -> save field Adding PrivacyWire -> save field Adding Hanna -> save field Everything is working now as expected! I don't know which textformatter might have been the issue or whatever details caused this BUT... if this happens again to me, I will probably reset, remove and add all textformatters to make it work again. Thank you @MoritzLost - for the debugging details and the module again!

Chäs & Co is a b2b cheese trader. They love good cheese and are proud of their excellent knowledge und connections to small cheese producers. They maintain a custom made database and used to copy/paste (!) the cheese infos to the former CMS (Contao). Since substituting the database with ProcessWire was no option, they export now the database to a csv file and import it to the new website (expanded version of module ImportPagesCSV). From there, the pw magic begins. The staff works with the admin interface: They search and find products in notime using the build-in search field (using cheese names or id. Using ids only possible by adding hook, see this forum thread). They generate price lists easily based on a template, providing checkboxes and option buttons for some restrictions, choose i.e. the cheese origin and price audience (all implemented as page selectors). By saving the page a PDF list gets generated (using mpdf, a php pdf library). The visitors can sort and filter the products using a form by shuffle.js. Product details are shown in a popup (fancybox). There's also the option for generating a nice pdf data sheet. No CSS framework being used. Other modules used: ProcessJumpLinks, ProcessProMailer, ProcessWireUpgrade. Visual design: Nicole Haller

I have built a couple of similar systems, it's actually not that difficult. You don't need a module for it, you can just write out the logic in your PHP template (I prefer to use custom page classes for stuff like this, but the template file will do fine). A good trick to get started is to separate the requirements into individual tasks that you can finish one by one. In your case, I would divide the requirements into the following tasks and questions: Create a data structure to hold your access codes, i.e. either a field or new template. (Optional) How and when are codes created? Manually or automated? For example, when a new concert is created in the system, you could generate a number of access codes automatically, or create a code when a reservation comes in. (Optional) How are codes distributed? For example, you could select a random code (or generate a new one, see above) when a registration comes in and send it in an autoresponse email. Create an interface for entering your individual code on a concert page, and validate the codes. Store the authorization (i.e. a valid entered code) so it can only be used by one person. Then you can think about how to solve those problems using either custom code or the tools that come with ProcessWire. Here are some suggestions: I usually use a Table field (part of the ProFields module), because it allows you to store a code alongside with information on it (like expiration date, used/available flag, etc) in a single field. I would have one dedicated template for access-protected events (in your case, concerts) and add one Table field to it which holds the codes for this event. You can solve this with simple hooks. For example, automatically creating a number of access codes when a new concert is created is only a matter of hooking Pages::add. Or if you want to create codes on demand during registration, hook into the relevant part of your registration process to create the codes when needed. I would build a simple registration form using FormBuilder, which already includes input validation, payments processing and autoresponder. Again, you can use hooks to insert an individual access code into the autoresponse email. You'll want to have a flag in your codes table which keeps track of whether this code has been used or not, to make sure each code can be used only once. You can do this in PHP directly in the template file: Check if the user is already authorized for this concert (see below), and if so, display the concert's content / stream / whatever. If the user is NOT authorized, display a form for entering the access code. If a code was submitted, check if the code is valid (i.e. it exists on this page, has not been activated yet — this should be a separate flag in your Table field — etc). If it is, store the authorization for this user (see below) and display the concerts content. You can use multiple approaches for this, depending on how serious you are about preventing misuse. A simple approach would be to store the authorization in a cookie or session. This would allow the same user to close and reopen the page (though using the session would mean the codes only stay active for the current browser session). This is pretty simple, but of course has it's limitations. For example, what if users want to switch from the desktop to a mobile phone? Distinguishing between one user switching devices and multiple users sharing an access code will be difficult. Another possibility is to user ProcessWire user accounts, requiring users to create an account and then adding the authorization for individual concerts to their account directly. Using accounts you could make access codes obsolete entirely. Of course, you'll have to find a solution against account sharing (I'm not sure if ProcessWire allows multiple simultaneous sessions for one account by default). Note that none of those solutions stop a really determined bad actor from sharing their access to your concerts, or the content you provide. The only solutions for this is to integrate DRM, which is really difficult and not really feasible for small websites. But both the solutions above should work mostly fine. Ok this text got longer than I intended, and I know it's not a complete solution. But you see the point – by breaking down the requirements into individual parts the system becomes much easier to build. You can pick and choose from existing solutions (ProcessWire user accounts, the FormBuilder and ProFields module, etc) and combine them with custom logic using hooks or the template file. The rest is just a matter of experience with ProcessWire and PHP. If you get stuck on coding specific steps of this system, make sure to post them here, there's always a good solution!

A terminal for running server commands: http://modules.processwire.com/modules/process-terminal/ https://github.com/adrianbj/ProcessTerminal NOTE: It does not support interactive commands like vi, nano, apt, etc. DO NOT attempt to use these as they may result in you needing to restart apache. This is a bash terminal that lets you quickly execute commands on a server. In addition to normal commands like: ls, cd, cat, mkdir, rm, chmod, chown, etc, you can also do mysql command line calls which is very handy if you need to add a new user, create a mysqldump etc. Note that for mysql commands you need to issue them individually - you can't simply start "mysql" and issue commands from there - each call needs to include your username and password and the command to be run, eg: mysql -u root -p mypassword -e "CREATE DATABASE newtablename"; There is also an upload and download command, eg "upload test.txt" which will spawn a file selector dialog on your machine to upload that file to your server with the given name. It also has arrow up and down for command history as well as tab autocompletion of commands and file names. This module was separated from Tracy because some shared hosts were flagging it as spam. This is because it uses system_exec to run server commands. This can certainly be dangerous, but in my opinion it is no more dangerous than the HannaCode module or the Tracy Console panel which both allow you to run system_exec. The key thing is that ProcessWire's htaccess rules prevent the shell.php file from being run directly and because this is a process module it uses PW's permissions to restrict usage to superusers.