ryan

This week it's a relatively focused blog post, largely in part to much focus going into the ProDrafts documentation today. Specifically, ProDrafts is now in pre-release! Here is today's post: https://processwire.com/blog/posts/prodrafts-now-available-in-pre-release/

If you've added "namespace ProcessWire" to the top of your template files, then you template files are now running in the ProcessWire namespace rather than the global one. AIOM runs in the global namespace, since it's not specifically made for PW3. Since AIOM uses static method calls to add files (if I recall correctly), you would just need to change those calls from "AIOM::something" to "\AIOM::something", with the leading backslash. That tells PHP to access something from the global namespace. By the way, you don't have to disable compilation for templates individually if you don't want to. If you don't want the template compiler at all, just set $config->templateCompile = false; in your /site/config.php and the template compiler will be completely turned off.

I can't think of any reason why the page name would come into play for the sorting. What I would take a look at though is where your PageTable items are stored (common parent for all, vs. children of page being edited). If using a common parent, look at the sort settings for that common parent on the Children tab, and make sure there isn't some predefined sort being applied. Likewise, look at the template used by that parent page and check the sort settings under the Family tab. If not using a common parent, then perform the same check as above, except for the page being edited (that page that contains the PageTable field). In your PageTable field settings, click the "Details" tab and review the "Sort fields" and make sure that it is blank. If it is blank already, go ahead and hit "save" anyway, just in case there's something caught in the field settings that needs to be refreshed.

That's exactly right, filtering the entire page tree at once, not just 1 level of children in a branch.

Thanks, glad you guys like it. I've lately worked on some projects here with a lot of pages deep in the site (and paginated no less), and the PageList bookmarks weren't cutting it. I found myself keeping two browser tabs open all the time so that I could keep my spot in the PageList. So I've been motivated to make this work better, but always got held up trying to figure out exactly how. Basically the goal has been to make the PageList behave as if it was an offcanvas panel that was always ready for you where you last left it. Back in PW 2.5 dev I was experimenting caches of the PageList, but the problem was that any changes in PageEdit could then make that cache stale, really limiting the utility of it. Last week I started messing with <link rel='prerender' href='...'> tags to the opened page list in order to keep a ready-to-use pre-rendered PageList that I could get to whenever clicking the "Pages" tab... it was quite cool, and instant, but also a real waste of background resources to be pre-rendering a PageList (and all the ajax requests) in the background while in the page editor. But just going through that process led to the current result, which uses JS cookies to remember the spot, and lets PageList perform a pre-render of what was previously split into multiple ajax requests. It's not as fast as using the link prerender tags but a lot more reliable and less wasteful of resources, so seemed like a good compromise. I had not seen that, wish I could say I had. But sounds like we're all on the same wavelength here! Great! Yeah it should run at the same speed regardless of quantity of children. I think one of the next improvements we'll want to look at is the ability to filter by text in the PageList. For instance, if you typed "something" in a text input, it would open all the branches directly to pages having the word "something" in their label. I think this has been brought up by others in the past too. The current search box in the masthead kind of does this already, but without any context of where those matches are, which is something the PageList could do. This could be handy in so many instances.

This week we've got a really nice improvement to ProcessWire's page tree, something that I believe everyone that uses the ProcessWire admin will appreciate. Also a big focus this week was on ProDrafts and wrapping that up so that we can release it and make it available to you. More on both here: https://processwire.com/blog/posts/processwire-3.0.8-brings-smarter-faster-page-tree/

This week we have another new ProcessWire 3.x version for you that includes several updates and optimizations. We’ve also greatly expanded upon the field rendering with template files, with lots of info covered in this post. https://processwire.com/blog/posts/processwire-3.0.7-expands-field-rendering-page-path-history-and-more/

This week we’ve got some great new optimized methods added to the $pages API variable, plus full link abstraction now built-in, new sub-selector upgrades, and more! http://processwire.com/blog/posts/processwire-3.0.6-brings-pages-upgrades-and-link-abstraction/

Maybe so, that's a good idea. I'll include that in the 2017 version. Though I figure everyone already can see that, whereas a site's Google Analytics isn't public to everyone. I knew the Beer Garden required one to be a member, but had missed that there was a minimum post limit. I suppose that makes sense. Maybe rather than linking to it, I should post a screenshot in there? @Mike Rockett is that okay with you if I put a sample of the design in the post? If so, which one do you want me to use? (or maybe I link to one on your site?)

This week we're going to look at our path for growth in 2016, which is already off to a nice start! This includes where we've been, where we're going, and how we will get there–with your help. We actually do have several core updates prepared too, but mostly smaller things that will fit better in next week's post. This post originally started as a section of our 2016 roadmap, but I decided it really deserved its own post, so saved it for this week so that we could cover it more in-depth. However, you might consider this part of, or a continuation of, our 2016 roadmap. But rather than looking internally, much of this post looks externally, outside of our software and community, and into the bigger picture of ProcessWire in the web development/design world. https://processwire.com/blog/posts/growing-processwire-in-2016/

I'm guessing that some new rewrite rule the SEO guys added caused it to start using those ?it= URLs, revealing them when it usually wouldn't. For instance, maybe they setup a rewrite rule that makes /index.php redirect to "/" without getting it quite right, thereby interfering with PW's own rewrite rules. I would suggest removing whatever rule they added that's causing the interference, and then putting your own alternative in a /site/ready.php or /site/templates/_init.php (if using one), like this: if(preg_match('/(index\.php|[?&]it=/!', $_SERVER['REQUEST_URI'])) { throw new Wire404Exception(); } Or if you just want to make it redirect to the homepage, replace the exception line with $session->redirect($config->urls->root); I will add something similar to the core ProcessPageView module to prevent that possibility too.

Thanks guys, I've committed a fix for that "column not found" issue and it should now be in the module. The issue was triggered primarily by the "field_comments_votes" field, when present, as it lacks a "pages_id" column and ProcessExportProfile wasn't taking that into account. Now it does. Please let me know if you see the issue occur anymore.

@dragan, I think this is the same issue that you were seeing with ProFields (per your topic there). I think PW is having trouble understanding your paths, potentially due to the spaces present in the path names and/or something to do with your Windows environment. I've not seen any other instances of this particular issue, but I'm going to be taking a closer look at the files you sent me and hopefully we can track it down. Hopefully we can resolve it with an adjustment to FileCompiler, but I've just not been able to identify what we need to adjust yet. @tpr It's funny you should mention that because the support is already built in. I didn't document it yet because I wasn't sure I was going to keep it there. But sounds like maybe we should keep it there. The format it uses is this: field.template.php example: body.basic-page.php Since this is already built in, you can try it out now if you'd like. It checks for a template-specific file before a general purpose one. It will use the template-specific one if present, or the general purpose one if not.

This week we've released ProcessWire version 3.0.5 which actually contains quite a lot of changes. Now you can nest repeater fields (repeaters in repeaters) and use dynamic/AJAX loading for all items. Plus we've got the first test version of Repeater Matrix released, and new support for field templates… https://processwire.com/blog/posts/more-repeaters-repeater-matrix-and-new-field-rendering/

I recently installed a client site at GoDaddy (I tried to talk them out of it, but had to work with what they had). It was one of those $5/month sites, not a VPS. I had to change the RewriteBase in the .htaccess file to "/", but otherwise found that it worked just fine. Granted it's not speedy, but everything runs acceptably for a low traffic site. With ProCache installed it's actually quite fast. Based on the things you've said, I would guess that there's a bottleneck somewhere, and that the GoDaddy server is just making that bottleneck more obvious. Speed should not be significantly affected by quantity of pages in the site, so it points to something, somewhere in the site that is loading a large amount of pages (most likely a hook or module). I would enable debug mode, and then view the Debug info in the bottom of the admin screen on one of the slow loading pages (though not Lister, since it ajax-loads its pages separately). Click on the "Pages" section to see what's being loaded. I'm guessing you might have something in there loading all 2000 pages. This might help to point to the source of the bottleneck.

It's like an enhanced repeater, but it doesn't actually use multiple templates. It uses just one, and pulls a few tricks behind the scenes to make it all work, while remaining perhaps more efficient than if it were using multiple templates. One other update I've been working on this morning for regular Repeaters, and now have functional (though have not pushed to GitHub) is making all repeater items ajax-driven, so they don't load until you click on them. This enables Repeaters to scale just as well as PageTable. It's a configurable option, but one that I think will be good to enable for folks that have lots and lots of repeater items... it should make a major different in editor performance.

Thanks guys glad you like what you see! Actually I haven't done anything in that respect, other than add the option to have them be collapsed by default (something that's been requested by a few people). But I agree just having that option makes quite a difference. It is using pages in exactly the same manner as regular Repeaters. Repeater Matrix actually extends Repeater, in the PHP class sense. So the core Repeater class handles all the page management for Repeater Matrix. This also enables you to convert a Repeater to a Repeater Matrix field (or back again) just by changing the field type.

This week is all about repeaters, something that we didn't cover on the roadmap last week–we always like to save a few surprises to keep things interesting. We've also got a preview of the new Repeater Matrix field coming soon to the ProFields package… Read the post here: https://processwire.com/blog/posts/processwire-3.0.4-repeaters-revisited-preview-of-profields-matrix/

Happy New Year! Here's the ProcessWire 2016 roadmap: https://processwire.com/blog/posts/happy-new-year-heres-a-roadmap-for-processwire-in-2016/

Okay if it works with 2.7.2 then it can be made to work with PW3. I installed it to take a closer look at what the issue was, and it came down to that PW3 doesn't support compiled admin themes at all. I'd forgotten that. I've updated PW3 to support compiled admin themes that live in /site/modules/, and that's now committed to the devns branch. Testing with AdminThemeModesta, it seems to work just fine. Though there's lots missing from AdminThemeModesta in terms of current feature support, so I'm not sure I'd recommend using it, but it should work now if you want it.

@mrkhan, Modesta only shows compatibility with PW versions up to 2.4, so I'm not sure there will be an easy solution to use it with PW3 or 2.7 for that matter. There have been significant changes to admin themes between the last few 2.x versions and to my knowledge only the themes included with the core are working for 2.7 and 3.0. Though if you do manage to get it working, you may want to submit a PR to the author of the Modesta theme. I think you are on the right track with adding "namespace ProcessWire;" to the top of all the PHP files. This is something that will be necessary for an admin theme to support PW3 (unlike other modules). I think the reason you are getting the "trying to get property of non object" error is because Modesta is an admin theme module, rather than an older style admin theme. That means it would need to live in /site/modules/AdminThemeModesta/ and not in /site/templates-admin/. I can see from the error message that you've got it in /site/templates-admin/ rather than in /site/modules/. An alternative is that you may want to consider creating a custom color theme for the Reno admin, as we know the Reno admin theme supports everything in the current 2.7/3.0, but we don't know if Modesta does, even if you can get it working.

Horst, I've not been able to duplicate this one here. The code I'm using to test: <pre><?php include("./index.php"); $test = $pages->get("/about/"); echo "$test->title - $test->sort - $test->modifiedStr\n"; $test->setAndSave('sort', $test->sort + 1, array('quiet' => true)); echo "$test->title - $test->sort - $test->modifiedStr\n"; Anything I'm missing with regard to reproducing it?

Hey guys, this upgrade now appears on PW 3.0 (devns) branch. If you are using the ~= operator in a search, like "title~=disability act" it now asks MySQL for the ft_min_word_len (per @LostKobrakai's suggestion above). If any word length falls under that threshold, it delegates that word to a separate REGEXP command in MySQL that matches whole words. This is actually an improvement over the code I mentioned earlier because the previous code that converts it to use a "%=" for short words could match things like "disability fact" or "react to this disability" etc. Whereas the new core addition will only match whole words in the same way that the MySQL index would, meaning the field would only match if it contained the exact words "disability" AND "act" somewhere in the field, and not some word that happens to contain the partial word "act". To take it further, it also now uses this technique to match stopwords that MySQL doesn't full-text index. Previously it would just exclude them from the search since the presence of a stop word would prevent a search from matching. Now you can perform searches that include those stop words and match them.

SiNNuT by "make it the default" I mean "make it the default when supported". When full-text isn't available for InnoDB, we couldn't use InnoDB for things like FieldtypeText/FieldtypeTextarea. I don't plan to drop MyISAM support, just default to InnoDB in the installer when we're identified that it can be fully supported in the environment. This could be a problem with migration, like when your dev server has the needed versions and your production server doesn't, so the installer will definitely need to call more attention to these considerations when providing the db engine selection at install time. Btw, we already do use InnoDB for some tables where we want to avoid table locking (like DB sessions).

This is actually one area that I think may be too broad in scope for a tuts plus tutorial. That's because PW doesn't generate markup nor does it have an official front-end forms API, so it would be much more of an HTML and PHP tutorial than a ProcessWire one. Keep in mind the guides there are to demonstrate the simplest possible cases. We use concatenation because it's really simple and easy (and what I prefer), but that doesn't mean it's a requirement of delayed output. You could just as easily use arrays, output buffering, wireTemplateFile(), wireIncludeFile(), etc. The point is to demonstrate delaying your output until the appendTemplateFile inclusion. That's what delayed output is. ProcessWire's API is a PHP API, so I find it a lot simpler to stay in that API rather than constantly jumping in and out of HTML. After all, it requires <?php ?> tags to jump in and out of PHP from HTML, but does not require anything but quotes or heredocs to use HTML within PHP. PHP alternative syntax is handy for large blocks of conditional HTML. But for most markup generation situations I don't recommend it unless you personally find it more readable. For many of us, the additional verbosity and constant jumping in/out of PHP & HTML make it difficult to read and follow, but this is purely a preference thing as I don't think it matters to the end result at all. When it comes to writing tutorials and/or documentation, I try to communicate the concepts in the simplest/shortest way possible so that focus remains on the concept and API calls that we are trying to teach. That doesn't mean you have to do the same, or that doing it differently means you aren't adhering to the concept. Whether you are using alternative syntax or not matters little to the concept. Though since you are in "direct output" when outside of a php tag, it does make your job a little harder for delayed output. But you can amend that by isolating your markup and rendering it with wireTemplateFile(). Fantastic! @benbyf and @isellsoap just let me know if there's anything I can do to assist. Thank you for writing tutorials for PW!