ryan

Thanks for posting. It looks to me like you shouldn't need to have a #pagebreak# at the top with your current code, given that you are subtracting 1 from $currentPage. Also, your "} else {" condition should probably "throw Wire404Exception()" rather than defaulting to $pageBreaks[0].

You don't really need any kind of multi-site support if you are just talking about subdirectories. If you want them to use the same database, then just make them all run from the same PW install. If you want them to run from separate databases, then just install PW in the root and the subdirectory… should you want to share the same core, then make /subdir/wire/ a symlink to /wire/. Though when I'm running more than one PW install on the same account, I usually just keep their cores separate so that I can upgrade and test them separately. But it's perfectly fine to run multiple PW installs on the same domain.

Do you receive this error when uploading files to other pages too? Do you receive this only if uploading a ZIP, or do you get it when uploading the language pack .json files individually? The error message most likely indicates that the directory where PW wants to store language files doesn't exist, and it's unable to create it. You could try creating the directory manually, but I think you will still have issues until you can determine what file system permission is blocking access. If you want to try creating the dir manually, edit your language pack and note the ID in the URL. Now create a dir based on that ID in /site/assets/files/. So if the ID is 1234 then you'd create the directory /site/assets/files/1234/ and make sure it's writable to PW.

For security, I'd avoid implementing solutions that would let anyone enable debug mode. So GET vars aren't ideal unless you can get enough "security by obscurity" with the GET variable (perhaps by name or value). My IP address doesn't change often, so I usually enable debug mode directly from my /site/config.php with a line like this: $config->debug = $_SERVER['REMOTE_ADDR'] === '123.123.123.123';

Most of these options are meant for ProcessWire (core) development, so they aren't meant to be documented as part of the settings you would typically use in site development. But for people that want to experiment with them, the inline documentation is pretty good. Of course, feel free to post questions here about any of the options too.

That's great about the ProcessWire presentation. I really enjoyed the slides. I can't get the video to play more than one frame at a time, and I don't know what's being said either (I don't have multi-language support installed). But it looks like it went on for a good long time. Anyone that speaks German have a summary of what was said / how it went? Also, who did it? Big thanks to the presenter for taking the time to do this.

The scope of the project you mention sounds pretty broad and will be a big investment on your part regardless of what system you build it in. I think part of your decision has to come from budget. If you are testing the waters rather than dedicating your full time to this project, then I would pursue whatever path has the most components already built, even if the result is not 100% what you want. I think that means looking into what's available and built through WordPress and IPS. I especially like the IPS option in your case. Maybe it's not perfect, but it does at least get you more than half way there and has the level of integration between components that you are looking for (including ecommerce). There's no doubt that you could build this all beautifully in ProcessWire, but I wouldn't recommend such a big project being your first in any CMS or framework. Whether ProcessWire or another platform, you'd want to have some significant experience developing apps/sites before pursuing such a big project in [x] platform. Unless you've set aside a large budget or don't have a full-time job already, find the tool that gets you closest to your needs before having to get into code. Then, once you've proven the concept or made it a success, develop it exactly the way you want it in ProcessWire or a full-blown framework. But stay with us here and start learning ProcessWire in smaller chunks and on smaller projects, and before long you'll be ready to build anything you can imagine.

In future versions of ProcessWire, including the current PW 2.3 dev branch, you can also do this: if(count($options['pageStack'])) { // don't include header/footer, etc. } $options['pageStack'] is an array of pages that called render(); before the current one. It basically gives a way for a page to discover the context it is being rendered in.

It's not necessary, as anytime you create something new the output formatting state is off. Of course, there's no harm in a $user->of(false); call either, but it's not technically necessary. Another way you can create a new user: $u = $users->add('ryan'); The password is actually one thing (and probably the only thing) that you really shouldn't sanitize, because you don't want to change the password they entered. What you should do instead is validate it, making sure that it's a string with some length and at least [n] characters (whatever your requirements are). By validate vs. sanitize, I mean don't sanitize (clean) what they entered, but give them an error and make them enter something new if it doesn't validate.

I'm not sure what's up but it looks like the caching from GitHub was failing, as I tried to reload it several times but no luck. That issue has turned up in the past too. I went ahead and made /api/cheatsheet/ a redirect to http://cheatsheet.processwire.com - major thanks to Soma for developing the Cheatsheet into a ProcessWire site. It's quite impressive the way he's got it setup with Fredi too. I'm going to start adding more new PW 2.3 functions to it today.

You can enable this option by editing your /site/config.php and setting $config->advanced=true; Next edit the template (Setup > Templates > edit) that you want to be able to change the createdUser. Click on the "system" tab (this is only visible in advanced mode). You'll see checkboxes for various options–check the appropriate one and save. Go back to your /site/config.php and remove the $config->advanced line you added earlier… as you don't usually want advanced mode on (some settings can be dangerous). But you should now have the ability to change the created user for pages using that template.

I've now got ProcessWire (local dev) fully converted to PDO and running with both PDO ($database) and mysqli ($db) available to the API. When in the admin, the debug mode info at the bottom highlights queries from each, so that you can more easily identify mysqli queries that you may want to convert to PDO. As a matter of efficiency, ProcessWire doesn't actually initiate the mysqli connection until you access something from the $db API variable. Meaning, the core and a stock install of PW doesn't use mysqli at all (or attempt a DB connection through it), but it makes it available if any modules or your site want it. In order to achieve this, I had to abstract the existing mysqli Database class behind a passthrough gatekeeper class. The only way you will notice that is if you are using any kind of type hinting for the old Database/mysqli class, OR if you are using procedural mysqli functions. I don't think I've seen any modules type hinting the old Database class or mysqli except for my own (like Form Builder). But I do think I've seen procedural use of mysqli at least once (I think it might have been in one of Teppo's modules?). Anyway, not sure if this matters to anyone, but just in case, here's the things to watch for with mysqli: // If you are type hinting mysql or Database like this… function example1(Database $db) { ... } // this function example2(mysqli $db) { ... } // or this // …then remove the type hinting: function example1($db) { ... } function example2($db) { ... } // if you are using mysqli procedurally with a $db param: $result = mysqli_query($db, "SELECT COUNT(*) FROM pages"); list($count) = mysqli_fetch_row($result); // use it without specifying $db param… $result = mysqli_query("SELECT COUNT(*) FROM pages"); list($count) = mysqli_fetch_row($result); // …or better yet, use the OO version: $result = $db->query("SELECT COUNT(*) FROM pages"); list($count) = $result->fetch_row(); Since PW 2.4 will be backwards compatible in terms of the database, lets not worry about switching our 3rd party modules over to PDO until 2.4 is actually out in a stable version, which is still months away.

The hook you'd want to use would probably be Page::viewable. However, hiding pages that a user can't edit just doesn't work in a tree hierarchy, because how then would a user get to the pages that they can edit? A better strategy would be to figure out exactly what you don't want the user to see in the admin tree, whether it is branch of a tree, a specific page, or all pages using a specific template. And take into account the fact that nothing under the page(s) will be editable since the user won't be able to navigate to them. public function init() { $this->addHookAfter('Page::viewable', $this, 'hookPageViewable'); } public function hookPageViewable(HookEvent $event) { if(!$event->return) return; // page already not viewable $page = $event->arguments(0); if($page->template == 'my-private-template') $event->return = false; }

Since the error is coming from Apache, I would bet that it's from an Apache module (mod_security?). The 401 authorization required is also interesting. PW doesn't care if it's running from web root or a subdir. But I would check your web root for an .htaccess file and see what's in there–it's possible there's something in there conflicting with/overriding ProcessWire's .htaccess.

I'm not really sure how this module could be tweaked for local videos, as it's built around oembed, so really more about web services than local hosting. I think that the best solution for local video hosting will depend largely on what player you want to use to display the videos.

It's correct that passwords can't be retained if you are developing a site in > 5.3.7 and migrating to a server running < 5.3.8. Best bet is to avoid any web server running an old version of PHP. But if you can't do that, then you'll want to reset your password at the live server after migrating the site to it. I usually paste this into my site/templates/admin.php, open the /processwire/ URL (to run it), and then remove it. $u = $users->get('ryan'); $u->of(false); $u->pass = 'mypass'; $u->save();

Thanks Soma. Those links will probably just keep changing (especially since they were going to line numbers), so I went ahead and unlinked them.

The ProcessPageClone module is not yet updated for use with the LanguageSupportPageNames module, but it will be by the time LanguageSupportPageNames gets out of development.

In film.php, try changing this: include('./includes/head.inc'); $commentsForm = $page->comments->renderForm(); To this (just reversing the order): $commentsForm = $page->comments->renderForm(); include('./includes/head.inc');

I think that you need to increase your memory size to PHP. Especially for anything that deals with images. I'm guessing you've got it set to 16m or 32m right now. And you probably want to bump it up to 128m or better yet 256m. You can set this in the php.ini via the memory_limit directive. On a ServInt server, I believe this is located in the file /usr/local/lib/php.ini. You'll have to restart Apache after making the change to php.ini.

This would not be scalable. A large quantity of abstracted links generated over a long period of time are not something that an uninstaller could remove in one request. That's one of the reasons why I'm not totally happy with abstracting links. LinkMonitor actually does go further than just abstracting links. It also locates broken links to images and such, and then logs them (and emails you, if you want). So it's a nice upgrade from PageLinkAbstractor, and also compatible with it. I'll have to get back to work on it.

Most likely there is an image in the system that isn't quite valid in format and so the resize failed. But it must be close to valid, because the previous checks apparently missed it. My guess is a corrupted image.

Are you sure it's not a ProcessField instance? That's what it is when I test here in that scenario. In either case, you are right that the test for ProcessPageView isn't right and needs to be changed. Currently it would only work on the front-end. I am changing it to this locally and will test before committing: if(wire('page')) wire('modules')->get('ProcessPageView')->finished();

That's the truth! I haven't had a chance to try things out in IE10, but will plan to do so soon. Thanks for reporting them. Anyone else able to reproduce these issues?

I suppose another way to accomplish this would be to just run ProcessWire from an SSD. Though wouldn't a servers bandwidth need to exceed the hard drive access time? I guess I figured bandwidth would be a bottleneck before the hard drive, but I don't claim to know much about server administration. Thanks for your interest in ProCache!