Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 05/16/2022 in Posts

  1. 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
  2. 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
  3. 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
  4. 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.
    10 points
  5. 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
  6. @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
  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.
    5 points
  8. 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
  9. And installing less in addition. Really no big deal, but just saying 🙂
    4 points
  10. @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
  11. Updated for PW 3.0.200 master. Download here: https://github.com/apeisa/Finnish-ProcessWire/archive/refs/tags/v.3.0.200.zip
    3 points
  12. Thx. The latest ProField Repeater Matrix has the option (input tab) to define the method for adding items. When you choose Images you get the overlay. By default, the image of the matrix type have the same name and be placed along with the type file location (for example: /site/templates/fields/modules_page/matrix_type.php => site/templates/fields/modules_page/matrix_type.svg). Preparing a good looking Image is just up to you then 😉
    3 points
  13. hi, even it's a funny idea as - you'll be multiplying duplicate contents between this latest-article and... the latest article - the content of this latest-article will change quite often it's quite easy to achive, just use $pages->find with template and sort by -date (with your own field naming convention) to get the id of your latest article on top of the code and then use $pages->get(xxxx)->content and so on to display the latest article content/images/... in the page hope it helps have a nice day
    3 points
  14. You can do this with a little bit of extra CSS. This example is what i use for a radio select .Inputfield_select_option input + .pw-no-select { position: relative; padding-top: 70px; margin-bottom: 20px; width: 100%; display: inline-block; text-align: center; color: #333; font-size: 14px; cursor: pointer; } .Inputfield_select_option input + .pw-no-select::before { content: ""; position: absolute; width: 100%; height: 50px; top: 0; left: 0; display: inline-block; background-size: contain; background-position: center; background-repeat: no-repeat; border: #d9e1ea 1px solid; border-radius: 3px; margin-bottom: 5px; } .Inputfield_select_option input:checked + .pw-no-select::before { border: #2a2a2b 2px solid; } #Inputfield_select_option_1 + .pw-no-select::before { background-image: url(images/option1.png); } #Inputfield_select_option_2 + .pw-no-select::before { background-image: url(images/option2.png); } #Inputfield_select_option_3 + .pw-no-select::before { background-image: url(images/option3.png); } To add a custom CSS the link below shows one way of doing so.
    3 points
  15. Hi @fruid You have to turn on advanced mode by setting this in your config.php $config->advanced = true; Than on settings tab on that page you will be able to toggle 'system' checkbox
    2 points
  16. I would definitely be interested... if some client would ask for a (PW integrated) forum. Must be at least 10 years now that I haven't had such a requirement. So I am not sure that there still exists a sizable market for (new) forum softwares...
    2 points
  17. I think Wanze no longer uses PW, it was written here somewhere... "LAST VISITED October 23, 2021"
    2 points
  18. Great website. Thanks for the behind the scene insights.
    2 points
  19. Just because there is no need for this extra. The client is happy what he got. Coming from Typo3...
    2 points
  20. You can translate your "C" inside admin translation files, the right one is: wire--modules--languagesupport--languagesupport-module for each language you can define the setting there. More on setlocale here, if you want to set it via api: Docs
    2 points
  21. You can configure your locale, according to your server settings, inside site/config.php like this: setlocale(LC_ALL, 'it_IT.UTF-8'); // where 'it_IT.UTF-8' is MY locale setting. You can find a list of all locales here on Stack Overflow
    2 points
  22. That's not always a bad thing - if it ain't broke, don't fix it :) There is the module by bitpoet that works in reverse (I think - I have used that one, but not this one).
    2 points
  23. @creativeguy Usually this behavior indicates that the site is missing an .htaccess file. Check your /Applications/MAMP/htdocs/giftfunds/ directory to make sure there's an .htaccess file in there. I'm guessing there isn't. If you don't have a copy of it, you can get it from here and then rename it to ".htaccess" (with the period in front).
    2 points
  24. I am new to ProcessWire and liking what I see. Could I ask for a bit of guidance. I am building a web archive for my county golf association. We have 90+ clubs. Clubs have players who win championships and/or play for county teams, and the clubs host these events. We have around 12 championships a year with results going back over 100 years. My objective is to be able to select a club, championship or player and see related events / results for each. My data is in csv files and I need to import this [already done the clubs, the import module works great]. My question is re structure and whether, for example, I need to have championship results as a child of the championship main page or whether it would be simpler to create queries to get the data I need. Any guidance much appreciated. Jerry
    2 points
  25. As an option https://processwire.com/blog/posts/pw-3.0.173/#telling-processwire-what-page-to-render
    2 points
  26. Hey @Richard Jedlička just wanted so say thank you as your module is really helpful in my daily work 🙂 Also thank you for your suggestions regarding RockMigrations field context syntax, I'm using that all over and it makes the migration syntax a lot better!! 😎
    2 points
  27. If using "Select options" fieldtype is not a requirement and you just need to have a more visual way to select things, you could use "Page Reference" fieldtype with InputfieldSelectize.
    2 points
  28. That is a classic error message that I get all the time: The Database connection cant be established. Mostly because I forgot one of the things: - Do you have a variable in your config to switch between two development environments (local/live)? So that you are still trying to use your local database settings on your live site? - Do you already have a working PW installation on the remote server? Try checking the config values against the config that refuses the connection
    2 points
  29. 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 🙂
    2 points
  30. It's not often I stumble on parity like this, so grabbed this screenshot for posterity 😁.
    2 points
  31. 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]
    2 points
  32. 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.
    2 points
  33. Hi @wishbone Maybe you can take a look at this module. Gideon
    1 point
  34. New Dynamic Selects Here is a preview of the upcoming update to Dynamic Selects (version 008). It is still early days and I don't currently have an ETA. This upgrade redefines the 'select' in Dynamic Selects. You are no longer tied to this <select></select>. This upgrade will give developers control over how they would like to have their Dynamic Selects rendered both in the Inputfield and in the frontend. This is possible thanks to htmx and ProcessWire's TemplateFile class. These allow for partial rendering of templates generated server-side. For each Dynamic Selects data type (Page, Template, User, Field), there will be a default partial templates which receive an object of that data type. For instance, a Dynamic Select that wants to render children of a selected page will receive the PageArray containing those children at their partial template. Developers wanting total control of any partial template will only need to duplicate a partial template and save this to a designated folder under /site (similar to Padloper) and customise that as they wish. This opens up a myriad possibilities. Your markup, your way. You want to render a HTML table, fine. An accordion? Fine. A photo gallery? Why not! The above also means all ProcessWire fields, including custom ones will be supported. This is because the partial template will receive the relevant object. With custom partial templates, this leads to endless possibilities. Repeaters, complex fields, any field. You could even combine this with Padloper to allow your customers to search for or preview products in very creative ways. Because these new version uses template partials, it means you can employ access controls in any part of the Dynamic Selects , for instance, show different fields or markup depending on user's location or if logged in, etc. Using the power of htmx, it also means you can output markup to different places simultaneously (Out of Band Swaps). @999design, this could cover your need in your post above about triggering more than 1 select.
    1 point
  35. Good day, @BitPoet! Are you planning to merge dev branch to have a new stable?
    1 point
  36. Hello Juergen, I uploaded the new FrontendForms.module and everthing is fine now. No warnings in back-end or front-end. This is a very handy and helpful module for building forms. I just miss the examples you have included in the previous versions of the module - they were very informative; it's a pity I didn't kept them after the updates. You have done a very good job. Thank you for your efforts and hard trying. Best regards, Constantine
    1 point
  37. Thanks @ryan - I'm Shawn, and my friend that passed was Anthony Taylor. Apparently he corresponded with you to some extent. It was the htaccess as you said. Thanks for the help.
    1 point
  38. 1 point
  39. @Manaus This is a case where you should do a 302 redirect $session->location($article->url); rather than render different articles at the same URL. Otherwise folks won't be able to accurately bookmark it, and it'll confuse search engines, so it'd be an SEO problem. But I'll assume you know that and you want to do it anyway. What Zeka mentioned above is a good way to go, and probably the one I'd choose. But here's also another option below. It assumes you have a "latest-article" template and it is used by the page /latest-article/. /site/templates/latest-article.php $article = $pages->findOne("parent=/articles, sort=-created"); if(!$article->id) wire404(); echo $article->render(); If you are using prepend/append template files, then you'd also want to check the box to disable them in Setup > Templates > latest-article > Files (tab).
    1 point
  40. Hi I created new module for adding links to quickly edit a field directly from page edit. https://processwire.com/modules/admin-helper-links/ You probably already know existing module HelperFieldLinks created by @Soma which was my inspiration. I was using that module for a long time so thank you @Soma! The reasons for this new module are that HelperFieldLinks seems inactive and contains few bugs. I decided to try to fix them, but after a short time I realized a better (i think) and simpler solution and also got some new ideas how to improve. I used javascript instead of PHP and modified a code which is already in PW source code to show field names when you hover the inputfield's expand arrow (in debug mode). I also moved the cog icon next to the expand icons which doen't break the layout so much. What is missing is the field info panel with it's props, never used it, but it can be done too. The template edit links needs to be added too. If you got some ideas how to improve, tell me.
    1 point
  41. It doesn't make sense to put the parent path in a check against the page template, but you can check the parent path separately: if($page->template != 'booking') return; if($page->parent->path !== '/nya-bokningar/') return; // The rest of your hook code...
    1 point
  42. @Nick Belane Hi, fixed it but haven't found the origin of the issue. I just downloaded the latest PW (3.0.184 by the time) and replaced the wire directory, index.php and htaccess by hand. But as the current master meanwhile is 3.0.200, try to repeat the upgrade steps. Maybe there is no issue with this particular upgrade. Even though, you should be save to replace the mentioned dirs/files by hand (Nonetheless i recommend backing up all relevant folders).
    1 point
  43. thank you!! when I understood it's not a matter of the pw-install, I searched again - and I don't believe how easy it was: the database name was casus sensitive. I had the prefix in capitals: DB... how many hours! learnt also that it's ok to just copy all the files from local to remote without new install thx again
    1 point
  44. Repeater fields give you a PageArray. Have you tried getPageByID($id) to retrieve the item? Check the return value before removing. It might be NullPage, or when using get() it might be null. As a matter of fact, since you already know the ID, it should be perfectly safe to just delete the page: $pages->get($id)->delete();
    1 point
  45. My guess would be that it's the line getting a value for $event where things start to go wrong. I'm wondering in particular where you're getting the value of $id from, and whether it's valid? You might want to try var_dump() to check whether $event actually is an object (and if so, if it looks as if it might be a repeater item): var_dump($event);
    1 point
  46. Hi there, I had a brief look at livewire and hotwire - and I love the concepts behind them. I really dislike having to choose between making a SPA or a server side site, the two paradigms are so different and hard to mix. If I understand live-/hotwire right it could mean a single paradigm for both client and server data manipulation, which I haven't experience since visual basic 6 :P To be able to model a regular PW site and then sprinkle it with app-like behaviours here and there would be absolutely incredible. I almost considering stepping over to Laravel for this reason, but it's a big step for me. Neither livewire or hotwire seems to exist without Rails or Laravel. So this seems to be a must. Anyone had experience with this, or something similar? Is there something similar that would work with PW?
    1 point
  47. This module allows you to automatically send an email to a newly created user with their username and password. It also has the option to automatically generate a password for the user upon creation. http://modules.processwire.com/modules/email-new-user/ https://github.com/adrianbj/EmailNewUser The following things are configurable: Whether Send Email option should be automatically checked when creating new user - also affects new users created via API From email address (if left blank it will use the admin email set in the config/php file Email subject Email body - includes the ability to use any fields from the user template using {field_name} codes so these can be put into the body wherever you want. It's your choice if you want to include the password in the email or not. Whether to automatically generate a password. This can be toggled on/off, but even if it is on, you can override it by simply entering a password manually when creating the new user. Ability to control the length and character sets used to make up the automatically generated password. Option to send a test email to yourself to make sure it is configured the way you expect. Because it is generally not a good idea to email passwords, it is highly recommended to use the new Password Force Change module in conjunction with this module. That way the user has to change their password the first time they login which will somewhat reduce the vulnerability of emailing the password. It can also be used for API generated users: $modules->get("EmailNewUser"); // call the module since it is not autoload on the front end $newuser = new User(); $newuser->name = 'newuser'; $newuser->email = 'newuser@gmail.com'; $newuser->sendEmail = true; // only needed if Automatic Email Send is unchecked $newuser->save(); Please let me know if you have any ideas for improvements. PS Thanks to everyone in this post: https://processwire.com/talk/topic/2981-new-user-welcome-message/ for their thoughts and ideas on how to do this.
    1 point
  48. I've been doing something very similar -- might I suggest a small change to the page selector to eliminate the need to check for the current page in your foreach loop? // Find the pages that use the specified tag -- and ensure the current page is excluded $articles = $pages->find("template=basic-page, id!={$page->id}, tags.title=$tag, limit=8"); This way, you always get 8 results (if there are that many, of course), whereas excluding page from the loop would leave you with 7 pages.
    1 point
×
×
  • Create New...