millipedia

I had to do this just the other week. We had an old CMSMS site that we'd moved to PW. We had a db table with the old user names and passwords in which we stuck on the new site, and then just created our own login page which first checked to see if we had the user in PW already. If the user isn't already in PW then check the password against the old table; If it matches then use that information to add a new user to PW. The users don't really notice that anything has changed. Here's the code I used for that - you'll have to adapt to your circumstances of course but it worked well for our move. if ($input->post('ml_name')) { // when processing form (POST request), check to see if token is present // (we have a CSRF field on our login form) if ($session->CSRF->hasValidToken()) { // form submission is valid // okay to process } else { // form submission is NOT valid throw new WireException('CSRF check failed!'); } $ml_name = $sanitizer->name($input->post('ml_name')); $ml_pass = $input->post('ml_pass'); // dont allow the guest username if ($ml_name === 'guest') { throw new WireException('Invalid username'); }; // do we have this user in PW already? $u_exists = $users->get("$ml_name"); if ($u_exists->id) { // user exists // lets try and log them in try { if ($session->login($ml_name, $ml_pass)) { $session->redirect('/'); } else { $ml_feedback = 'Unknown details.'; } } catch (WireException $e) { // show some error messages: // $e->getMessage(); } } else { // ok - well do we have this user in the old CMS table? $query = $this->database->prepare("SELECT * FROM `cms_module_feusers_users` WHERE username = :login_name LIMIT 1;"); try { $query->execute(['login_name' => $ml_name]); } catch (PDOException $e) { die ('Error querying table : ' . $e->getMessage()); } // we've got a user from the old table if($query && $row=$query->fetch()) { $ml_feedback='Is in old table'; $hash=$row['password']; // handily the old auth just uses password_verify if(password_verify($ml_pass, $hash)){ // Add this user to the PW users $new_user=$users->add($ml_name); if($new_user){ $new_user->pass=$ml_pass; $new_user->addRole('members'); $new_user->save(); $log->save("new_members_site", $ml_name . " added as user"); $u = $session->login($ml_name, $ml_pass); if($u) { $session->redirect('/'); } else { die("Error in logging in. Please contact admin."); } $ml_feedback='new user added to PW'; }else{ $ml_feedback='Unable to add new user. Please let admin know'; } }else{ $ml_feedback='No matching records found.'; } }else{ $ml_feedback='No record found.'; } } } and this is the login form that the we had on our new login page - this and the above was all in a single template. <form id="ml_login_form" class="ml_login_form" method="POST"> <?php echo $session->CSRF->renderInput(); ?> <label for="ml_name">Username</label> <input id="ml_name" name="ml_name" type="text" value="<?= $ml_name ?>" required> <label for="ml_pass">Password</label> <input id="ml_pass" name="ml_pass" type="password" value="<?= $ml_pass ?>" required> <div style="display: none;"> <label for="ml_pass_bear">Password</label> <input id="ml_pass_bear" name="ml_pass_bear" type="text" value=""> </div> <button type="submit" name="ml_submit" class="butt">Submit</button> <div class="ml_feedback"><?= $ml_feedback ?></div> </form>

Depending on your requirements, the Stripe payment processor for FormBuilder might be worth investigating. You can set Paypal to be a payment option in Stripe so that users can pay using PayPal but you can keep all your transactions on the same plaform. Out of the box FormBuilder might not do everything you need (if you need a basket etc) but it is possible to hook into the module to update line items / prices etc. We recently built a basket system for a site that we'd wired directly into Stripe but then shifted over to hook into Formbuilder instead because it already did a lot of the heavy lifting in using the Stripe API.

So, today I learned that you can use a config-dev.php file which takes precedence over the normal config.php file if it's present. ... unfortunately I discovered this by accidentally uploading a config-dev file to a live site. I'd got two config files for live and staging in my project folder and just renamed them when I wanted to update a setting - I'd coincidently named the file for the staging details as config-dev.php and accidently uploaded it to production. Luckily this just meant that the content from the staging site got displayed which wasn't too out of date so hopefully no one noticed.... Now I look into it, I can see that's it been around for ever and there's been lots of chat about it, but hey, I didn't know about it, so thought I'd stick it in this thread just in case anyone else was a daft as me.

Obviously you should try and educate your client into the advantages of building in PW (and in the difficulties of designing a pixel perfect site that works across all browser and devices) but if they really insist on being able to fiddle then WebFlow is probably the kind of thing they want. Not a PW solution, but it does work well once you get the hang of it. We lost a client of 20 years to it last year 😞

Bernhard's AdminRockStyle is probably the easiest way to go, but there's a blog post from Ryan which covers how to customise the admin theme using Less. We keep a slightly more accessible colour scheme in our skeleton project as a starting base for new sites for example, and it would be easy enough to add a larger font size in there.

One thing that has improved the speed at which I can mark up a design from Figma is the VS Code extension. I can open a design in a VS Code tab, and then not only see the the properties for an element but also have them appear as auto-complete suggestions as I type. Given that mostly I'm just grabbing one or two properties for an element that's really useful. The same goes for assets; I can copy SVG elements directly to paste into my markup or export them straight into my project folder. If you use Figma and VS Code then it's definitely worth checking out.

Great - that's really useful. I didn't know about the 'always' condition in .htaccess (even though it's all over the place in the usual .htaccess file ....). I think a combination of that and catching my errors earlier should do me. Thanks for your help.

We're building a Capacitor app that grabs data from the OpenAI API via ProcessWire (it's a fun project - I'll write it up once it's done). For successful requests we're adding a CORS header: header('Access-Control-Allow-Origin: *'); header('Content-Type: application/json'); and that's all good. Occasionally though we'll get a timeout form OpenAI (or I've done something daft in the code) and PW will throw a 500 error. Because that response doesn't have the correct headers then I can't catch the error in the app. I've tired adding the header into wire()->addHookBefore('Page::errorPage', function($event) { but I'm not convinced that 500 errors even get there. Suggestions as to how I can a header gratefully received....

Just in case it might be useful to you, there's a $sanitizer->truncate() method which will trim a block of text to the nearest word / sentence etc. It's very handy for creating neat summaries.

Has anyone managed to update this module to use an updated API version? I've done my very best to persuade users that now is the time to ditch Twitter but I've still got a few clients holding out ....

The placeholder background images are pulled from YouTube / Vimeo, so whatever thumnail you set there will be what gets shown. Then a pretend play button that gets added which defaults to the Vimeo blue / YT red buttons: When you click the button the placholder is replaced with the relevant iframed video. The module has a config option that will let you change the colour of that button. It's not too much effort to style the play button if you want to make it bespoke (as we did for https://osborne.coop/ ). Now - GDPR is a good question. All we're doing when the page loads is pulling an image in. Neither Privacy Badger nor uBlock are complaining about anything when we load an image from YouTube, but Privacy Badger does flag a cookie from Vimeo (uBlock doesn't mind). We use the no-cookie domain for YouTube as well of course. It doesn't look as if lite-youtube or lite-vimeo offer the option to use a local placeholder image but it's probably doable. Not enrirely sure how we'd configure it in a TextFormatter tho.

As requested by @fuzenco (quite a while ago... sorry for being slow), I'm just creating a separate thread for our TextFormatterLiteVideoEmbed module rather than hijacking the Lite YouTube Embed Module thread. TextFormatterLiteVideoEmbed is a text formatter that replaces YouTube and Vimeo urls in text and textarea fields with custom web components that only load the video iframe when they've been interacted with. This is a million (approximately) times faster than loading the video when the page loads, especially if you have multiple videos on a page. You can check Paul Irish's original YouTube version to see what it's all about. There are config options to set the button colours for the components, and one day I'll get round to adding all the other parameters we ought to have. I've used it on several live sites at the moment and is our go-to module for embedding videos now so hopefully will keep adding to it but I'm happy to take requests if anyone needs anything specific adding. It was originally based on the TextformatterLiteYouTubeEmbed module so props to @jacmaesfor creating that. The code is available on Github at https://github.com/millipedia/TextformatterLiteVideoEmbed and I'll add it to the modules repository once I've tidied up the code (it's getting there slowly).

Damn - ninja'd by @slkwrm but I was just saying the same thing: There's been a lot chat in this forum recently about htmx so I'm giving it a go on a dashboard webapp we're currently building and it's been working very well indeed. In our case we've built a module where we create URL hooks that handle ajax requests from htmx // initialize the hook in your AutoLoad module public function init() { wire()->addHook('/api/log-activity', function($event) { include('ajax_log_activity.php'); }); } Then it's just a case of marking up your button or form to post whatever you need to that url: <form id="log_form" hx-post="/api/log-activity" hx-target="#log_form_bits"> <!-- or a button --> <button class="butt butt_secondary" hx-post="/api/log-activity-delete/<?=$some_id?>" hx-target="#your_target" hx-confirm="Are you sure you wish to delete this log entry?">Delete</button>

We look after a lot of non-profit sites including half a dozen schools and they're mostly hosted on Digital Ocean instances managed by Cloudways. Their cheapest instance is currently $11 a month and that's what we normally start and which provides good performance for most cases (there are some additional per Gb backup charges but they're normally very minimal). You can scale up instances if you need to. One thing we find particularly useful is being able to 'clone' sites so we keep a skeleton PW site up to date and can just replicate that to kick off a new project (no, all our sites do NOT look the same...). You can also clone a site to a staging site and then push changes from that to the live site. We generally stick sites behind a free Cloudfare account as well (because honestly why wouldn't you), and Cloudways also have a deal with Cloudflare where you get the enterprise level for $5 a month which seems great if you need it (we rarely do). We also use https://krystal.uk/ for clients who need emails - that's more of a traditional CPanel setup but works well for us.

Hmm - it works for me on several sites at different page depths - which webserver are you using? But you're right that I don't really think we need that leading period, and taking it out seems to be fine, so I've made those changes as suggested. Thanks for letting me know.