Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 04/23/2022 in Posts

  1. This new main/master version has more than 220 commits, resolves more than 80 issues, adds numerous new features, performance improvements and optimizations, and consumes HALF the disk space of our previous release— https://processwire.com/blog/posts/pw-3.0.200/ I've just merged the dev branch to the master branch so this new version is available now. I will add the 3.0.200 tag (which should trigger packagist and others) over this weekend or Monday.
    37 points
  2. It's been a quiet week on the dev branch (mostly), and so this post will also be short. That's a good thing, as it means we are at a stage where there's no new major things to immediately fix or add. Assuming that remains the case, by next week at this time we should have 3.0.200 released on the main/master branch. In next week's post I plan to outline all that's changed since our last master version, 3.0.184, stay tuned and have a great weekend!
    22 points
  3. We had a smooth rollout of the new main/master version 3.0.200 last week (read all about it here). If you haven't upgraded yet, consider doing so, this new version is a great upgrade. I'm going to add the 3.0.200 tag shortly after I finish this post, which should trigger other services (like packagist) to upgrade. I've had a new client project in the pipeline that I've been waiting to start till the new main/master version was out, so this week I started that project. Pete and I are working together on it, like we've worked on others before. It involves taking a popular WordPress site and rebuilding it completely in ProcessWire. I've done this a couple times before, but this time it's bigger and broader in scope. I always find the large site conversions to be great learning experiences, as well as great opportunities to show how ProcessWire can achieve many things relative to WordPress, in this case. At this stage, I'm having to spend a lot of time in WordPress just to get familiar with the content, fields, etc., as well as in the theme files (php and twig). The more time I spend in these, the more excited I get about moving it into ProcessWire. For this particular site, moving from WordPress into ProcessWire is going to result in a big boost in efficiency, maintainability, and performance. Part of that is just the nature of PW relative to the nature of WP. But part of it is also that the WP version of the site is kind of a disorganized patchwork of plugins, code files, and 3rd party services, all kind of duct taped together in an undeniably confused, undisciplined and fragile manner. (Though you'd never know it by looking at the front-end of the site, which is quite nice). This has been a common theme among WordPress sites I've dug into. Though to be fair I don't think that's necessarily the fault of WordPress itself. I always enjoy taking a hodgepodge and turning it into an efficient, performant and secure ProcessWire site. I love seeing the difference it makes to clients and their future by taking something perceived as a "necessary liability to run the business", and then turning it into the most trusted asset. I think the same is true for a lot of us here. We love to develop sites because it's an opportunity to make a big difference to our clients… and it's fun. Ironically, if past history is any indicator, I seem to get the most done on the core (and modules) when I'm actively developing a site. Needs just pop up a lot more. I don't know if that'll be the case this time or not, but I do expect to have weeks with lots of core updates and some weeks with no core updates, just depending on where we are in the project. This particular project has to launch phase 1 by sometime in July, which is kind of a tight schedule, and that may slow core updates temporarily, but who knows. I'll share more on this project and what we learn in this WP-to-PW conversion in the coming weeks. Thanks for reading and have a great weekend!
    21 points
  4. This week's commits for ProcessWire 3.0.199 focus primarily in wrapping up several remaining reported issues in preparation for our master/main release version. So you can think of 3.0.199 as very close to a release candidate for the next master/main version. A few of the issues resolved this week were ones that had been around a long time, due to being difficult to reproduce, or issues that had been held off for awhile because they were going to take additional time to resolve. (See commit log for details). Having closed out a few of those older issues this week, I'm feeling good about where the dev branch is right now and think we're just about there. If you have a chance to test out the current dev branch (3.0.199), please let us know if you run into any issues. At least one person has asked about why we're not bumping the version to 3.1 (previously, or now). The reason is that all 200 versions of 3.x should be compatible with each other, enabling one to upgrade (or potentially downgrade) between the 3.x versions, without any drama. That's a good thing I think, and so I'm kind of proud that we are approaching version 3.0.200, which will hopefully be our next master. I'm sure we'll have a 3.1 at some point in time, but I'd like to keep on the 3.0.x track so long as upgrades remain drama free. Thanks, and have a great weekend!
    19 points
  5. A week ago the new website of the wuppermann group went online. The Wupperman group is a EU-wide operating company with several locations in different countries. Their portfolio is all about steel fabrication. This includes flat producs and tubes & profiles. The technical production is developed by me, Olaf Gleba. The basic grafic design is supplied by C&G: Strategische Kommunikation GmbH. Homepage: https://www.wuppermann.com Some Impressions: (Secured) Shareholder portal, only available in german language Technical notes: 1. All contents are populated by provided (i name them) content modules (e.g. Repeater Matrix Types) which gets the customer what he needs and either prevent them from doing weird stuff. In nearly all textareas formatting is limited to a absolute minimum. For example, image insertion in CKEditor is generally prohibited. Instead there are dedicated fields for modules which holds media content. 2. This and that.. - vCards are build on the fly with a admin hook on page save. - PrivacyWire as CCM (just a few cookies to handle Matomo and external movie content) - Uses the SearchEngine Module to handle (multilanguage) site search - Email Obfuscation Module for frontend e-mail addresses - Wire Mail Smtp to deliver automated e-mails - Multilingual (currently german, english). Hungerian, polish, dutch following. - Ajax driven content (for example on the contact page) - Heavy use of Fieldtype AssistedURL (Fork by @adrian) to provide language dependend, local file linking (fieldname_[de|en] approach) - Login area (shareholder portal) with secured file downloads ($config->pagefileSecure = true) - Email New User, Admin Action (create users batcher), Force Password Change for functionality like adding new users with specific roles, Password reset, Change Passwort a.s.o. - Distribution of concatenate/minified css and javascript is cachebusted (happens within my developement environment,- no modules (like AIOM etc.) involved). - Thanks to @ryan* all images are delivered in WEBP format (with fallback). *) s. https://github.com/processwire/processwire-issues/issues/1497 - The site uses a bunch of modules provided by the ProFields Package (for example the Combo, Repeater Matrix and Table Fieldtypes).
    15 points
  6. Triasima, a portfolio management company, asked the agency Contractuelle to revamp its web image. Spiria was the contractor for the site integration. While seemingly straightforward, there were a few challenges ahead, including managing three distinct regions that shared a lot of content: Canada, the United States and the Rest of the World. Two of these regions were assigned a sub-domain (us. and world.). We did not need a multi-site module. Within each region, the visitor has to choose a type of investment profile. One of these profiles could only be selected by the Canadian region. Each profile shares some content but is identified by colour. In short, a small puzzle solved with very little code and CSS. We made extensive use of field repeaters to create a nice administration interface. We have designed "presentation scenarios" that allow the administrator to set up pages as they wish. Only the header and footer are fixed. https://triasima.com
    15 points
  7. @Robin S @bernhard @teppo I would say it's less important to limit how many fields you create than it was before, but it's still worthwhile to make efficient use of fields for other reasons (at least for the way I work). But the technical reasons for doing so appear to be much less than before. If you look here at the performance numbers on a system with 1000 fields you can see that prior to lazy loading, it took 0.5167 ms (half second) to load the fields. This might sound reasonable, but note the fields were created with an automated script and not as diverse as they would be in a real environment, so I'd expect the numbers to be higher/slower in real life. After lazy loading that part of the boot process was reduce to 0.0062 ms. Even without lazy loading enabled, the field loading was reduced to 0.0322 ms (in that 1000 field environment) just due to the other optimizations made in support of lazy loading. So there's some question as to whether lazy loading is even necessary anymore now that everything else more optimized. But using less time and energy is always good thing, even if not felt on individual requests, small differences add up to significant numbers over thousands of requests. The way lazy loading works is that everything in the database table (for fields, templates, fieldgroups) still gets selected and loaded, but into an array rather than into objects. That data doesn't get loaded into and converted to actual Field (or Template, Fieldgroup) objects until that specific object is requested. TheTuningSpoon found that overhead came from actually creating and loading the objects rather than selecting them from the DB, and I was able to confirm that. But it also means that the more fields you have, the more memory they will consume. But the memory consumed by the raw field data is very little and I think you'd have to have many thousands of them for it to even be a consideration. Lazy loading fields don't change the way I use fields, at least. I like to have as few fields as necessary just because it's easier for me to keep track of, fewer things to remember when writing code, fewer things to manage during changes, etc. But if your workflow is like the one Bernhard describes above then that seems like a case where more fields would appear to be a benefit.
    12 points
  8. We upgraded a big multi language site to 3.0.200 and to PHP 8* + MySQL 8 a couple of days ago, several thousands pages, lots of templates and fields (120MB DB). The upgrade went fine, and the site is running super fast! I didn't measure with tools, but just by reaching the URLs of some complex pages and you can see it loading waaay faster. The client could not be happier. 😃 Fantastic job, Ryan and the other contributors! Thank you, Sergio --- * I used RectorPHP to help upgrading my custom modules, which was nice.
    11 points
  9. Hey everybody, I just uploaded a small textformatter module for wrapping tables with a div container in order to display responsive HTML tables in the frontend. TextformatterWrapTable Processwire wrap table module is a textformatter module for processwire CMS/CMF. It is wrapping markup tables with a div container. wrapping tables with div container simplifies the process of displaying responsive tables in the frontend. The css classes for the wrapper and the table are configurable. .table-responsive / .table by default the module produces the following markup: <div class="table-responsive"> <table class="table"> ... </table> </div> Link to Repository https://github.com/pmichaelis/TextformatterWrapTable
    9 points
  10. This week on the dev branch we've got a good mix of updates and issue resolutions, though not quite yet enough yet to bump the version number just yet. But here's a few highlights: There's a PR from Adrian committed which adds configurable columns for Selector fields. System update 20 was added which fixes the "created user" for several system pages. WireHttp was updated to support sending cookies in GET/POST requests powered by CURL. Lister was updated to recognize non-sortable fields, preventing unnecessary error messages. There were also 3 issue resolutions this week. We are getting down to the smaller stuff in terms of updates, which means it's about time to get that next master version out. I know I've been talking about it for awhile, but think we'll likely have one more dev branch version (3.0.199) and then it's looking like our 200th 3.x version will tentatively be the next master version (3.0.200). Thanks for reading, Happy Earth Day, and have a great weekend!
    8 points
  11. I always start from scratch when it comes to creating the fields and templates, and basic site structure, but rarely when it comes to the pages/content. On previous conversions I've gone into WP’s database and exports to migrate content. This new case is a little bit unique in that WordPress couldn't do everything they needed, at least not in a manner that was affordable or reasonable to implement, from what I understand. While some of the content is in WP, other content is coming from authenticated web services. Lots of the pages have some content, custom fields and repeatable blocks in WP, but there are also custom fields with IDs for external services that it pulls other content from at runtime. They are paying a couple other companies quite a bit of money every month to host their content through these web services and make it searchable. They pull from those services at runtime and output it all from the WP templates. It strikes me as really inefficient, but it all works fine and you'd never know it from the front-end. But it's also expensive for them and fragile to have these kinds of external dependencies, not to mention a pain to have to manage content (even for the same page) across different services. This is all stuff that ProcessWire does well on its own, so none of those external services are needed on the new site. Since the front-end of the site is already compiling them all into single-page output, I built a scraper to pull it directly from the existing site and put it into the right places in ProcessWire. Scraping might seem like a last resort, but in this case it was the fastest, most direct way to pull everything out since the content is split among different databases and services. Basically using WP as an adaptor for the services it is pulling from. Luckily I can edit the WP templates to modify the markup (adding wrapping tags or custom html id attributes, etc.) where needed make the scraper relatively simple. @MarkE
    7 points
  12. These always trip me up, I get all excited by a big blog post and then it turns out I already know everything from following your lovely weekly threads 😄 Great stuff as always!
    7 points
  13. For me the opposite is true 😉 The main reason for that might be my workflows around RockMigrations and custom page classes. Having the fields defined in code directly in the page class is so much easier for me than any other approach I tried. So those additions where very welcome ones for me 🙂 Need some new data for a boat? Go to the boat pageclass file and add a field there. Need a new field for every blog post? Go to the blog post pageclass file and add it... I'm only sharing fields across templates (page classes) when they really have the same purpose (eg a RockMatrix field for the pages content that has several content-blocks like headline, text, quote, etc that should be the same for templates home, basic-page and blog-item). So adding a new content block like "image" for example would make it available on all those templates immediately compared to having to update all templates one by one and adding the new image block to three different fields. For me it feels a lot better to have a single field for a single purpose. Sharing a field for different purposes by overriding settings in template context never felt good to me... I'm using template context a lot, but only to do simple modifications like tweaking the field's label (eg of the title field). One huge benefit of such an approach can be that you get reusable components that you can simply copy from one project to another. That's because the page classes do NOT share fields with other components of your site and therefore are self-contained parts that work on their own. That would not be possible if you shared fields from a central place. Or it would be a pain to reuse single parts of that website. I have been there. I don't want back 🙂
    6 points
  14. Congrats @ryan and the whole community!😄
    6 points
  15. Like caniuse.com but for PHP, eg: https://caniphp.com/?s=null It is possible to support the project: https://ko-fi.com/magicroundabout https://github.com/rosswintle/can-i-php Happy coding! :)
    6 points
  16. I'm a big fan of HTMX. It's kindof like "lower level" than hotwire and not sure if even comparable to Livewire. And there is also the Intertia.js adapter if you want to take a look.
    6 points
  17. Great news! Having a recent master version is always a good thing. And maybe it is a good time to think about the roadmap for the future? Maybe even about those breaking changes, that could make 3.1 от even 4.0 a necessity? Something that revolutionize PW dev once again. I remember when 3.0 was planning. I didn't even understand what namespaces are back then)) But now I can't imagine staying at 2.x and love that that move was made on time. What is the next step?
    6 points
  18. @JerryDi I don't think there's a right answer as to what would be the best structure for your case. It really comes down to your needs, which I don't have enough familiarity with this to give an ideal answer. You'll be able to build your search for championships by club, player, etc., either way, as PW will make that simple. You can have any kind of parent/child relationship for those championships such as… /years/year-num/championship-name/ /clubs/club-name/championship-name/ …and so on. But another route to take (and what I might recommend here) would be to have a /championships/ parent and have all the championships under there, perhaps auto-sorted by year. Each with fields for "year", "club", "players", etc. /championships/championship-name/ And perhaps fields like "club" and "players" on each championship page would be page references to other pages setup in a similar structure: /clubs/club-name/ /players/player-name/ …and so on. Taking this route (where all championships share a common parent) may not be perfect for any one need, but will likely be a good fit for a diverse range of needs, a solid choice overall. So without knowing the details of your needs that's the route I'd probably take.
    5 points
  19. It's not often I stumble on parity like this, so grabbed this screenshot for posterity 😁.
    5 points
  20. Wow, what an awesome list of improvements! @ryan, I have a question about the lazy-loading of fields. Do you think this change means that the previous recommendation to reuse fields, as in the "Making efficient use of fields in ProcessWire" blog post, is now no longer needed? Say I am using text fields in lots of different templates for different purposes, and if I create and name fields so they describe the use in each template I will have 50 text fields, or if named them generically and reused them I would have maybe 5 text fields. Is their any reason now to prefer the 5 fields option over the 50 fields option, given that in any one template I'll only have 5 text fields or less and so presumably only ~5 or less fields get fully loaded at a time?
    5 points
  21. 5 points
  22. I think person 2 sees page B in 2 seconds. I did a kind of test... I have two pages and two templates: page "Yellow" uses template "colour" and page "A Basic Page" uses template "basic_page". There's nothing special about the template file for basic_page but in the template file for colour I have: sleep(30); If I load page Yellow in one tab and then immediately load A Basic Page in another tab then I have to wait 30 seconds to view either page. But if I load page Yellow in one tab and then immediately load A Basic Page in an incognito window (which will have a different session) then the page loads immediately.
    5 points
  23. The company I work for in central Connecticut, Solution Innovators, is looking to hire a programmer with ProcessWire experience to join our small but growing team. We've been working with PW since 2012 and have numerous marketing sites and web applications built on it. Strong PHP skills are a must, with experience building object oriented systems and organizing and documenting code in a clean, maintainable and reusable fashion (like the ProcessWire core). Skills in Vue.js, javascript, jQuery, html, and css are a plus. DM me for more information!
    5 points
  24. Hi @Gideon So, I will prepare something, but it's mostly taking advantage of the Repeating fields.
    5 points
  25. @fruid I'm sorry for providing only small bits of help only but you can also consider using URL hooks instead of putting both "normal page rendering" and AJAX responses into the same template file. See: https://processwire.com/blog/posts/pw-3.0.173/ In one way it is cleaner and more flexible than putting both responses into the very same file, but of course, you have to "manage" the two different responses in different files in this way. Another way of separating AJAX request/responses from the page request is to use URL segments, but with URL hooks available since PW 3.0.173, I would not use that technique anymore.
    5 points
  26. @theoretic Sounds like a fun project. If I understand correctly, you are doing a select to read the value, then incrementing the value in PHP, then writing the value. With concurrent requests doing that, there's always a gap between the read and the write, so you should expect that some of the requests are naturally going to collide, unless you use a different strategy. What you probably need instead is a single update query that does a "col=col+1" instead. Otherwise you'll have multiple requests reading a value (like the number "3"), incrementing it, then writing the same number "4" to the DB. So the final number would always be less than the number of requests sent. The reason being that some other request may have incremented the value in between the time another request read and then wrote the value, so they'd always be overwriting each other, writing the same "4" to the DB. If you need separate read/write queries, you'd need to obtain both a read and write lock to the table row you intend to update, before you even read the value. And you'd need to release the lock after you write the value. You'd also have to account for the cases where you cannot obtain a lock (due to being locked by another request), by having a retry mechanism. Without a retry mechanism, you'll also end up with some unaccounted for requests. A good example of the pattern you are trying to achieve is implemented in the SessionHandlerDB module. It has to obtain a read/write row lock and read the session values. Then at the end of the request, it has to write the session values, then release the row lock. That way concurrent requests in the same session can't overwrite each other's data. But it also means that concurrent requests are queued and have to wait in line for their turn to control the data. The same would be true in your test case. Lastly, pay attention to the http response code on the concurrent requests. Requests can be refused, especially if concurrent from the same session or IP. They can be refused by Apache or PW. So a request cannot count towards a total unless it returns a "200 OK" response code (this would be true for any concurrent testing of web requests whether w/PW or elsewhere).
    5 points
  27. If you are working with CSV, don't forget about the new $files->getCSV() 🙂 while($row = $files->getCSV('/path/to/foods.csv')) { echo "Food: $row[Food] "; echo "Type: $row[Type] "; echo "Color: $row[Color] "; } https://processwire.com/talk/topic/26929-pw-30197-– core-updates/
    5 points
  28. Hello folks, I was working on a forum module which is about 65% done and was wondering if there would be enough interest to continue development. This would be a paid module of course due to the amount of time involved. I should have my workspace set back up in a few weeks, but later today I'll get a feature list and some screenshots of what I have so far and add them to this thread. Thanks for your time 😎
    4 points
  29. And installing less in addition. Really no big deal, but just saying 🙂
    4 points
  30. @ryan Have you considered putting some new screenshots here? It’s a very popular feature judging from showcase threads, developers here love to show off their images to great effect (it was also asked about in this recent thread, for instance), but it gets almost no love in the public docs/store page, and even in the introductory blog post it can only be seen for a split second in the video. The images in the video are also kind of grey in comparison to @olafgleba’s beautiful display 😄 I’m sure showing it off on the store page would boost sales some!
    4 points
  31. Congrats @ryan that's a really great achievement 🙂 Also thx to @matjazp for all your help on the github issues - great work!
    4 points
  32. @Matzn that not.how obj inheritennce work { .clsses inherit code not runs time valus } class A{public $foo;} class B extends A{} $a=new A(); $a->foo='Foo'; $b=new B(); echo $a->foo; // 'Foo' echo $b->foo; // emptys.. nothing modules work.same { .mabe.u want this in you TestModuleChild ? } >>> public function __construct(){ $this->setArray($this->modules->getConfig('TestModule')); }
    4 points
  33. Hello, We have been audited by a security firm regarding a new website in Processwire. The client is a financial firm and insurance companies are becoming increasingly wary of the vulnerabilities that certain libraries represent. The report mentions the two obsolete jQuery libraries that ProcessWire uses for the admin part. Although the visitor or potential hackers are not aware of the use of these libraries (and the report does indicate that the site is secure), the report still mentions a moderate risk when it comes to the administration of the site. In short, the following libraries are requested to be updated to remove these vulnerabilities. .../wire/modules/Jquery/JqueryUI/JqueryUI.js .../wire/modules/Jquery/JqueryCore/JqueryCore.js It might be time to upgrade on this side. Is it possible to do this without causing problems in the administration of the site? I can do my own tests, but I would still like to know the reasons why this is not up to date.
    4 points
  34. @fuzenco - new version just committed that also supports integer & decimal field types as well as float.
    4 points
  35. @DrQuincy Is this from a template file? You could do this: echo "<p>An error occurred!</p>"; return $this->halt(); That halts the rendering of output but lets PW finish everything else in the request. Another option is to throw a WireException. This will also halt the request but allow PW to still shutdown. The response is an http 500 error. The error message will be displayed if in debug mode or if the user is logged in and a superuser. throw new WireException("An error occurred!"); Often times on the front end a fatal error is about a resource not available, and a 404 is the appropriate response. So you can do this: throw new Wire404Exception(); or this does the same thing (I prefer this shorter version): wire404(); Lastly, while the above are preferable, it's also okay to do an exit() or a die(), is shouldn't break anything at least.
    4 points
  36. Hi @Matzn <?php namespace ProcessWire; class ParentModule extends WireData implements Module, ConfigurableModule { public static function getModuleInfo() { return [ 'title' => 'Parent Module', 'version' => 1, ]; } const defaultValue = '12345'; public function __construct() { $this->set('api_user', self::defaultValue); // set default value in construct } public function getApiUser() { return $this->api_user; } public static function getModuleConfigInputfields(array $data) { if(!isset($data['api_user'])) $data['api_user'] = self::defaultValue; $form = new InputfieldWrapper(); $f = wire('modules')->get('InputfieldText'); $f->name = 'api_user'; $f->label = 'API USER'; $f->value = $data['api_user']; $form->add($f); return $form; } } <?php namespace ProcessWire; class ChildModule extends ParentModule { public static function getModuleInfo() { return [ 'title' => 'ChildModule', 'version' => 1 ]; } public function __construct() { parent::__construct(); bd($this->getApiUser()); bd($this->wire()->modules->getModuleConfigData('ParentModule')); } } Take a look at the construct method of ChildModule. Without calling parent::__construct you will not be able to get what you want. Also you can use $this->wire()->modules->getModuleConfigData('ParentModule') to get config data of module.
    4 points
  37. Maybe my https://github.com/joyofpw/inertia module can be of help 🙂
    4 points
  38. @wbmnfktr thanks for starting this topic, very interesting! After reading all replies I think I get your point. I mostly develop with Django (Python) where DRF gives a powerful standardized API centered around models. Still, as you said, while working with other systems I always miss processwire for it's flexibility ;) From what I understood other systems include a REST API out of the box (more or less) where processwire "forces you to write some lines of codes" … and I guess that is the strength of processwire. It does not force you into a one fits all solution. My two cents: For an upcoming project I tested different solutions. With AppApi indeed I got resonable results in not 2 but 15 minutes. With JWT included, nice! (thanks @Sebi) For smaller needs URL hooks … for bigger needs –without auth– PageQueryBoss … –with auth– appAPI, is my way to go. But yes +1 for a core integrated solution that publishs pages based on standards . Doing so it would even be easy to get a clear, understandable and standardized API Documentation.
    4 points
  39. Supposedly this dude is rebuilding it 😛 Ok seriously, trying hard, but my time is also limited right now, I almost have the UI rebuilt in Alpine, just need to wrap my head around the Fieldtype interface. But I'd say it's still at like 20% - 30% I am trying to get a run at it asap to build the bare minimum, without the Markup modules, which I also need anyway lol
    4 points
  40. In addition to the other very valid comments, this is what’s causing the problem as I understand it. ProcessWire will still prepend _init.php for Ajax requests unless you tell it not to. One way might be to wrap these two lines in an if-block in config.php. That will disable the prepend/append files for all Ajax requests, which seems reasonable: if ($config->ajax) { $config->prependTemplateFile = '_init.php'; $config->appendTemplateFile = '_main.php'; } A more flexible approach may be to forego auto-append and just call those files explicitly when you want them. To expand on @szabeszs comment, $config->ajax works by detecting the header “X-Requested-With”, which browsers don’t send by default. If you’re using XMLHttpRequest, you need to add it like this: var request = new XMLHttpRequest(); request.setRequestHeader('X-Requested-With', 'XMLHttpRequest'); If you use the Fetch API, there is a Headers() object you can pass: https://developer.mozilla.org/en-US/docs/Web/API/Headers Jquery sends the header automatically, which is. I believe, why ProcessWire expects it.
    4 points
  41. What about the "X-Requested-With: XMLHttpRequest" header? The $config->ajax call requires that to be sent.
    4 points
  42. Yes, it will break. I gave the link to the blog post introducing "owner" selectors in the code, but here it is again: https://processwire.com/blog/posts/processwire-3.0.95-core-updates/ So this selector... template=colour, select_colour.owner.template=animal, select_colour.owner.id!=$page->id ...is saying... Match pages where: the page template is "colour" and the page is selected in a field named "select_colour" and the page containing the select_colour field is using the template "animal" and the page containing the select_colour field is not the page represented by the $page variable (i.e. the page that is currently open in Page Edit)
    4 points
  43. v0.0.12 now available. This fixes a few bugs and also introduces interactive dependent-selects in the config. Now that both the config and the pages have dependent selects, I thought it would be helpful to demo how it all works. Firstly, the config. On the details tab, you select the quantity you want to measure and then choose what units you want to be selectable within a page (you can also choose whether to convert automatically, not at all, or to 'ask'): New field.mp4 You will realise that we ended that demo just saving with no quantity selected. That's because we can use the same field in different template contexts to measure different quantities. So, next, we are going to add our field to a template and choose 'volume' as the quantity: volume template.mp4 Similarly, we can add our field to a different template to measure mass: mass template.mp4 Finally, we can create a page using one of these templates. In this case, it is 'volume' and we have chosen to convert automatically: volume page.mp4 If we had chosen to 'ask', we would have got a confirmation box before doing the conversion. All of this is accomplished by the magic of htmx (and of course ProcessWire). The principles behind it are discussed at The actual code has moved on a bit from that post. For instance, I have used css transitions in the config. These work really nicely with htmx: #Inputfield_unit_set { opacity: 1; transition: opacity 200ms ease-in; } #Inputfield_unit_set.htmx-swapping { opacity: 0.1; transition: opacity 100ms ease-out; } #Inputfield_unit_set.htmx-settling { opacity: 0.1; } Now I'm getting the hang of htmx, I really like it 😃
    4 points
  44. There is also an option to use cookie and htaccess RewriteEngine On RewriteCond %{HTTP_COOKIE} language=(ua|en) [NC] RewriteCond %{REQUEST_URI} !^/(ua|en)/ [NC] RewriteRule ^(.*)$ /%1/$1 [R=301,L]
    3 points
  45. I can confirm I use this a lot too!! It also merges updates on fields and templates. I think the only caveat I have is that it doesn't work 100% with FieldtypeOptions. And the pages import/export is crazy good, works with absolutely every native field I've tested with, even complex Repeater Matrix/Repeaters. I just recently used it to migrate some old sites, into a new "template field schema" and I cannot even estimate how much work it saved lol
    3 points
  46. @Matzn Your TestModuleChild.module is overriding the getModuleConfigInputfields() of the TestModule.module and replacing it. In PHP, if you want the parent method to run, then you need to either omit the method completely in your child class, or call the method parent::method() so that it will run (like what you are doing with your __construct method). What you are doing currently is replacing the method with one that has no code in it. What I think you are wanting is this in your TestModuleChild.module: public function getModuleConfigInputfields(InputfieldWrapper $inputfields) { parent::getModuleConfigInputfields($inputfields); } After doing the above, now it will inherit the code of the parent class. And after calling that parent::method() maybe you want to add another configuration setting to it, i.e. public function getModuleConfigInputfields(InputfieldWrapper $inputfields) { parent::getModuleConfigInputfields($inputfields); $f = $this->wire()->modules->get('InputfieldText'); $f->attr('name', 'test_field'); $f->label = 'Test field'; $f->val($this->test_field); $inputfields->add($f); } But if you don't want to add anything new to the getModuleConfigInputfields() then just leave the method out of your TestModuleChild.module completely, and it will inherit automatically. Also, module configuration data should be defined with runtime calls, so I recommend you remove this: public $field_1 = "parent module property 1"; and replace it with this in your __construct(): $this->set('field_1', 'parent module property 1'); I see you are using static getModuleInfo() methods in your classes. In cases where you've got one module extending another, unless the child module literally does an include() at the top of the parent module's file, then you should define your child module's info in a ModuleName.info.php file like I described in my previous message (including the 'requires' statement), and omit the getModuleInfo() static method. Otherwise, if PHP/PW happens to include() the child module before the parent module, you'll get a fatal class error. By using a separate ModuleName.info.php, PW can learn about the module without having to load the class file, and it can see from your 'requires' statement that it needs to load the parent module before your child module, ensuring no fatal errors. If you can't do this, or don't want to, then make sure your child module does an include() or require() of the parent module's file, somewhere before your "class TestModuleChild ...".
    3 points
  47. you can set password and other settings in config.php WireMailSmtp/WireMailSmtpConfig.php at master · horst-n/WireMailSmtp · GitHub $config->wiremailsmtp = [ "smtp_password" => "test", ];
    3 points
  48. @thetuningspoon, Thanks for posting this. If possible, please edit your post and address points #1 - 3 as relevant as per the job posting guidelines: E.g. remote working, US-based, similar time zone, etc 😄. Thanks!
    3 points
×
×
  • Create New...