Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 01/16/2022 in all areas

  1. ProcessWire 3.0.193 resolves 6 issues, makes improvements to the template and module editors, adds new hooks, adds improvements the $pages->find() findRaw method, and more. We covered some of these updates in last week's post, so we'll focus on what's new this week. First off we have a new advanced mode feature that lets you edit the raw configuration data for a module. This can be useful for various reasons, especially for module developers. If you have $config->advanced = true; in your /site/config.php file, you'll see a new option on your module information screen that enables you to directly edit the raw JSON configuration data for the module. There's also an option that lets you view the raw JSON module information data. Unlike the configuration data, this isn't editable. That's because it comes from the module directly (overtime you do a Modules > Refresh) or is generated at runtime, so there's little point in editing it here. In my case, I've found these new tools helpful for clearing out old and/or irrelevant configuration data during module development. In some cases, having the ability to edit this data may help to identify or fix issues that previously would have been difficult to do without using the API. If there's interest, I may move this into a dedicated (non-core) module that also lets you directly edit field and template configuration data too. But for now the feature is in the core, but just requires advanced mode before it appears. A few new hooks were added this week: Fieldgroups::fieldRemoved($fieldgroup, $field) Called after a field has been removed from a fieldgroup/template. Fieldgroups::fieldAdded($fieldgroup, $field) Called after a new field has been added to a fieldgroup/template. Fieldgroups::renameReady($template, $oldName, $newName) Called before a fieldgroup is about to be renamed. Fieldgroups::renamed($template, $oldName, $newName) Called after a fieldgroup has been renamed. Templates::renameReady($template, $oldName, $newName) Called before a template is about to be renamed. Templates::renamed($template, $oldName, $newName) Called after a template has been renamed. Fields::renameReady($field, $oldName, $newName) Called before a field is about to be renamed. Fields::renamed($field, $oldName, $newName) Called after a field has been renamed. These accompany the existing addReady(), added(), deleteReady(), deleted(), cloneReady(), cloned(), saveReady() and saved() hooks available for fields, templates and fieldgroups. Last week a couple people asked about versioning and migration of stuff in PW (like fields, templates, modules, etc.) and if there were any plans to provide additional tools for that. For the projects I work on at least, this part of the development process consumes so little time that it doesn't warrant developing more stuff for it. But I understand others might find it useful, so for those that would, I'd rather keep the core lean and instead leave that to tools/modules built by experts like Bernhard and others around here. I think it's important that whoever develops and maintains such features also be the same one(s) that would use them. But if any kind of core updates would be helpful to developers looking to implement more features here, I'm on board. Whether that means adding more hooks to specific events (see above as examples), maintaining field/template/module data in files in addition to the current DB tables, or anything else that helps such modules, this is all possible and likely simple for us to support in the core. So just let me know what I can do to help. While not full-featured migration tools, we do have useful field, template and page export/import tools in the core already, and those will of course continue to be maintained and improved, and may be expanded to include modules too. Thanks for reading and have a great weekend!
    14 points
  2. Well hello, today is the day I would like to introduce Flowti, my biggest Project I have worked on for the last 2 1/2 Years and the reason I am developing Symprowire, too. So, what is it all about you may ask. Flowti is my daily driver to Plan, Document and Execute Projects Flowti is my tool to work on concepts and ideas Flowti is my tool to present Work Flowti is my tool to organize and support Product Management Work Flowti is my digitalization Framework To give you a glimpse about what Flowti is already capable of I attached some screenshots for you to study 😛 To make this one short, I plan to fully Open Source Flowti this year after Symprowire reaches v1.0 and will use this post as a way to show progress. Cheers, Luis
    12 points
  3. The problem: Synchronizing fields and/or templates made on the dev server with the live server is cumbersome. At the same time, there is no version control of fields and templates, which some folks (including myself) see as a disadvantage of ProcessWire. A way to have version control to track changes and replicate automatically would be desirable. There is the template and fields export feature in ProcessWire which has said for ages that this is only a beta version, although I have used it many times without any problems. However, even with this method, it is very cumbersome to reconcile changes between dev and live. You have to remember which fields / templates you created and select them, then copy and paste them on the dev server. This is a manual, cumbersome and time consuming process. Existing solutions: For this reason, several solutions have been developed such as: Migrations by @LostKobrakai https://processwire.com/talk/topic/14603-rocksvn-brings-version-control-to-your-fields-templates/ ProcessWires Template's and field's export function https://processwire.com/modules/rock-migrations/ https://processwire.com/talk/topic/25307-oh-no-not-another-migration-module/ https://processwire.com/modules/auto-export-templates-and-fields/ Other systems like Laravel, Craft, Kirby and Statamic use configuration files (migrations, YAML) to manage fields / templates, which allow to create a state of fields / templates. Since the configuration is done in a file, you can of course manage it with git (or other vcs). By configuring in a file, it is also possible to automatically execute these migrations during a git push through different deploy pipelines like github actions, buddy, bitbucket pipelines and thus you have the desired state on the desired server. Where to go from here? In another post @bernhard showcased a prototype, that uses a YAML-file to create and manage fields / templates in ProcessWire. At the same time he showcased a YAML recorder which writes all changes that are made to templates and fields into a YAML file, which looks very promising: I think a combination of a recorder and a YAML config file would be a optimal solution, at least for me. What format to use for such a configuration file was and has also to be discussed:
    10 points
  4. Would you mind telling us a bit more about your workflow in regards to projects and their migration? This would be super interesting.
    8 points
  5. @bernhard YAML is preferable because it's declarative instead of imperative. This has a couple of side-benefits, like cleaner diff views in git, no formatting issues or different styles and no 'noise' in your commits (all only relevant if you have a git-based workflow with pull requests). But the big thing is that it makes it impossible to create environment-specific configuration, which is exactly what you don't want. If you embrace that the configuration is the source of truth for the entire site state (excluding content), you won't need this anyway. Take your example where you switch a field based on whether the languages module is installed - I would flag this in a PR and consider it an antipattern. Whether a site is multi-language or not should be part of the configuration. If it isn't there's no way to guarantee that the code which works in staging will also work in production, so at that point you're doing all the work for controlled deployments and version control but not getting the benefits. Another downside of PHP is that it's onedirectional by default. With YAML, if a deployment fails, you can just roll back to the earlier version and apply the configuration of that version. With PHP, this may work if the PHP migration is just one single $rm->migrate call with an array of configuration (so basically it is a declarative config). But you have no guarantees that it will, and if you have any logic in your migration that depends on the previous state of the site to migrate to a new state, this migration is irreversible. Migrations do have their place - if you really need to perform some logic, like moving content from one field or format to another. But besides that, declarative configuration files are preferable.
    7 points
  6. Some of you might of used my previous U2F module for their two factor needs. Well I was recently informed that Chrome is dropping plain U2F support in favour of WebAuthn. So after a full day of debugging some cryptic errors I am proud to announce a WebAuthn module. This has some major improvements. For example you can now use on-device credentials like Windows Hello/Apple Touch ID. This means that even people without a Yubikey can benefit from modern two factor authentication. It also has much better cross platform support. For example NFC will now work on an iPhone. I do not recall the original U2F stuff working well on iPhones so yay? The is still the original issue that ProcessWire imposes with its Tfa class, That being it is a setup once and never edit again system so you can only add your on-device credentials for a single device because once saved you cant then edit your credentials on a second device. You also lack the options to revoke a single credential or add a new one. You have to wipe out the config and re-add your keys again. It sucks but realisticly if you need more than 3x credentials your almost defeating the point of Tfa I feel the need to also point out that this does not replace passwords. That is something WebAuthn can do a fully passwordless setup. But I think implementing that inside ProcessWire would be a huge challenge. It is frankly a form of magic that I was able to make WebAuthn work within the confides of ProcessWire's Tfa class. Github: https://github.com/adamxp12/TfaWebAuthn ProcessWire Modules: https://processwire.com/modules/tfa-web-authn/ I hope this module helps you guys out securing your ProcessWire websites If you have any issues just reply and I will do my best to help you out
    5 points
  7. 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.
    5 points
  8. yeeha!! 😎 <?php /** * Center Buttons * @return Buttons */ public function getButtonsCenter() { $buttons = parent::getButtonsCenter(); $buttons->add([ 'name' => 'markClaimed', 'icon' => 'check', 'tooltip' => 'Mark selected items as claimed', 'hidden' => '!selected', 'appendMarkup' => '<div id=markClaimedConfirm hidden>...</div>', 'callback' => [ 'name' => 'sendIDs', 'confirmmarkup' => '#markClaimedConfirm', 'loading' => 'Saving items...', 'reload' => true, 'execute' => function($input, self $grid) { $ids = $this->wire->sanitizer->intArray($input->ids); $note = $this->wire->sanitizer->text($input->note); foreach($this->wire->pages->findMany(["id" => $ids]) as $p) { $p->setAndSave(Effort::field_claimed, 1); $p->setAndSave(Effort::field_claimedwith, $note); $grid->sse("Saved page $p"); sleep(1); // just for the screencast } $grid->sseDone(); return ['success' => true]; }, ], ]); return $buttons; }
    4 points
  9. @guy You could try this: if($this->wire()->process == 'ProcessPageEdit') { // save from page editor } If you want to capture other types of page editors, like ListerPro, User Profile, etc. you could do this: if(wireInstanceOf($this->wire()->process, 'WirePageEditor')) { // save from any page editing process }
    4 points
  10. Thank you for summing this topic up in a new thread. I had the same intention but couldn't spare the time. I am all for version control of fields and templates. @bernhard's RockMigration Module already does a great job here. And since he introduced the prototype recorder I am very excited that we will soon have something to work with and build upon. This should really be part of the PW core or available as optional core module. Would be great if @ryan put this on the roadmap for 2022.
    4 points
  11. thx! I'm thinking about it. But I think not to the current version. RockMigrations has evolved over the last years and it's time to refactor and clean up and that would be a good opportunity. What I'd like to know of you guys is why everybody seems to be so excited about YAML? Is it about the YAML thing or is it about the recorder? I'm asking because YAML would really be a drawback IMHO. What I think would be much better is to have a regular PHP file that returns a simple array. That's almost the same as a YAML file but you can do additional things if you want or need. See this example: <?php namespace ProcessWire; /** @var RockMigrations $rm */ return [ 'fields' => [ 'foo' => [ 'type' => $wire->languages ? 'textlanguage' : 'text', ], ], 'templates' => [ 'demo' => [ 'tags' => RockMails::tags, 'fields-' => [ 'title', 'foo', ], ], ], ]; That migration file would add a "foo" field and depending on the system make this field single or multi-language. That would be just one example which would not be possible using YAML syntax. Another thing is using class constants. Possible in PHP (see RockMails::tags in the example above), not possible in YAML. I'm really curious what it is really about, thx.
    4 points
  12. Side note @ryan it would be nice if you could add relevant keywords to the title of new news or blog posts. This makes it easier to find information when you are searching for it weeks or months later ("weekly update 14.1." is not nearly as helpful as "weekly update find raw parents, sanitizer float" in a search result) +1 for better version control support. I've not built RockMigrations just for fun 😁
    4 points
  13. Thanks @Guy Incognito I have merged your PR. I have switched to using SeoMaestro, but to be honest I am not particularly happy with either of these modules - both have their issues for my way of working / thinking. It will be interesting to see what RockSEO brings to the table.
    3 points
  14. Okay guys I have worked all day on this https://github.com/adamxp12/ProcessWire-TfaWebAuthn A total rewrite essentially moving over to WebAuthn. I Invite anyone to test this out I will publish it to the modules site probably tomorrow as long as no one has any major bugs I have missed in my testing. @Pete You can add a physical security key in addition to Windows Hello. but you can only setup one instance of Windows Hello/Apple Touch ID at a time because of that ProcessWire Tfa limitation but NFC keys will work on iPhone now where they did not before so a YubiKey with NFC will work virtually everywhere. I would assume if you enrolled your Android phone via USB it will work on-device too in the browser but I do not have an Android device to test that.
    3 points
  15. @Pete WebAuthn is the W3C standard whereas U2F was a google thing. When I made this module in 2019 WebAuthn was a fairly new thing The module does already support multiple keys the issue is once you save the users TFA settings they become locked so cant go in and remove a single key or add another you have to deactivate it and re-add all the keys. The might be a way around this. It does make sense from the POV of the TFA class being for one time codes as you would not edit it you would just deactivate it. The U2F was a great challenge with that constraint. With WebAuthn I might have to disable non cross platform methods like WIndows Hello because it would be impossible to setup multiple devices once you hit save on the first device. But at least it will work as it did before once U2F is removed from Chrome. I could keep that enabled but it would mean only the first device you setup will have that on device option. any other device would have to use a a physical security key. Granted I am far from a ProcessWire expert so maybe the solution is obvious?
    3 points
  16. FYI: " Google Analytics Now Illegal in Austria; Other EU Member States Expected to Follow The Austrian Data Protection Authority ("Datenschutzbehörde" or "DSB" or "DPA") has ruled that Austrian website providers using Google Analytics are in violation of the GDPR. ... ...all Google Analytics data can be imported into Matomo so no historical data is lost. " you can read more: https://matomo.org/blog/2022/01/google-analytics-gdpr-violation/?mtm_campaign=newsletter_2022_01_21
    3 points
  17. This week we have ProcessWire 3.0.192 on the dev branch. This is about 20 commits ahead of the previous version and contains 11 issue fixes and 5 pull requests, along with various other updates. PR code contributors in this version including Daun, MrSnoozles, Radon8472, BernhardBaumrock and Tyde. Thanks! For more details see the dev branch commit log. In addition to core updates, in recent weeks I've also been working on a new module similar to the PageAutosave (developed for the admin) except that it is for front-end forms. It works with any front-end form (whether home brewed or from something like FormBuilder) and remembers the entered form values every time a field is changed. If the user doesn't submit the form, they get an email with a link to finish filling out the form after a configurable period of time. This is especially nice for order and reservation forms. Accompanying the module is a separate Process module that lets you view all the forms in progress in the admin. Each form entry has its own unique URL, making them easy for users to return to, from any device. Once the user submits the form, the data gets removed from the pending submissions database. This is something I've been meaning to develop for awhile, and with the admin PageAutosave module still fresh on my mind, I thought now was a good time to do it. Thanks for reading, Happy New Year and have a great weekend!
    3 points
  18. @ryanThis is a bit off topic, but I would also support version control for fields/templates as something to maybe concentrate on for this year. There is a lively discussion going on: And Bernhard has already shown an awesome proof of concept in his video:
    3 points
  19. This week we have some improvements to the $pages->findRaw() method. Most of these are based on requested improvements in either GitHub (like #427) or the forums: Support for selecting parent properties/fields in the return value, i.e. $pages->findRaw("selector", "parent.title"); // Example 1 $pages->findRaw("selector", [ 'title', 'parent.title', 'parent.parent.title' ]); // Example 2 Support for selecting page 'meta' data in the return value, i.e. $pages->findRaw("selector", "meta"); // example 1 $pages->findRaw("selector", [ "meta.foo", "meta.bar" ]); // example 2 Support for selecting "references" in the return value. References are other pages that reference the found page(s) via Page reference fields, just like the $page->references() method. $pages->findRaw("selector", "references"); // example 1 $pages->findRaw("selector", [ 'references.title', 'references.url' ]); // example 2 If you want the references to be indexed by field name, just include "references.field" in the requested fields: $pages->findRaw("selector", [ 'references.field', 'references.title', 'references.url' ]); Support for selecting title and/or value from options (FieldtypeOptions) fields, i.e. $pages->findRaw("selector", [ 'my_options_field.*' ]); // example 1 $pages->findRaw("selector", [ 'my_options_field.title', 'my_options_field.value' ]); // example 2 Support for a new "flat" option that flattens multidimensional arrays in return value. This is best explained by an example. Let's say we did this: $pages->findRaw("categories.count>0, limit=1", "title, categories.title" ); And it returns an array similar to this for every matching page: [ 'title' => '2-factor authentication coming to ProcessWire', 'categories' => [ 1035 => [ 'title' => 'Security' ], 1288 => [ 'title' => 'Users' ] ] ] Now let's try the flat option: $pages->findRaw("categories.count>0, limit=1", "title, categories.title", [ 'flat' => true ]); (side note: you might already know this, but fields and options can also be bundled in the selector like this below, which is identical to the above): $pages->findRaw("categories.count>0, fields=title|categories.title, flat=1"); It flattens any multi-dimensional arrays in the return value to be indexed in the same way that you requested them in the $fields argument: [ 'title' => '2-factor authentication coming to ProcessWire', 'categories.title' => [ 1035 => 'Security', 1288 => 'Users' ] ] In addition to these updates for the $pages->findRaw() method, this week there have also been updates to the $sanitizer->float() method and InputfieldFloat module. Now both support numbers with E notation such as 1E-2, 10E-14, -1.253E-5, etc. There are also some new values for the getString option on the float sanitizer. I don't work with this kind of stuff very often, so thanks to @MetaTunes on GitHub for helping to figure it out. Lastly, the ProcessTemplate module also went through a refactoring with some minor improvements this week. Thanks for reading, have a great weekend!
    3 points
  20. @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.
    3 points
  21. @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.
    3 points
  22. Hello, @Frank Schneider! The code is: $content = str_replace('xName', 'something', $content); Have a nice day!
    3 points
  23. 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
    3 points
  24. A user in another forum found a solution!!! <?php header("Cache-Control: no-cache"); header("Content-Type: text/event-stream"); $i = 0; while(true) { $i++; echo "data: value of i = $i\n\n"; echo str_pad('',8186)."\n"; flush(); if(connection_aborted()) break; sleep(1); } Reading the manual about flush() finally broucht me to the correct settings for my setup: <?php header("Cache-Control: no-cache"); header("Content-Type: text/event-stream"); @apache_setenv('no-gzip', 1); @ini_set('zlib.output_compression', 0); @ini_set('implicit_flush', 1); ob_implicit_flush(1); $i = 0; while(true) { $i++; echo "data: value of i = $i\n\n"; flush(); if(connection_aborted()) break; sleep(1); } I've tried several settings before regarding gzip, but nothing worked. For me the ob_implicit_flush(1) made the difference 🙂 https://www.php.net/manual/de/function.flush.php
    2 points
  25. Hi @alexm. Pete is currently helping me with this. Hopefully this week, we'll have a 'pre-sales' forum that anyone can access. We'll use that for issues, wish list, etc. Ideally, we could have done issues in GitHub but Padloper is not an open project. Both pagination and lazy-loading have not yet been implemented. They are high on my todo list, especially the latter.
    2 points
  26. @kongondo where is best to submit a list of things I find. These aren't necessary issues, so didn't know if you want them submitted to Github as that's the frontend shop. One I have in mind is that I have a product with 711 variations (ridics I know) and I know we've discussed this before with your Variations module, which is integrated into Padloper 2 in a new form. But i'm wondering if you kept the pagination feature as my variations all show as one huge list.
    2 points
  27. Hi all, Not sure if if everyone has jumped to SeoMaestro these days but I'm still fond of MarkupSeo and it's still live in many of our sites so I've made a few small but important tweaks based on real world usage. @adrian I've just made a pull request with these changes to your fixes branch in case others find these changes useful: Stopped canonical links from being able to inherit from parent pages: Inherited canonical links could cause problems with search engine indexing whereby you're inadvertently telling Google your new page is the same as another purely because you (or a client) missed the canonical field. So I think it is better for the default to be current page URL if the field is left blank rather than inherit the parent. Implemented handling of relative URLs in the canonical field: You can now use relative URLs in the canonical field for internal links. They will still render on the front end as SEO-friendly absolute URLs, but this way it is easier if you use different domains for testing or if you need to change the site domain. (https://github.com/mrjcgoodwin/MarkupSEO/tree/various-fixes-enhancements)
    2 points
  28. Yes, currently generating diagramms by code definition in the editor, but planning to let generate diagramms by parent-child relations in a future iteration. Its good for now and me but not that user-friendly 🙂
    2 points
  29. @bernhard Thanks you very much, it works for new pages, for old i update status1021, status1022 fields to "1" directly to db and translation appears. 👍
    2 points
  30. Thanks for looking at this Adam. I just got a colleague who uses Apple for everything to test and it allowed tapping her Apple watch to login and Face ID. She's got another device to try later with fingerprint but it does sound like it does all devices which is nice, and gives plenty of options, so seems like where things are going in the future. If there are changes required to the base TFA class to help in any way let me know and I can ask Ryan 🙂 Sometimes things won't be hookable that it would be helpful to be hookable etc. I think with WebAuthn It would be more useful if the base class allowed for more keys to be stored per module right, so then per-website I could set it to allow login via facial recognition and fingerprint on the same app - that sort of thing - rather than just allowing one key per module which I think is how it works now? Also happy to help/test in any way I can on this one. As I say for me it's not a huge thing the current module stopping working as I have alternatives, but WebAuthn has me a little excited as it seems like a more natural way to allow people to login.
    2 points
  31. @kongondo can you remind me on Monday and I'll get a forum set up? Not sure if we should call it Padloper Pre-Sales or something and have a pinned topic at the top saying for paid support to request access to the other forum or something like that?
    2 points
  32. Chrome. The worlds worst browser as always. Making web developers lifes a pain lol Moving to Webauthn is a possibility. but the is few PHP libraries for it and one of them claims to be "simple" and the example is over 350 lines of code. So I might not get it done by Febuary 😞 its a big task and essentially makes this a full plugin rewrite
    2 points
  33. There are also some other alternatives besides matomo with plausible analytics or fathom analytics. I personally like those because they generally also do less. Most people don't actually need all the fancy advanced features anyways.
    2 points
  34. I'd be curious how the other tools with file based config manage changes over time. My biggest problem with file based config (over file based migration) is that it'll only give you the current state you want things to be in, but no indication of which state the system is coming from and how to actually make data already in the system(db) be migrated to the new expected state. I'm not aware of declarative systems being able to handle that, which to me severly limits usefulness. It might be great in the beginning of a project, where you can scrap existing data, but won't work at all once old data needs to be maintained going forward.
    2 points
  35. I am more excited about the recorder than about YAML. And I see your point. When using a PHP array for the migrate() method, you can do things that you can't do in YAML. But on the other hand, for recording changes locally and than migrating them to staging/live, YAML would be sufficient. Your use case, where you setup fields and templates for a RockMails module with RockMigrations is different. When installing that module, it needs to check whether it is being installed on a multilang site or not. But when recording and migrating changes, we already know the context for the migration since it has been recorded through YAML. My conclusion would be to store the recorded data in YAML or JSON. For other use cases, like you described, we can still use a PHP array.
    2 points
  36. That's exactly what I always think. It already bugs me with Docker Compose and also with other tools. But your recorder looks really cool 🙂
    2 points
  37. Good catch - thanks for noticing that - I'm not on it this morning apparently :) Well @Ivan Gretsky - at least using $config->paths->data should work for you. I'll still keep an eye on that $maxItems setting and implement when available and see if it handles that other situation.
    2 points
  38. Well that's two different dumps... one is dumping the array and one is dumping an object that has an array inside the data property! d($config->paths); d($config->paths->data); Personally I think that behaviour is good 🙂
    2 points
  39. Hi @Ivan Gretsky That's how it works for me. In your case, you can create a controller for 'b' template that extends your 'a' template, call the parent init method and then set template for the view class PostsController extends CategoryController { public function init() { parent::init(); $this->view->setTemplate('category'); } }
    2 points
  40. 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.
    2 points
  41. 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.
    2 points
  42. Thanks 😊. I will check out RockSEO. The thing that has kept us on MarkupSEO to date is the simplicity for implementation and also for clients. Combined with the changes you’ve made previously it’s pretty effective at doing what it needs to. I’ll have a think if there’s anything else that can be done to improve it further.
    1 point
  43. Finally an authority that stands up and no longer follows main stream and established behavior. Trying not to be a sheep doesn't get much support or likes Matomo is not like it used to be anymore https://matomo.org/pricing/ My 5cts for an alternative, I use bbclone a lot as it gives just enough in most cases https://www.bbclone.de/features.php
    1 point
  44. 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".
    1 point
  45. With Formbuilder you can save your submitted data either as entries or normal pages. You may then query those entries or pages and output them as you see fit. Thoroughly sanitized I don't see why this wouldn't work. Depends on your Processwire skills. But I am sure there are people in the forum with more experience in that matter.
    1 point
  46. Thanks marcus and Martijn. I found the saveModuleConfigData() method last night and ended up using: $this->modules->saveModuleConfigData($this, self::getDefaultData()); Works like a charm!
    1 point
×
×
  • Create New...