dragan

I don't know how @benbyf structured his site, i.e. neither the tutorial or the GitHub ReadMe mention any of that. Why don't you just ask him? Personally, I would also tend to use page reference fields to create categories. Together with URL-segments (and maybe altering the JS a bit for the AJAX stuff and history.js functionality) this would be my choice of how to set up such a site. Looking at that code block above, it seems like you just need to check if $child has children (check for one more level deeper), and do some if/else stuff...

How big is your navigation? If you've got a huge flyout nav with 4 levels, you should use soma's MarkupSimpleNavigation module or something similar. Maybe your site isn't multilang, but using the page-slug will not go so well if you ever decide to add another language to your site. Why not simply use <a href="<?=$pages->get(123)->url?>"><?=$pages->get(123)->title?></a> instead?

Perhaps a dashboard with all kinds of infos, links etc. would be useful, when you enter the PW-backend for the first time. Such a dashboard should of course be able to be de-activated, or easily modified. Or a dedicated help page instead (that you could also be free to modify, or be able to show or hide, depending on user-permissions/-roles).

Just visited cmscritic.com again after a while (I'm subscribed to their newsletter). Apparently, they switched again to Wordpress (everything points to that, when opening browser inspector and seeing their HTML, the usual wp-xxx folders and file naming). Does anybody know the reason why? @ryan Were they unhappy with PW in some sort? oops, I kinda double-posted - didn't see a similar post from just 15 minutes ago...

What's the big picture? Where are these JSON files coming from? Do you just build a frontend with externally fetched JSON data? Do you have to fetch / update JSON data on a regular basis? Or do you create this JSON yourself?

Chrome inspector gives me a 404 error for the xsl: Failed to load resource: the server responded with a status of 404 (Page Not Found) perhaps comment out that line in the .module file and see if it fixes the issue. I downloaded your xml file, removed and loaded it in Chrome - everything is viewable normally.

idk, but I would try to install it on a local Apache environment instead of nginx (AMPPS, Laragon XAMPP, MAMP... what have you) yes and no. Depending on your page/tpl/field settings, some configs may run faster in page-edit-mode than others (you know, stuff like load only when opening field via AJAX etc. - but that's not TTFB, but mainly the browser needing time to fetch and render all the stuff) - but not the overall speed of moving around in the backend. If some of your recent changes involved using / adding nested Matrix Repeaters A LOT, then this could be an issue.

you're on a roll

I can definitely supports ML (although, it depends a bit if you also take into regard backend-usage... labels, fields - perhaps if you install an "exotic" language pack, some labels etc. are maybe not translated. But you can edit those yourself like in the PW-backend). But as far as handling ML content - yes, it supports all that.

Why don't you just test it? It's the latter, really, unless I have missed something brand-new lately...

The number of hooks and PDO-queries seems rather high. Did you modify anything (add functionality, change template code...) since you've noticed a slowing down of your site? Did you turn off debug-mode on your live-site? It really should be. It could be a number of reasons. Perhaps some modules are autoloaded when not even necessary. Or the way you've built it is not optimized enough. As you probably know - with PW - you can do anything in so many different ways, but some ways of doing stuff is better when you're dealing with lots of content + users. Since a few versions, we have e.g. methods like findIds() or findMany() that can speed things up. Also, it's a good idea to check if there are new module updates available. Maybe some of them are quite old, and would benefit from an update, performance-wise. If you need a quick fix, I'd suggest getting the ProCache module. (Perhaps there's a "x days money-back guarantee" that Ryan offers - I'm not sure.

De-installed is not quite the same as physically removed. If you de-activate a PW module, it will still be on your server. But all DB-related stuff will be removed (not every module uses the DB). Hint: Most old modules not tagged with "PW3-compatible" can be easily enabled with adding PW3 namespaces at the very top of the php (.module) file: <?php namespace ProcessWire;

Would you mind telling us why? I'm kinda curious. And thanks again for the templates/site-profile. I'm always curious to see how other ppl build their sites "behind the scenes"

'pdfpath' => "/usr/bin/pdftotext", 'wordpath' => "/usr/bin/wvText", What is is this? Do I have to install some Unix tools as root? I'm on a shared host. Os should they refer to the files in the import folder? o_O

For some strange reason, after installing your module today, and I click on "settings" / configure, nothing happens. I cleared module cache, the rest of the site is running fine. PW 3.0.92, PHP 7 (or 7.1, not sure). Tracy Debugger says nothing, I also don't see any related things in error logs. Any idea?

Just a stab in the dark, but did you try using PW namespaces in every included file? <?php namespace ProcessWire;

maybe try template.title (or some such variation)?

Install this module and run Batch Create Users https://modules.processwire.com/modules/process-admin-actions/

Yeah, similar experiences here. We have used a theme called The-7 (iirc) for 4 WP-sites. The theme had half a dozen variations of everything: 5 different tab elements, 7 accordion types, x sliders/carousels etc. etc. To ensure style consistency, we had to write a manual so authors could remember which items to choose and how. But tbh, I can fully understand why some ppl like such stuff. To most people, more is more.

I just got a notice whenever I go to the module section: PW 3.0.85 Updated AOS half an hour ago. Cleared site/assets/cache Refreshed modules + did "clear compiled files" The notices (the appear twice) remain...

Which version are you running? If you go to Admin > Setup > Fields > yourDateField don't you see these options in the Details + Input Tabs? You can define date/time formats for each installed language.

Always.

If you gave us some more background infos about the "big picture", I'm sure we could come up with more ideas. e.g. Is it always the same CSV you want to parse/display? Does your client frequently upload CSVs (updates)? Are you doing this in just one particular place, or in dozens of other areas / pages? How big are those CSVs? There's a great module (Handsontable) by @bernhard that you could use. The client could copy+paste from Excel to PW, and with little code you could display that as an HTML-table. If it's data that don't need to be synced every day (with a cron job), you could do a one-time CSV-to-PW conversion (build a page that holds data/fields equivalent to the CSV data structure), and then let the client update this data inside PW. re: speed / performance / caching etc. If the server has to process a huge CSV every single time the page is requested, you could run into problems. So... depending on your needs we might suggest going this route or another, and avoid to have bottlenecks, and probably making the UX for your client better. re: Hanna Code https://modules.processwire.com/modules/process-hanna-code/

Well, there are many tutorials out there. Since I don't know which ones you already have read, I'll just urge you to read (or re-read) these basic overviews: http://processwire.com/about/what/ http://processwire.com/api/ The "holy trinity" (imho) in PW consists of: templates pages fields The API glues it all together. Once you realize how those things play together, it'll click. Now, and this is what most people might confuse: Pages inside the PW admin (page-tree) don't have to represent typical "web pages". Pages can be used for simply creating attributes for a select dropdown in a template, as a reference. They don't need to be published (publicly visible). Templates can store any number of fields - if you're just building "normal" websites, these would be called "page type". But you can also control permissions with templates (and much much more). The hierarchical page-tree seems simple at first (some folks might think "so what?"), but you can use the page/parent-children relations for all sorts of stuff, like categories. If you're building web apps / sites for an international audience, you'll be surprised how simple and thought-out the multilang handling is made inside PW. Lots of systems force you to create a JSON/XML file for strings that are not directly editable in your template (button/form/JS strings). With PW, everything is editable right inside the PW-admin. PW selectors are powerful. Everything is relational. You can query, fetch, cross-reference anything easily (fields, pages, sub.field.values etc.). You can build your own custom modules or dashboards, and don't even bother with a "classic front-end". People have built huge CRM systems or similar where everything is happening only in the so-called backend. For lots of people, the "click" comes when they realize how bloat-free PW is. It doesn't assume anything. It gives you lots of freedom, and people accustomed to frameworks with a steep learning curve, at first don't really see the benefit of it. Because most ppl tend to think "more complicated probably equals better". So, perhaps ask yourself what exactly do you plan to build. Ask questions here, and we'd be happy to point you in the right directions.

Welcome to PW Just very very quickly (it's past midnight now, and I should really get some sleep): If you add a new field to a template, you have to add code to output that field. Depending on direct or delayed output strategy (several echo() vs. $content .= concatenation and just outputting it once) - you need to simply add either $content .= $page->my_new_field or $page->my_new_field "move things around in the template": PW doesn't care about your field order you're using inside your templates. You have to define yourself what you want to do with it - that's the nice thing working with PW (one of a million).