ryan

Thanks for reporting back. Glad to hear that was it and that everything is working now!

Probably WordPress. I'm guessing its default configuration has at least something to do with WP. There doesn't seem to be anything inherently wrong with Suhosin (rather, just how it's configured), and in fact it seems like it could be quite a useful security tool. But it would have to be configured for the software it's running with, otherwise seems like it's very likely going to interfere with that software.

Just found a Suhosin setting that will definitely interfere with PW files fields: Note that 64 as the default setting for "max length" of variable names in POST requests. This appears to be ON by default with this value in Suhosin. That's going to cause issues all over the place in PW. If you have a files field with a name more than 18 characters, or any files field in a repeater, then Suhosin is going to block any data in it. It looks to me like Suhosin's default settings will potentially interfere with most of PW's multi-value inputs, not to mention some of Suhosin's other default rules will interfere with other parts of PW (and I'm guessing almost any powerful CMS other than perhaps WordPress).

Just looking at all the things Suhosin gets involved with (https://suhosin.org/stories/configuration.html), it seems likely to me something with your files field(s) are generating a false positive with Suhosin. For instance, maybe it doesn't like something about the property name used by file descriptions or some combination of factors. It looks like there is a whole lot of stuff that can be configured with Suhosin that could cause all sorts of problems with different web applications. So after looking closer at Suhosin I stand by what I said earlier of this probably being the first thing to look at. If you are using Chrome, it's definitely not the browser. I think the majority of us here are using the latest Chrome as well. These permissions are usually considered to be far too open. It's certainly possible suhosin is having a problem with this. Though since you are on a dedicated VPS, maybe it doesn't matter much for your situation, but perhaps it does to Suhosin. Since you are using suphp, you can actually lock those permissions down quite far... the files likely don't even need to be readable outside of the user account. Whereas, your current permissions have them globally readable and writable to everyone (even if everyone is just you, since it's a dedicated environment, it's still likely to trip security-related things like Suhosin). If disabling Suhosin doesn't do it, see if you can just find any installation producing the issue reliably on a core Images field, and we can take a look at that.

@Ovi_S we run on a ServInt server here too, and actually so do all my clients… and pretty much every site I work with, for the last 10 years. I can't say I've ever observed the issue you've mentioned. So I doubt it's a ServInt issue, and instead must be related to something about the server configuration. For instance, none of the servers I use at ServInt have suhosin or suphp active. Now I doubt that suphp would be an issue, but suhosin–maybe. It would be worth trying to disable that at least temporarily if you can. Since the issue you've described seems a little random and no errors are involved, it has that sound of something interfering with the normal requests, which I think suhosin might do. Based on available info so far, I'm inclined to think this is the first thing that should be looked at. I'm sure you've tried this, but does using a different browser make any difference? If you look in your /site/config.php file, what settings are you using for $config->chmodFile and $config->chmodDir? Are you able to duplicate the issue on completely stock installation of PW 2.7.x or 3.0.x using one of the default profiles? (with no 3rd party modules installed). If so, I'm happy to take a look at it if you don't mind PM'ing me the PW admin login and FTP (or SSH) login to the installation. I would also need instructions on exactly what steps to take in order to reproduce the issue.

Since PW doesn't control your front end output, there are some things it can't update without doing a refresh. Though it should be able to dynamically update most text-based fields. For others, you can either let it do a refresh (which it should do automatically) or if you prefer, you can always provide hints to it. Though if you've got a heavily javascript-driven layout, refresh is always going to be reliable. If you've got a text field that you think it should be able to update dynamically, please post a copy of your entire HTML output of the page to the ProDrafts board (or PM to me), so that I can test with it here. Thanks. It's a ProDrafts setting, but affects both server-side and client-side.

For this week we've got a new version of ProcessWire 3.x, version 3.0.9. This version adds some useful UI enhancements in the admin that were originally envisioned by members of the ProcessWire community. ProcessWire 3.0.9 and also has a few other refactoring, bug fixes and tweaks. We've also got more info on the new version of ProDrafts released yesterday. https://processwire.com/blog/posts/processwire-3.0.9-adds-new-long-click-and-save-actions/

ProDrafts version 2 is now available for download in the ProDrafts board. This one includes the "Live Preview" capability shown in that video above. It also includes "View Both" capability, and several other improvements.

Hey guys, here's a video demonstrating the Live Preview feature of ProDrafts. This feature should be available to ProDrafts users this week. Please view the larger + HD version so that you can see it better.

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.