Leaderboard

@bernhard I think you make a really good point and I could see myself using either sorting by name or folder for different projects. 100% agree on the backwards compatibility issue as well. I see the value in having it both ways and a setting would be really great!

Tried to changing the "Content Type" setting on the fields "Text formatters" tab to "Markup/HTML" and everything went crazy, so i quickly changed it back to "Unknown/Text". And all is well. In the front end all the Markdown bunched up in a pile with no line endings or returns when i clicked saved. And in the front end when i went to check on what showed up there, the Markup was unchanged except for some HTML tags had been added. Very strange. But i think for the time being i am going to let Markdown and Front-End editing stay away from each other until we figure out this mystery.

Hey @FireWire thank you very much. Not sure about this one. Some libraries like fontawesome come with dedicated folders, like for solid icons or for brands. In some cases it might make more sense to sort by folder (eg to have all brands together), in others it might be different (like in your example). I don't really want to change the default behaviour as this would change existing installations. I mean... I don't know of anybody besides you and me using this module, but nonetheless I'm not sure if changing the default is a good idea. Maybe we need a setting for that?

That’s how you’re supposed to do it as far as I know. Just swap /wire/ and you’re done. See the docs for more details on .htaccess and /index.php, which you do sometimes need to update, but it doesn’t happen very often: https://processwire.com/docs/start/install/upgrade/ Non-core modules will be installed to /site/modules/ so they are not affected by PW updates. Don’t manually put modules into /wire/modules/! Indeed you should never* change anything in the /wire/ directory at all. *Of course, feel free to hack on the core as much as you like, but you’ll need to take extra steps when updating to avoid wiping out your changes. And updates may break your modifications in other ways, I suppose. I’m not sure it’ll break anything, I guess you’ll have to test it ? ProcessWire caches some information about installed modules in the “caches” database table, so you may need to delete that? But generally I’d imagine things to go smoothly. Yeah, if you update .htaccess you need to make sure to keep the changes you made to suit your environment. It rarely changes, though, so it’s not too messy to just check out the last handfull of diffs and see what you may need to add: https://github.com/processwire/processwire/commits/dev/htaccess.txt. As you can see, the last change was in January, but I’ve gone back a couple of years and really nothing critical happened.

The script is in my templates/init.php file. You have to change the switch statement. Change zh to pt and replace de with es. You need to put google on an exclusion list, so the bot get's not redirected! That is important, because the bot will visit with "en" language and will kick out all other language out of the index, if you force a redirect on them. The redirect function: function crawlerDetect($USER_AGENT){ # Bots we DON'T want to redirected $crawlers = array( 'Google' => 'Google', 'Lighthouse' => 'Chrome-Lighthouse', 'MSN' => 'msnbot', 'Rambler' => 'Rambler', 'Yahoo' => 'Yahoo', 'AbachoBOT' => 'AbachoBOT', 'accoona' => 'Accoona', 'AcoiRobot' => 'AcoiRobot', 'ASPSeek' => 'ASPSeek', 'CrocCrawler' => 'CrocCrawler', 'Dumbot' => 'Dumbot', 'FAST-WebCrawler' => 'FAST-WebCrawler', 'GeonaBot' => 'GeonaBot', 'Gigabot' => 'Gigabot', 'Lycos spider' => 'Lycos', 'MSRBOT' => 'MSRBOT', 'Altavista robot' => 'Scooter', 'AltaVista robot' => 'Altavista', 'ID-Search Bot' => 'IDBot', 'eStyle Bot' => 'eStyle', 'Scrubby robot' => 'Scrubby', 'Facebook' => 'facebookexternalhit', ); $crawlers_agents = implode('|',$crawlers); if (strpos($crawlers_agents, $USER_AGENT) === false) return false; else { return TRUE; } } # The setLang var is that for the hole session it will not enforce the redirect anymore # I have in the footer of my sites a language dropdown as override in case the user want to visit the # other language - or in case the automatic ist wrong $USER_AGENT = $_SERVER['HTTP_USER_AGENT']; if(crawlerDetect($USER_AGENT)) { $session->set('setLang','1'); }; if(!$session->get('setLang')) { if ($_SERVER['HTTP_ACCEPT_LANGUAGE'] != '') { # I take the first two letters of the sended language and compare it in a switch # statement $accept_lang = substr($_SERVER['HTTP_ACCEPT_LANGUAGE'],0,2); switch ($accept_lang) { case 'de': $session->set('setLang','1'); if($page->url != "/") { $url = $page->localUrl('default'); $session->redirect($url); } break; case 'en': $session->set('setLang','1'); if($page->url != "/en/") { $url = $page->localUrl('en'); $session->redirect($url); } break; case 'zh': $session->set('setLang','1'); if($page->url != "/zh-cn/") { $url = $page->localUrl('zh-cn'); $session->redirect($url); } break; default: $session->set('setLang','1'); if($page->url != "/en/") { $url = $page->localUrl('en'); $session->redirect($url); } break; } } else { $session->set('setLang','1'); } }; The dropdown (is building also in the templates/init.php above the redirect function) - also make here the same changes as above, case 'default' to es (your base language set in ProcessWire and zh to pt, and the default case in the bottom to en, as the wish fallback: $current_lang = $languages->getLanguage(); switch ($current_lang->name) { # set all placeholder variable for the users language # also the attribute then for the html tag case 'default': $class_lang = 'language-de-de'; $hreflang = 'de'; $lang_url = $wire->page->localUrl("default"); break; case 'en': $class_lang = ''; $hreflang = 'en'; $lang_url = $wire->page->localUrl("en"); break; case 'zh-cn': $class_lang = ''; $hreflang = 'zh-cn'; $lang_url = $wire->page->localUrl("zh-cn"); break; default: $class_lang = 'language-de-de'; $hreflang = 'de'; $lang_url = $wire->page->localUrl("default"); break; } # The Dropwdon Linkt Text as PRocessWire Language Var, that can be set in the language module $drop_title = __("Sprache ändern"); $lang_li = ''; foreach($languages as $language) { // if(!$page->viewable($language)) continue; // is page viewable in this language? if($language->id == $user->language->id) { $lang_li .= "<li class='current'>"; } else { $lang_li .= "<li>"; $url = $wire->page->localUrl($language); $hreflang_drop = $home->getLanguageValue($language, 'name'); $lang_li .= "<a class='drop-item' hreflang='$hreflang_drop' href='$url'>$language->title</a></li>"; } } # Now comes the dropdonw. Build at with the framework/dropdown lib you want and change it accordingly. $drop_title for the titel of the menu # and then $lang_li for all the collect <li> above $lang_dropdown = ' <div class="dropdown"> <button class="drop-toggle" type="button" aria-expanded="false" onclick="dropFunc()"> <svg width="18px" height="18px" stroke-width="1.5" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg" color="#fff" style="transform: translate(0, 3px);"><path d="M2 5H9M16 5H13.5M9 5L13.5 5M9 5V3M13.5 5C12.6795 7.73513 10.9612 10.3206 9 12.5929M4 17.5C5.58541 16.1411 7.376 14.4744 9 12.5929M9 12.5929C8 11.5 6.4 9.3 6 8.5M9 12.5929L12 15.5" stroke="#fff" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"></path><path d="M13.5 21L14.6429 18M21.5 21L20.3571 18M14.6429 18L17.5 10.5L20.3571 18M14.6429 18H20.3571" stroke="#fff" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"></path></svg> '. $drop_title .' </button> <ul id="drop-menu" class="drop-menu"> '. $lang_li .' </ul> </div> '; Then in my templates/_main.php in the footer, I call $lang_dropdown for the dropdown menu for manual override.

So... at this point you, @BrendonKoz, and others should post all details about their setups to find the issue. Those warnings might not have an impact, BUT they are a very bad look when trying/installing ProcessWire for the very first time. For my current DEV-setups: latest DDEV (Host: Ubuntu 23.10, not virtual) PHP 8.2 MariaDB 10.4 Apache FPM InnoDB, utf8mb4 Latest successful ProcessWire version: 3.0.241 For my current PROD-setups: PHP 7-4 to 8.2 MySQL v. ??? on webgo, and whatever on Hostinger Apache - not sure how it runs there (webgo, Hostinger) InnoDB, utf8mb4 and a lot of MyISAM with utf8 and utf8mb4 ProcessWire from 3.0.165 to 3.0.241

No, no such e-mail. But i got an angry error message from TracyDebugger when going to the Adminer part of Tracy. So i looked up the module page on ProcessWire homepage and compared the version with mine and got a chock. Updated it at once and everything was smooth sailing.

Did your hoster send you a scary email about the old Adminer script containing known vulnerabilities? Cause that happened to me ?

That'a a core module. So it's in the /wire/ folder for a reason as it is part of ProcessWire itself. In this case you also don't download it, you just activate it. Nothing to worry here as well.

Ok, we have the same settings now. Besides mine is actually a Textarea (Multi-Language) field, but I don't think that's the issue here. I uploaded a short clip of how the field and/or frontend-editing now behave. It worked way better before. https://youtu.be/OOUKdEzH4Tc After all I maybe really just disable it again. As mentioned before I rarely use it and I have a quick link to the edit screen anyways.

It might be best to disable Frontend Editing on fields that are going to be handled with Markdown (or possibly any fields that have Textformatters that swap in/out content dynamically). I'm thinking that because Frontend Edit is not aware of the additional processing that a textformatter will do, it is only presenting and saving the data as it sees it based on the Fieldtype, and (in the case of textarea) Content type therein. @bernhard You have front-end editing in your Rockfrontend; does it use the core's frontend page editor, or did you use your own? I'm curious if you've run into any similar issues.

If you're intermingling this field with actual HTML on purpose, it would make sense that there are problems. As I mentioned earlier, Markdown should accept HTML, but due to how this all works together, I can see scenarios where there would be issues. I just manually typed in <strong>Test this</strong> into the Frontend Editable textarea for the body field, and saved. The text was bolded. OK. I went back to edit it and the text was still bolded, but there were no HTML tags for me to modify to un-bolden it. CTRL+B didn't work because that's a browser control to open my bookmarks. It would have to be modified in the backend, or I'd have to combine Markdown with a richtext editor (which I have not tested, and there are other modules for that, too). Therefore, any broken HTML would just be broken HTML. NOTE: I did not adjust any Input settings, so "Strip Tags" is not enabled. I don't believe HTMLPurifier is processing this input as it's currently configured, which is its own problem... See below (the "Edit this page" should not be bolded, it's hardcoded text, part of the page template, not part of the body field.)

I was curious, so setup a test environment. Blank profile. I created a `body` Textarea field and applied it to the `basic-page` template. I enabled the core's TextformatterMarkdownExtra module, and configured it as such: - Parsedown Extra - Safe mode: No (realistically this should be "yes", but setting it to yes caused HTML to be HTML encoded) For the body (Type: Textarea) field: - Text formatters: Markdown/Parsedown Extra (ONLY this; HTML Entity Encoder caused issues when combined with the Markdown formatter) - Inputfield type: Textarea - Content type: Markup/HTML - Markup/HTML (Content type) [options]: None selected, though this is only due to it being a test; these should be fine to adjust Choosing "Unknown/Text" for the Content Type while using Markdown seems to cause some issues when combined with Frontend Edit since the rendered text after being formatted is HTML, not text. I also had a strange scenario with Frontend Edit at one point where the text generated by Frontend Edit into the `body` field using contenteditable was "<div>Body text</div><div>More text</div>", but interestingly, ProcessWire only rendered "<div>Body text</dv>" into the HTML, though when I activated Frontend Edit to modify the field's value, the full text was displayed. I believe that may have to do with choosing "Unknown/Text" for the content type while using Frontend Edit due to how contenteditable works. That being said, once I configured things as it is configured above, I was unable to reproduce any extra newlines being produced in the final markup, no matter how many times I edited and saved.

Hi @bernhard! I noticed that the Scrollclass Feature has stopped working in RockFrontend (I am on version 3.19.0) https://www.baumrock.com/en/processwire/modules/rockfrontend/docs/javascript/ See line 258 of RockFrontend.js, the variable declaration for "j" is missing here: for (j = 0; j < attrs.length; j++) { This same goes for line 264: scrollpos = window.scrollY; Here is the updated snipped that will work: /** * Add/remove class on scroll position * * Usage: * <a href='#' rf-scrollclass='show@300'>Add class "show" at 300px scrollposition</a> * * Add multiple classes (thx @StefanThumann) * <a href='#' rf-scrollclass='show@300 show2@600'>Add class "show" at 300px scrollposition, "show2" at 600px</a> */ (function () { let scrollElements = document.querySelectorAll("[rf-scrollclass]"); for (let i = 0; i < scrollElements.length; i++) { let el = scrollElements[i]; let attrs = el.getAttribute("rf-scrollclass").split(" "); for (let j = 0; j < attrs.length; j++) { let parts = attrs[j].split("@"); if (parts.length != 2) return; let cls = parts[0]; let y = parts[1] * 1; window.addEventListener("scroll", function () { let scrollpos = window.scrollY; if (scrollpos >= y) el.classList.add(cls); else el.classList.remove(cls); }); } } })();

thank you @da² for the code optimization! but why it was not saving correctly was an issue with the context foreach ($page->children("include=hidden") as $child) { ... } in that case it must be $child->of(false); $child->sammelband_verweis = $matchingPage->id; //$newArray; $child->save('sammelband_verweis'); (instead of $page) ! problem solved (the only problem was kind of blind in front of the screen)

I'm not a PHP expert, I use this language since a few years but only intensively since last year. And I just found the spaceship operator <=>. A few days before I implemented an ArrayUtils::floatCompare() because I found bugs in my code where I compared floats like int, because usort callback function return value is an int and I was returning "$float1 - $float2"... followed by the implicit cast to int... not perfect sorting. ? I know I've already read about this 'spaceship.' I remember the name, but probably it wasn't the right time to fully understand its meaning. ^^ Did you know this operator? EDIT : thanks to the moderator who pinned this topic, I owe you a beer! ?

Until today I didn't know how burnt CPU cooling paste smells. ? I had enough fun for now with importing those datasets, time for the frontend shenanigans.

I am still not sure it this is a weird glitch or bug or maybe even expected behaviour. Until this very thread here I never really noticed any issues and didn't find any messed up articles so far, yet to be frank I rarely use that feature on a daily basis. I mostly enabled frontend-editing for some fields to clean up formatting, adding a sentence, fixing a typo, and similar tasks while browsing through the site. On the other hand I'm in the process of migrating some client projects over to Markdown textareas as those clients feel more comfortable using plain-text than HTML editors - and they just can't really f**k up things that bad in there. So it could become a concern when I enable frontend-editing there. It's not planned, but could be the case. @ryan , maybe you could give us more insights here? Is this expected behaviour or a weird glitch/bug?

It should be faster with transaction, and I did add startTransaction and commit in my import script. I'm still trying to figure out where the bottleneck is. Shouldn't be the hardware (i9-14900K, 64GB, high speed NVMe SSD), and I didn't see any io waits in the stats, so something is probably wrong with my db server (MySQL 8.4.0 on Windows 11). Looks like I've got do some forensics there.

... what was it? ?? No, everything is good! ? PS: I do get support forum e-mails, (as a forum moderator), whereas 99% of the blocked messages are real spam. But today I've read this in the mail subject: "Jan Romero has posted a post in a topic requiring approval", what lets me have used the posts url-link to look at it! ?

Mh, an investment company gobbling up open source projects. Yeah, that's never a good sign. I think we need an RTE that's governed by the OSI or something.

Hi @bernhard. I have now a 'close on save' feature as an option. * 'close-on-save' => 'no', // "no": no close-on-save, "": allow, but any error, warning or message will prevent close-on-save, // "messages": allow close if there are only messages, "errors warnings messages": always close regardless of notices // If "add" is included in the list, then the popup will close on save if it is a page add operation, otherwise it will remain open to edit There was already an option to reload/redirect the page on close: * 'redirect' => '.', // url to redirect to after closing the modal - default is to reload the current page (use redirect => '' to suppress). Use '#divid' to scroll to a specific div on current page All defaults can be changed in the module config.

I'm using a similar setup with markdown and frontend-edit. Copied your snippet, added demo content, wrote text... no new lines added here. I put some screenshots here to compare. If you want, drop me one of your .md files and I will test with that.

This week I've bumped the dev branch version to 3.0.241. Relative to the previous version, this one has 29 commits with a mixture of issue resolutions, new features and improvements, and other minor updates. A couple of PRs were also added today as well. This week I've also continued work on the FieldtypeCustom module that I mentioned last week. There were some questions about its storage model and whether you could query its properties from $pages->find() selectors (the answer is yes). Since the properties in a custom field are not fixed, and can change according to your own code and runtime logic, it doesn't map to a traditional DB table-and-column structure. That's not ideal when it comes to query-ability. But thankfully MySQL (5.7.8 and newer) supports a JSON column type and has the ability to match properties in JSON columns in a manner similar to how it can match them in traditional DB columns. Though the actual MySQL syntax to do it is a little cryptic, but thankfully we have ProcessWire selectors to make it simple. (It works the same as querying any other kind of field with subfields). MySQL can also support this with JSON encoded in a more traditional TEXT column with some reduced efficiency, though with the added benefit of supporting a FULLTEXT index. (Whereas the JSON column type does not support that type of index). For this reason, FieldtypeCustom supports both JSON and TEXT/MEDIUMTEXT/LONGTEXT column types. So you can choose whether you want to maximize the efficiency of column-level queries, or add the ability to perform text matching on all columns at once with a fulltext index. While I'm certain it's not as efficient as having separate columns in a table, I have been successfully using the same solution in the last few versions of FormBuilder (entries), and have found it works quite well. More soon. Thanks for reading and have a great weekend!

Just a thought for future in case performance really becomes an issue for someone: it's possible to add a generated + stored column to a MySQL table that feeds itself from a dedicated value in a JSON column, and this column can of course have a fulltext index. A hook on PageFinder::getQueryUnknownField could then "redirect" the query to the generated column. Would only work on single valued fields, of course. For anybody interested in creating such a generated field from a JSON field, here's a blog entry that explains it better than I could.

If you want to support the development of my PAGEGRID module you can find it now on Kickstarter. You can donate here. Thanks for your support!

Clickbait title aside, I recently found a cool new feature in PHP 8.1 and wanted to share it with you, in case you didn't know this either. Starting with PHP 8.1 you can write $this->method(...) (yes, that's the actual syntax, not a placeholder) to reference a method. I find this super convenient, especially for defining hooks. Plus the IDE can refactor this much better than the traditional [$this, 'method'] callback. <?php class MyModule { public function init() { $this->addHookAfter('ProcessPageView::finished', $this->doSomething(...)); } private function doSomething(HookEvent $event) { // TODO: something } }

The collaboration between dotnetic and Fugamo highlights the importance of a well-designed, efficient website for attracting and retaining customers. Fugamo, a provider of custom clothing for schools, clubs, and organizations, faced significant challenges with their old website. Slow load times, outdated design, and cumbersome content management were major issues that hindered customer engagement and conversions. The Challenge Fugamo's primary goal was to present their product offerings effectively, but their old website's sluggish performance and unattractive design made it difficult for potential customers to explore and make inquiries. Additionally, the absence of a wishlist feature complicated the user experience, leading to a lower conversion rate. The content management system (CMS) in place was inflexible, making it hard for Fugamo to update and create new content efficiently. The Solution Design Overhaul: We prioritized a visually appealing design to engage Fugamo's target audience — students, schools, and clubs. The new design incorporates vibrant colors, dynamic graphics, and interactive elements like an animated header. This not only enhances user experience but also strengthens Fugamo's brand identity and emotional connection with visitors, increasing the likelihood of customer loyalty. Centralized Content Management: A key improvement was the integration of a centralized interface, streamlining the management of both the website and the online shop. This ensures that new products can be added quickly and efficiently, keeping the website up-to-date without redundant manual updates across multiple platforms. Mobile Optimization: We implemented a responsive design ensuring the website performs well on all devices. This approach guarantees a seamless user experience regardless of the device used, addressing the needs of a mobile-savvy audience. Wishlist Feature: To enhance user interaction, a wishlist feature was introduced. This allows users to mark products of interest and include them in their inquiries through the contact form, simplifying the process and encouraging more customer engagement. Flexible Pagebuilder: We incorporated a flexible pagebuilder tool (RockPageBuilder), enabling Fugamo to easily create and update content. This tool simplifies the management process, allowing for quick adaptations and additions, crucial for maintaining an up-to-date and engaging website. Live Search Integration: A live search function was added, providing instant results as users type their queries. This feature significantly improves user experience by making navigation and product discovery faster and more intuitive, which can increase user satisfaction and the likelihood of conversions. Techniques and Technologies Used ProcessWire CMS: We utilized ProcessWire, our favorite CMS known for its flexibility and power. The existing e-commerce system is also based on ProcessWire, making it an ideal choice for seamless integration. Key Modules: Several ProcessWire modules were employed to enhance functionality: RockPageBuilder: For easy content creation and management. RockFrontend: Supports modern frontend development. RockMigrations: Facilitates field and template creation and data synchronization. FrontendForms: Simplifies form creation, management, and validation. SEOMaestro: Provides tools for creating sitemaps and managing Open Graph data. HTMX and AlpineJS: For drawers, navigation and live search PageimageSource: Optimizes image management and display. Latte Template Engine: Offers a powerful and secure template system. Outcomes and Impact The redesign and optimization efforts resulted in a significant improvement in website speed and user experience. Enhanced design elements and faster load times led to longer user sessions and reduced bounce rates. The introduction of the wishlist feature and improved content management increased the number of inquiries and conversions, helping Fugamo attract more schools, clubs, and students. Conclusion The Fugamo website revamp underscores the critical role of a modern, user-friendly website in business success. By addressing performance issues, implementing a captivating design, and enhancing content management, dotnetic helped Fugamo boost their online presence and customer engagement. This case study exemplifies the necessity of ongoing digital innovation to meet user needs and drive growth in the competitive online marketplace. For more details, visit the Fugamo Case Study (written in german).