Leaderboard

I oftentimes create a checkbox field called 'test' and assign it to certain templates. I check the box if the page is a test page. These pages may exist on the live site and I don't want to hide or unpublish them, but at the same time, I don't want them to appear in the XML Sitemap. (not part of this tutorial, but I also noindex,nofollow those pages using a meta tag in the head so search engines don't index them) In that case, you can remove them from the WireSitemapXML like this in /site/ready.php: $wire->addHookAfter('WireSitemapXML::allowPage', function(HookEvent $event) { $page = $event->arguments('page'); if($page->hasField('test') && $page->test) $event->return = false; });

@artfulrobot Comments are a kind of turn-key fieldtype focused just on comments (like you might use in a blog) or reviews, and their purpose is pretty specific and different from that of a page. So the point is more to be focused on solving a specific thing than to be flexible in the way that pages are. And actually, this is the purpose of most Fieldtypes. If what you are needing is the ability to build your own custom type then that's what pages, templates and fields are for, and maybe that's what you need, I'm not sure. But if you are needing specifically comments, then FieldtypeComments is also quite flexible for comment-specific needs. When it comes to custom data that you want to store along with the comment, there is the meta() method which you might find useful: https://processwire.com/api/ref/comment/meta/. This is what I use for storing photos and other Q&A with comments/reviews, like you see here: https://www.biketours.com/reviews/

I can confirm. I fixed it by adding if(typeof str == "undefined") return ""; at the top of parseValue() function in inputfields.js.

Short answer as I'm slumped on the couch. It seem you already read the structure documentation page and got the idea. About explaining the concept to the client, just use a real analogy. For example, think of a website as a book. In a book, you have chapters, sections, and pages. Similarly, a website is organized into sections, and each section contains individual pages that hold different pieces of content. In ProcessWire, a "page" is a container that holds all the data and content for a specific part of your website. It's not limited to what you see on the front-end as a traditional webpage. Instead, a page in ProcessWire can represent various types of content or data, such as blog posts, products, images, or contact forms. Once that said, and once you got the « Wow this is flexible! » then you can go further and say that using this tool (some of us call it a framework more than a simple CMS) allow you to build other types of applications than a website. I mean no frontend, no colors, no (web)Pages. You can find somes use case threads arround the forum. Ask for more. Just adding that once your clients become familiar with the page-based concept and the benefits of it, they will find it easier to manage their website content. Enjoy ?

art fulbot, usea that select-options field type.if you not want pages fer select opts. thats blog tut.very olden days, they are was not select-options type then {{ but I still like to uses pages most times }} for comment donut use pages 4 comments install ProcessCommentsManger module in Modules>Core>Process edit.comment field .. clicka Input tab .. choose "yes" for "use comment manger rather then in-page editor" for findning comment use comments find() methoda n.joy youwill or ask more love, $willy

We've been running pretty much the same jQuery and jQuery UI versions for the last 10 years or more. I haven't really seen much urgency to upgrade because the versions we have work quite well, and I wasn't so enthusiastic about the amount of work and potential headaches the upgrade might entail. Over time there have been been a few security issues found in the jQuery library, which I've always kept an eye on, but they weren't ever things that affected our usage or caused any concern here. The biggest hangup I had was just that upgrading meant also updating a lot of code that uses jQuery, since many of the changes to the library are not compatible with code written for earlier versions. (Newer versions of jQuery have a slightly less convenient API than earlier versions). I place more value on stability than on having new versions of things. But it's always been in the back of my mind that sooner or later it would be nice to get these libraries upgraded for many reasons. After all, newer means better and faster right? Well, not always, but that's been the theme in jQuery at least, that newer versions of the library have some performance benefits over older versions. For awhile now, ProcessWire has been using newer jQuery version only when $config->debug = 'dev'; and I've been testing that out for quite awhile (maybe a year?). This week we upgraded our "main" core jQuery version from 1.8.3 to the last available 1.x release 1.12.4 (4 years newer), which is the one I've been testing. We also upgraded our "dev" jQuery version from 1.12.4 to 3.6.4, which is the newest available version, released by jQuery last month (March 8, 2023). In addition, our jQuery UI "dev" version is now updated to the newest available version, 1.13.2. After awhile, these "dev" versions will become our main versions, but likely not before the next main/master version. While the core seemed to work fine as-is with the newer jQuery (1.12.4), the newest versions of jQuery (3.6.4) and jQuery UI (1.13.2) required quite a few JS file updates to support, and that's primarily what you'll see in the commit log this week. If you'd like to test the newest versions of these libraries in the ProcessWire admin (in a dev environment), edit your /site/config.php file and set: $config->debug = 'dev'; When you do that, it will also load the jQuery migrate library with logging ON. Meaning, the Javascript console will contain messages about things that need to be updated. There's still work to do in the core here, so if you enable 'dev' mode then chances are you'll see some messages about things in the admin too. The "dev" debug mode also makes it use the newest jQuery UI library. Keep an eye out for any visual glitches or any UI things that don't work. For instance, I found that when using the newest jQuery UI version, the image resize/crop tool wasn't working quite right, though I hope to have that figured out soon. Chances are there may be other examples like that, if using the 'dev' debug mode, so please let me know if you come across any. If you are a module author, your module uses jQuery and you want to make sure it's working well with the new main core version (1.12.4) you can also enable jQuery migrate verbose messages in your javascript console by setting the following two in your /site/config.php: $config->debug = true; $config->advanced = true; I've found that updating code for jQuery 3.6.4 seems to be backwards compatible with 1.12.4, so maybe just using the $config->debug = 'dev'; option is a good bet when testing, but I wanted to mention both options are available. I'll be continuing to update our core .js files for 3.6.4 and jQuery UI 1.13.2, and next week will likely update some of our 3rd party jQuery libraries such as the TableSorter library and others. Also, I've not forgotten about pulling InputfieldTinyMCE into the core, that'll likely be in the next version 3.0.216. Thanks for reading and have a great weekend!

Thanks, I pushed the fix from matjazp

Go to Modules -> Configure -> AdminThemeUiKit. There will be a section called “Masthead + navigation” which you can click to open. Then under “User navigation label format”, where it currently says “{Name}”, enter “{title}” instead. Or any other valid template string you like, obviously. The field pretty much tells you what to do. Of course this only works if your user template has fields for the things you want to display. As you will notice, other admin themes have their own settings, so if you allow users to change themes, you’ll probably want to make equivalent changes to all of them. However, AdminThemeReno doesn’t use the same template string system and AdminThemeDefault has no setting for this at all.

I still use jquery a lot and started to use alpinejs. Tailwind also has js part that could be run with vite. My best wish was to have vite as a standalone executable so it could be run on a prod. Not sure if it is even possible.

@ryan - another issue which looks like it's just core related - I can no longer view field settings (eg Setup > Fields > body) because of this error: inputfields.js?v=33g:1049 Uncaught TypeError: Cannot read properties of undefined (reading 'toString') at parseValue (inputfields.js?v=33g:1049:13) at inputfieldChange (inputfields.js?v=33g:1370:15) at setupDependencyField (inputfields.js?v=33g:1606:3) at HTMLLIElement.<anonymous> (inputfields.js?v=33g:1614:4) at Function.each (JqueryCore.js?v=1.12.4:1:4048) at a.fn.init.each (JqueryCore.js?v=1.12.4:1:1235) at HTMLFormElement.<anonymous> (inputfields.js?v=33g:1613:70) at Function.each (JqueryCore.js?v=1.12.4:1:4048) at a.fn.init.each (JqueryCore.js?v=1.12.4:1:1235) at InputfieldDependencies (inputfields.js?v=33g:1612:10) Please let me know if you can't reproduce and I'll try to provide more info, but so far it's happening on all sites I've upgraded.

Ok... so to give you a small update on this and the reason why I thougt about this feature in first place. In my case, this time, the "client"* really needed to be sure that all enabled/installed modules are somewhat/somehow Core/Ryan modules. It's not about Ryan himself, more of... 3rd party-issues. My "client"* needs a solution for a closed environment. All software, even for websites - or in this case - something similar to an intranet, needs to be audited. A website setup will be worked out in the future (hopefully), so every partner/affiliate should be able to clone a repo from Github (based on a master repo with all modules, settings, defaults audited ... - a site profile, ready to use, to be clear here). They trust ProcessWire and believe in Ryan and therefore only wanted to go with his modules in first place, while 3rd party modules are fine BUT... they needed to know about those prior to install them ANYWHERE, or when in testing-stage needed to know if those are "3rd Party" to get them into an audit. As of now we are already a step further and the "client"* looked up more and more, maybe already most of the modules we could need, already by his own DEV team. To make it clear. They looked for things in the modules like base64-encodings, external resources, external scripts, hidden Google Analytics (and similar) calls, and what-not. Their DEV team is awesome... yes, they digged through a lot and were happy so far - even 3rd Party/community modules. There were some issues they fixed already in some modules - can't say which, as I really don't know. But I got an "OK! Let's go." this week. ? * THE CLIENT: The client - is a new company of an old friend of mine - I worked with for 10+ years and they have to audit any software they use for their clients. They used Dr***l, Ty**3, and some custom solutions in the last few years and weren't that happy. A dummy/MVP-setup of mine brought them to ProcessWire with "huge success" (their words). But to be able to release it to more real clients of them, they need to be able to assure some things... which brings us back to my initial thought and question we are working on right now. To make it even more transparent: it's within the financial/automobile/insurace niche - so they are super strict with their contractors and partners (my client/friend). TL;DR: ProcessWire in a niche-software-solution, ready to be cloned from Github but with audited modules without any [shady-ish] scripts or whatever.

tl;dr - see below As @flydev pointed out... a page is more than just only a page. The confusion is real. Totally real for... at least me back in the days when I started using ProcessWire, coming from b2cafelog (nowadays WordPress), Drupal, Nucleus, Textpattern and many more "solutions". Yet... I never ever tried to explain a client what a "page" is in ProcessWire. For my clients a page is the last point/instance, in terms of hierarchy in delivering output, aka a real page. I never tried (after the first 10 clients or so) to explain the steps in-between. Even most designers and developers (outside of PW) get this part - and I don't even try to explain it most of the time anymore. For reasons. While everything is a page... you might want to explain it to your client in different terms. I most often use terms like unit, container, wrapper, entity, part of, fracture... or else depending on whatever I talk about. While I use a page as reference in a recipe, it's still an "ingredient, I can reference" for a client. Makes life easier. This "page concept" is NOT about communicating it to the client (for me!), it's for understanding the concept. When you get this... PW is not only your friend, but your best friend, wingman, best man, godfather of... you get the idea. These are/could be all the same - depending on the context and your setup. $page->title $ingredient->title $city->title $user->title Even though one is a page (endpoint) and all others are a page reference, comment, repeater... whatever. You seem to be very new to PW and came from Drupal, which is totally fine, and therefore you might JUST need to explore more parts of how the API and page handling works. This is not a newbie tip at all! It's what I did and I enjoyed it! You worked with Drupal so... you know more complex setups and concepts - I guess. I came from super limited CMS (see above) back then and learned a lot about PHP and whatever you could achieve with ProcessWire. For me it was freedom to do whatever I wanted to do. Till today. tl;dr/Conclusion: Think about 'page' as a concept and not a page. Or... let us know. We are here to assist and help to find a way.

bern hard, https://processwire.com/api/ref/page/meta/ $bern_hards_datas = $page->meta()->getArray(); love $willy

No plans to implement this for now. If there are multiple requests I will consider it.