teppo

For Repeater use (or any complex data type) you'd have to mark an element as a parent and include the child structure within it. And since your items may not all be the same, you'll need if-else. And probably some way to check existence and length of an item as well. ... and just like that you've just invented a brand new templating language

Sounds like a bug – if you can reproduce this, please open an issue for it at https://github.com/processwire/processwire-issues/issues

Perhaps I'm missing the point, but this should be the easy part. Maybe something along these lines: <?php $current_date = null; $items = $pages->find('template=news-item, sort=date_field, start=0, limit=20'); if ($items->count()) { foreach ($items as $item) { $date = date('j.n.', $item->getUnformatted('date_field')); if ($date !== $current_date) { if ($current_date !== null) echo "</ul>"; echo "<h3>{$date}</h3><ul>"; $current_date = $date; } echo "<li>{$item->title}</li>"; } echo "<ul>"; } It's a bit crude and probably wouldn't work as-is with your infinite scroll approach, but that's the basic idea anyway

Right – WSL 2 is indeed an awesome concept. Kind of like having a real Linux box to work with (kidding ) When it comes to the terminal app, I guess it's just the fact that it's a desperately needed upgrade that makes folks happy. Good for them – and good for me I guess, if I ever have to touch a Windows machine again. Never say never, and so on and so forth

Serious question: were tabs, colors, and splittable windows the kicker here, or did I miss something important? That sounds... well, pretty basic, to be honest. No OS shaming intent here, just not sure if I've understood what this is all about. And, for the record, I'm a huge fan of VSCode – Microsoft has been building some really awesome products in recent years

That can definitely be a bit of a pain, and applies to any migration really The good thing about the way WordPress handles internal links is that they are all (assuming they've not been modified via hooks or plugins, and a plugin hasn't been producing loads of "non-standard" links) absolute URLs with predefined prefix for each custom post type, and as such – in a lot of cases – you can just run a string replace on the exported data. If you're working on a copy of the site, you can also use WP-CLI (if you have it installed) and run something like "wp search-replace 'https://OLD' 'https://NEW' --all-tables" before the export. Of course if you move things around a lot, it's not going to be quite as simple.

MarkupMenu is a markup module for generating menu trees. When provided a root page as a starting point, it generates a navigation tree (by default as a HTML "<ul>" element wrapped by a "<nav>" element) from that point onwards. If you've also provided it with current (active) page, the menu will be rendered accordingly, with current item highlighted and items rendered up to that item and its children (unless you disable the "collapsed" option, in which case the full page tree will be rendered instead). Modules directory: https://modules.processwire.com/modules/markup-menu/ GitHub repository: https://github.com/teppokoivula/MarkupMenu Usage As a markup module, MarkupMenu is intended for front-end use, but you can of course use it in a module as well. Typically you'll only need the render() method, which takes an array of options as its only argument: echo $modules->get('MarkupMenu')->render([ 'root_page' => $pages->get(1), 'current_page' => $page, ]); Note: if you omit root_page, site root page is used by default. If you omit current_page, the menu will be rendered, but current (active) page won't be highlighted etc. A slightly more complex example, based on what I'm using on one of my own sites to render a (single-level) top menu: echo $modules->get('MarkupMenu')->render([ 'current_page' => $page, 'templates' => [ 'nav' => '<nav class="{classes} menu--{menu_class_modifier}" aria-label="{aria_label}">%s</nav>', 'item_current' => '<a class="menu__item menu__item--current" href="{item.url}" tabindex="0" aria-label="Current page: {item.title}">{item.title}</a>', ], 'placeholders' => [ 'menu_class_modifier' => 'top', 'aria_label' => 'Main navigation', ], 'include' => [ 'root_page' => true, ], 'exclude' => [ 'level_greater_than' => 1, ], ]); Note: some things you see above may not be entirely sensible, such as the use of {menu_class_modifier} and {aria_label} placeholders. On the actual site the "nav" template is defined in site config, so I can define just these parts on a case-by-case basis while actual nav markup is maintained in one place. Please check out the README file for available render options. I'd very much prefer not to keep this list up to date in multiple places. Basically there are settings for defining "templates" for different parts of the menu (list, item, etc.), include array for defining rules for including in the menu and exclude array for the opposite effect, classes and placeholders arrays for overriding default classes and injecting custom placeholders, etc. MarkupMenu vs. MarkupSimpleNavigation TL;DR: this is another take on the same concept. There are many similarities, but also some differences – especially when it comes to the supported options and syntax. If you're currently using MarkupSimpleNavigation then there's probably no reason to switch over. I'd be surprised if anyone didn't draw lines between this module and Soma's awesome MarkupSimpleNavigation. Simply put, I've been using MSN (...) for a number of years, and it's been great – but there have been some smallish issues with it, particularly with the markup generation part, and it's also doing some things in a way that just doesn't work for me – the xtemplates thing being one of these. In many ways it's less about features, and more about style. In MarkupMenu I've tried to correct these little hiccups, modernise the default markup, and allow for more flexibility with placeholder variables and additional / different options. MarkupMenu was built for ProcessWire 3.0.112+ and PHP 7.1+, it's installable with Composer, and I have a few additional ideas (such as conditional placeholders) on my todo list. One smallish and rather specific difference is that MarkupMenu supports overriding default options via $config->MarkupMenu. I find myself redefining the default markup for every site, which until now meant that each site has a wrapper function for MarkupSimpleNavigation (to avoid code / config repetition), and this way I've been able to omit that Requirements ProcessWire >= 3.0.112 PHP >= 7.1.0 If you're working on an earlier version of ProcessWire or PHP, use MarkupSimpleNavigation instead.

I have no experience with this Tribe events thing, so can't speak for that, but for the bulk of the content I'd recommend skipping the database export idea and going with the built-in REST API. While the REST API has its quirks, going directly to database for exports is going to be a major pain in the a*s in comparison. Not entirely unlike exporting ProcessWire content with raw SQL... It would be best to have a separate copy of the site at hand first, but after that it's basically as simple as installing the ACF to REST API plugin (which adds ACF field data to the REST API results) – and of course making sure that the REST API is enabled in the first place. You should be able to query and export all your pages, articles, and any custom post types with this method. Once you have the data, importing it to ProcessWire is going to be a breeze. (Note: based on some quick googling the Tribe events plugin also provides REST API support. I haven't used this, but it looks promising.) Also, in case that idea won't pan out, you can always rely on existing solutions, such as WP All Export (which provides a GUI for exporting content, including ACF data). Admittedly I haven't worked with this plugin before, but it's the companion plugin for WP All Import, the de facto standard plugin solution for complex imports. WP All Import is a bit of a monster and can feel clunky (hence devs often prefer custom imports for long-running, often-used, scheduled stuff), but for one-off cases it's a really handy tool. -- Edit: in case anyone is wondering, the WP REST API was first announced on June 17th 2013, which would be a week or so after Ryan started this thread. It didn't make it's way into the core until 2015, and even then it was for a very long time considered "a work in progress". It's been more than five years since this thread was started, so it shouldn't come as a big surprise that some things have changed

ProcessWire uses session_id() internally as well (in SessionHandlerDB), so by all means use that. I've never had any reason to actually work with session ID's in ProcessWire or heard anyone else asking for this, so my guess is that it's not a very common need, and as such Ryan hasn't felt the need to include a custom getter method for it in the Session class

That's quite strange. Running this through decoder suggests that this include is trying to load file from /wire/modules/System/.db9f7664.ico. Is this a path that exists on your site, and if so, what's in that file? /wire/modules/System/ is a path where SystemUpdater and SystemNotifications live, but I'm not aware of anything that should create a file like that. Combined with files suddenly being removed and this file getting modified, it doesn't sound good. The first thing to do would be to check the server, i.e. is it possible that someone has gained illegitimate access to it. Is this a shared host, a VPS, or something else entirely? Were both sites on the same host? I'm not aware of any security issues with ProcessWire itself, but ProcessWire isn't immune to problems caused by someone gaining access to the server, directly or through another application (such as a WordPress installation – which has actually happened before).

At least to some degree related, no doubt! The reason I'm asking about ways to bundle dependencies into site profiles is that I was originally a bit conflicted about how to move forward with a project I'm currently working on. Based on the description in that thread there are definitely certain similarities with my project and what Jonathan is working on, but I'm not yet quite sure if there's any real common ground (except, perhaps, the target group) Either way it'd definitely be interesting to hear more about Jonathan's project – and perhaps share/borrow some ideas as well

Thanks Benjamin! What you're saying makes sense, and I've also come to terms with the fact that the contents of the site profile itself (mainly what's within the templates directory) won't be easily updated. They are, after all, intended to be modified, and as such "updating" them doesn't make a whole lot of sense. I do also agree that we're in a bit of a strange place right now: on one hand there are native (to ProcessWire) ways to handle things like dependencies, but on the other hand we've also got certain level of built-in support for Composer. That's not necessarily a bad thing, though: just for an example, folks have been doing stuff like installing modules from within the Admin for quite some time now, while I still haven't enabled that on any of the sites I've built – and won't, unless it's for a site that someone else is going to manage. First of all I prefer not to give the site easy write access to executable code (security), and second of all I've had some trouble making that work with my version control and deployment practices. (There are other reasons too, but those have always been my "top two".) The way I see it, the tools and practices I prefer are quite likely not what the "mainstream user" prefers – and I'm OK with that. Same goes for the dependency management: in my case I'm thinking that whatever solution is used should be reliable, easy (comparatively: running a few commands from command-line is easy), automatable, and compatible with different workflows (including things like CI/CD tools). The fact that ProcessWire caters for these tools just as it does for the built-in alternatives is a strength in my books. Anyway, I guess this once again boils down to the rather well established point that there's more than one way to do it -- Sidenote: to my best knowledge GitHub download feature actually doesn't include submodules, so the only way to have everything as an easily downloaded package is to bundle it all together. This is part of the reason why I don't (currently) think that submodules are worth the hassle.

Exactly. And just to clarify: $page->field_name returns a value stored in the field, not a field object, so that's why you can't check the type of the field that way

Thanks @horst and @Robin S for the input! Those are some valuable insights right there. I do have to agree that #1 would be beneficial for the widest possible audience. As you pointed out, Robin, this is likely still the best approach for most site profiles out there, simply because it's the only solution that works right out of the box. Anything else would require either the use of somewhat developer-oriented tools (such as Git or Composer) or a totally different approach (ProcessWire Kickstart) – and as such would be a potential turn-off for some users. This is just me thinking out loud, but if site profiles were able to provide a list of dependencies that ProcessWire could then satisfy (or tell the user to handle manually if it couldn't), that could be nice. Or perhaps ProcessWire should provide some sort of built-in support for "recipes"... Anyway, in my case the site profile I'm working on is going to be rather developer-oriented, so if Composer is enough to scare someone away – well, that's probably for the best. Basically what Horst said above: it depends on the target group, and in this case my target group are developers, so going with a set of tools that are anyway considered essential in the business isn't necessarily a bad thing. I could also go with Kickstarter, but since I'm trying to reach for the "serious developer" territory here, I think using industry-wide best practices is actually going to be a benefit in itself (And yes, I'm currently leaning towards Composer approach. Though please let me know if you have better ideas – I'm all ears!)

So, I've been working on a site profile and came across something I'd like to get some input on. Like probably many other site profiles out there, this one also depends on (and thus includes) third party modules. What I'm wondering is: what would be the best way to include them with the site profile? I can think of three possible / feasible approaches: Bundle the modules into the site profile as-is, i.e. include the full module directories. Benefits: just install the site profile and the module is instantly available. No other dependencies and doesn't require any knowledge beyond "how to install a site profile". Drawbacks: updating the module requires updating the files manually, or updating via Admin (which may not be permitted, and may not be a suitable option in case the whole site is stored in a version control system). Unless the site profile is manually updated from time to time, it may initially contain very old module versions when installed. Add module repositories as Git submodules. Benefits: modules are easy to install and update with Git, just run "git submodule init" followed by "git submodule update". Drawbacks: Git and some basic understanding of its command-line use is required, and simply installing the site profile itself isn't enough to get it up and running. Add modules as Composer dependencies. Benefits: same as with the submodule approach, but perhaps a bit more flexible – possible to define minimum versions, minimum stability, etc. Also: this would be familiar approach for many PHP devs, while something like Git submodules seem to be less commonly used. Drawbacks: obviously requires Composer and command-line access, plus a basic understanding of what Composer is and how it works. Module directories won't contain .git folder, so can't be updated with Git commands (not sure if this is a real drawback, though). What would you prefer, or which approach do you currently use? Any other ideas? I'm kind of leaning towards the Composer method, mainly because I'll likely have other Composer dependencies as well, so it would actually require fewer steps than including modules as Git submodules. Still the submodule approach does have certain benefits, like easier updates (sort of, at least) -- Note: since there's no separate forum section for site profiles, and technically this may apply to literal modules as well, I'm posting this the Module/Plugin Development area. If any of the moderators disagrees, I'm happy to move the thread to another area instead