ryan

I'll get them committed here soon. But attached is a file that has them added: ImageSizer.php public function getFilename() { return $this->filename; } public function getExtension() { return $this->extension; } public function getImageType() { return $this->imageType; } public function getWidth() { return $this->image['width']; } public function getHeight() { return $this->image['height']; } public function isModified() { return $this->modified; } I love the video! well done.

Awesome site, well done! Great to see Apeisa's shopping cart module here too.

Does the user have a role that has "create" permission for the template needed there? Also check the template's family settings for both the parent page and child page you intend to create. If that still doesn't seem to be the problem, let me know and I can make the ProcessPageAdd::getAllowedTemplates(); function hookable.

Matthew, the main "gotcha" with adding files to newly created pages is that the page needs to exist in the DB before files can be added to it. So if you are creating a new page, you'll just want to have a $page->save(); somewhere before you add the file to it, and another $page->save(); sometime after you add the file to it.

You might want to check out the blog profile, which uses "next/prev" for comments pagination: http://processwire.com/blogtest/comments/ Also, the current version of ProcessWire does include the ability to paginate comments, though it's not particularly automated yet. See the FieldtypeComments::findComments function. While not the prettiest bit of API code, you can use it like this: $limit = 10; // comments to display per page $start = ($input->pageNum-1) * $limit; $selector = "page=$page, sort=-created, start=$start, limit=" . ($limit+1); // find the comments. replace "comments" with the name of your comments field $comments = FieldtypeComments::findComments("comments", $selector); // output the comments echo $comments->render(); // output the pagination links if($input->pageNum > 1) echo "<a href='./page" . ($input->pageNum-1) . "'>Back</a> "; if(count($comments) > $limit) echo "<a href='./page" . ($input->pageNum+1) . "'>Next</a>";

Double check that this isn't the result of cache. Go ahead and login at https://ssl-account.com/domain-name/processwire/. Now browse the site. Does it work? If so, check to see if you have any caches enabled and disable them. Also, double check that when you link to assets in your site, you are using a variables like $config->urls->root rather than "/"; and $config->urls->templates, rather than "/site/templates/"; etc.

Generally I don't add tags except when we need to link to something from the past. Since 2.3.0 is the current master, I didn't think it needed a tag yet. Though I was going to add it anyway once 2.3 is officially announced. 2.2.9.final was just to mark the spot where it was at before merging in the dev branch. I would have called it 2.2.10, except that I wanted 2.2.9 to be the last version number in the 2.2 version (since we'd used 2.2.10+ for dev branch). The 2.2.9 version that people have been installing is 2.2.9.final. For the most part you can ignore tags with ProcessWire, as we don't use them for anything other than making links to past things, when necessary. The passwords and hashes won't change until the user actually changes their password. Basically it leaves it alone until the password changes. If you have an existing site and you want to take advantage of the better security of blowfish hashes, you should ask users to change their password. For admin users, it gives you a notice that you should change your password when possible.

The blog profile is a self running site profile, so it's not something that you can take and install on an existing site. In your case, you'll probably want to install in a subdirectory and then modify it to look like your main site. Though keep in mind it's not particularly difficult to produce blog functionality on your own, so you might also just consider not using the blog profile and instead coding what you need into your main site.

I read the article about GPL v3, just to make sure I hadn't missed anything before. But it's not clear to me why we would want to use GPL v3? (at least doesn't seem like any changes that matter to ProcessWire).

In 2.3, there are also these two additions (so far, undocumented). Either one returns the number of visible children: $page->numChildren(true); $page->numVisibleChildren; I will be adding these to the API pages, along with all the other 2.3 additions very soon.

My own website is very out of date. Basically all my extra time now goes towards ProcessWire, and my own website gets no love. It's now a 6-year old site... ryancramer.com is now so old/bad that it probably reflects very poorly now. I need to do a redesign/redevelopment soon!

Thanks for the report. Where did you find this line? hash('blowfish','mystring',false); That line does not appear in ProcessWire (as far as I know). The PHP error you got is correct, because "blowfish" is not a valid hashtype for the hash() function. Blowfish hashes are generated by PHP's crypt() function. It should not be possible for ProcessWire to call the hash() function with "blowfish" because here is the code (shortened): if(!$hashType) { // (ancient backwards compatibility) $hash = md5($pass); } else if($hashType == 'blowfish') { if(!$this->supportsBlowfish()) { throw new WireException("This version of PHP is not compatible with the passwords."); } // our preferred method: blowfish $hash = crypt($pass, $salt); } else { // older style (sha1), when no blowfish support $hash = hash($hashType, $pass, false); } The mystery is how your hash() function was called with "blowfish", when it shouldn't be possible with the above if() statement. Let me know if I'm misunderstanding. Overall though, it sounds like your PHP is reporting that it does support blowfish, but then failing when we ask it to generate a blowfish hash. I'm wondering if there is some PHP bug related to this in 5.3.8. If so, I could have it detect when it's got the buggy PHP version and fall back to non-blowfish.

I think that's a pretty interesting and smart idea actually. But it doesn't sound very white hat… more like a trick for getting around a Google algorithm. Would you install this on your sites knowing that the purpose of it was to come up with random variations on keywords to boost pagerank for processwire.com? I'm not sure even I would install that module. We are in this for the long haul and want to stay far in the white hat area when it comes to SEO, which is what we have been doing. But I appreciate your mention of this and am pretty impressed by your idea, even if I'd question what hat it goes into. You also bring up a very good point. If someone can be totally white hat and still get penalized because of legitimate links back to them, then it probably makes sense to tweak and adjust the anchor text when it's in your power to do so, just to avoid too much redundancy. After all, we don't want to get penalized for following the rules. So maybe we adjust the links in the default site profile on occasion when other updates are being made. However, I'm not really sure over optimization would ever be a problem for us, because how many people stick with the default profile, as-is… probably not many. Not to mention, the links are there for people rather than search engines, so I prefer to just use the words that speak most clearly. But definitely something to think about down the road, should our site profiles start showing up all over the place.

It looks like this could probably go in any JS file or any output that can produce a <script> tag, or even the admin theme. So there are lots of places you could get it in there. But I think the best place would be in your /site/templates/admin.php because this file is not overwritten during upgrades. Add this before the code that's already in there: $config->scripts->add($config->urls->templates . 'scripts/date-localization.js'); Then add your code to the file in /site/templates/scripts/date-localization.js

That could be. It doesn't look like AdminBar is yet confirmed compatible with 2.3. There's a good chance there's a JS error occurring. 2.3 uses significantly newer versions of both jQuery and jQuery UI, so JS errors are the most obvious places to look (and usually the simplest issues to resolve). Are you seeing anything in your error console? (In Chrome: View > Developer > Javascript Console).

It sounds like these are all PageArrays? If the items in it are going to be of varying types, you could make the output loop check the type to determine how it's going to render it: foreach($items as $item) { if($item->template == 'product') { // render a product } else if($item->template == 'repeater-photos') { // render a photo from a repeater } else { // ...and so on } } Another approach would be to let the items render themselves via their template files. Your product.php and repeater-photos.php templates (for example) could just be coded to render nothing but the markup for their individual item. Then your loop would be essentially this: foreach($items as $item) { echo $item->render(); }

Yes, I think that a lot of modules currently in the core should be removed from the core. But we can't just remove modules from the core because that could break someone's site during an upgrade. So it has to be part of a longer plan that involves a custom-download packager (enabling one to download PW with user-chosen modules included), and tied to a major version where users would be expecting something more to an upgrade process. I actually think CKEditor's download packager is a pretty good example of what would work well for us. You can browse their plugin directory and click "add to cart" (or something like that) to add any given plugin to your CKEditor download. Then when you "checkout", you are downloading a CKEditor ZIP with all the plugins you wanted, ready-to-go.

At least in ProcessWire, the tree is far more scalable than a linear bucket system like in EE. If it helps to conceptualize, think of ProcessWire as having a tree of buckets. This is the natural way the web works. If a single-level linear bucket system suits your needs, then you can do this in ProcessWire. But there's a good chance you can do much better. So I would argue that your statement about buckets vs. trees is backwards. In terms of scalability, a tree will take you much farther. But it does require that each branch in that tree have the ability to function as an unlimited bucket. This is exactly what ProcessWire does. Also consider that websites have hierarchy by nature, need and design. That hierarchy is extremely useful and powerful, and should be embraced. Websites lacking hierarchy would be limited, for obvious reasons. When working with a linear bucket system, you are always mapping a hierarchal system to buckets. This has always struck me as completely unnecessary, complicated and unfortunate. This mapping and conversion is ultimately a side effect of having to reduce a powerful system of tree hierarchy (upon which the web is based) to a less powerful bucket system. But if the system embraces the natural hierarchy of the web, then no mapping or conversion is necessary. You are working with the tree either way. The question is whether the system is embracing and using it (like ProcessWire), or mapping it to a more limited system of linear buckets. I don't have enough experience with MODX to know what the "resource tree shortcoming is", but am guessing it's something to do with pagination that others have mentioned before? I know that MODX has a reputation for being quite scalable, so would guess that they just have a different approach to managing that scale. But once you have worked with trees, and really experienced the benefits, it's very difficult to go back to buckets, IMO. The words "tree" and "shortcoming" simply do not go together. As for keeping more than one CMS in your toolbox, I think that's always a good idea. It sounds like MODX and ProcessWire have common ground in terms of philosophy, and these two would be good to have in your toolbox. I don't think I would bother with keeping a bucket-based system in your toolbox, except for perhaps WordPress, which can be handy in the right situations (like one-off blogs when client has very limited budget). ProcessWire is pretty much infinitely scalable, within the boundaries of a server, SQL database and file system. As scale increases, you do have to practice care in how you use the API. ProcessWire gives you a lot of power, and will fill up your memory if you tell it to. So you have to use common sense when using the API at the large scale. For example, an API call like $page->children(); might be referring to a million pages. Do you really want to load and display links to a million pages at once? (probably not). Does the server have enough RAM to keep a million pages in memory at once? (not likely). So you accommodate scale by specifying limits and using pagination, like $page->children("limit=50"); This is something you don't necessarily have to consider at the smaller scale. But I think it's a good practice to design and develop every site as if it could grow infinitely. Do you need to learn PHP? Not any more than you would need to learn the {tags} from another system, like EE. The time investment and scope of what you'd have to learn would be about the same, maybe even less with ProcessWire. In fact, you can do almost anything in ProcessWire by simply learning how to use just two API variables: $page and $pages, and knowing what a PageArray is. There are a few bonuses you get from learning PHP vs. a tag system though: Whatever you learn about PHP is something you can take with you, beyond ProcessWire. The more you learn about PHP, the more you can do, both inside and outside ProcessWire. Meaning, the environment can grow with you, when and if you want it to. Whereas, at some point, you'll start hitting your head on the ceiling in a {tag} environment. ProcessWire's API is identical regardless of context. You can be in a template file, command line script, plugin/module, etc., and everything works the same. In a {tag} environment, if you want to grow and learn plugin/module development, you'll be starting from scratch. In ProcessWire, everything you learn applies throughout the system in any context. It's only a small step to go from building templates to building modules. In {tag} systems, it's a canyon. In fairness, while you don't need to know much about PHP to effectively use ProcessWire, you may indeed need to learn more PHP to accomplish some of the things you've set out to do: paid membership and access, member signup forms, etc. ProcessWire is a tool more than a turn-key solution for these particular needs. While they aren't difficult to accomplish, you might find yourself doing more on the code side than you would with a system that has turn-key solutions for membership sites. If your project budget/timeline doesn't give you the room to learn and build these things, you would want to investigate more ready-to-use solutions for these. But I think you would do well to make friends with and use ProcessWire either way.

I'm not sure that I totally understand the entirety of what you are doing, but it is relatively simple to copy page references from one page to another: $page1 = $pages->get('/some/page/'); // page we want to copy from $page2 = $pages->get('/some/other/page/'); // page we want to copy to // optional: remove any existing categories if there are any $page2->categories->removeAll(); foreach($page1->categories as $category) { $page2->add($category); } $page2->save();

When you've got your first release version ready (if it isn't already), please post to the modules directory too.

The timepicker is not actually part of jQuery UI. It was an add-on created by Trent Richardson, as jQuery UI's datepicker does not have a timepicker. There is a tab on localization for this timepicker available here. Does this help?

Yes, I merged it to master yesterday. I just don't think there's any reason for new users (especially) to be starting with 2.2.9 at this point. The dev branch is more stable than 2.2.9. Now we can go back to letting the dev branch be a dev branch. I'll send out a 2.3 announcement later this week. While there are always more issues to resolve, there haven't been any major problems since people started testing. Nearly all issues that have come up have been related to needing a modules cache clear, or needing to start with a fresh /wire/ dir–things that people should do for any ProcessWire upgrade. I have now added these items to the upgrade instructions in the new README file included with ProcessWire. People upgrading from 2.2 to 2.3 should still follow all upgrade instructions exactly, backup, use caution and test thoroughly. Here are the upgrade instructions as they appear in that readme file: Best Practices Before Upgrading Backup your database and backup all the files in your site. When possible, test the upgrade on a development/staging site before performing the upgrade on a live/production site. If you have 3rd party modules installed, confirm that they are compatible with the ProcessWire version you are upgrading to. If you cannot confirm compatibility, uninstall the 3rd party modules before upgrading, when possible. You can attempt to re-install them after upgrading. General Upgrade Process If you are upgrading from a version of ProcessWire earlier than 2.3, see the sections below for version-specific details before completing the general upgrade process. Upgrading from one version of ProcessWire to another is a matter of replacing these files from your old version with those from the new: /wire/ /index.php /.htaccess Replacing the above directory/files is typically the only thing you need to do in order to upgrade. But please see below for more specific details about each of these: Replacing the /wire/ directory When you replace the /wire/ directory, make sure that you remove or rename the old one first. If you just copy or FTP changed files into the existing /wire/ directory, you will end up with both old and new files, which will cause an error. Note that the /wire/ directory does not contain any files specific to your site, only to ProcessWire. All the files specific to your site are stored in /site/ and you would leave that directory alone during an upgrade. Replacing the /index.php file This file doesn't change often between minor versions. As a result, you don't need to replace this file unless it has changed. Replacing the .htaccess file Like the index.php file, this doesn't always change between minor upgrades, so the same applies. This file is initially named htaccess.txt in the ProcessWire source. You will want to remove your existing .htaccess file and rename the new htaccess.txt to .htaccess. Sometimes people have made changes to the .htaccess file. If this is the case for your site, remember to migrate those changes to the new .htaccess file. Upgrading from ProcessWire 2.2 Follow the general upgrade process above. You will want to replace your /index.php and .htaccess file as well. Clear your modules cache. To do this, remove all of these files: /site/assets/cache/Modules.* Login to ProcessWire admin. You may get an error on the first web request you try, but that should only happen once, so just reload the page. Upgrading from ProcessWire 2.1 First upgrade to ProcessWire 2.2. (side note: I'm not positive this is necessary, you may be able to go straight to 2.3, but I didn't have any 2.1 sites to test). Follow the instructions above to upgrade from ProcessWire 2.2. Upgrading from ProcessWire 2.0 Download ProcessWire 2.2 and follow the upgrade instructions in that version's README file to upgrade from 2.0 to 2.2. After successfully upgrading to 2.2, follow the general upgrade process above. Troubleshooting an Upgrade If your site is not working after performing an upgrade, clear your modules cache. You can do this by removing all of these files: /site/assets/cache/Modules.* If your site still doesn't work, remove the /wire/ directory completely. Then upload a fresh copy of the /wire/ directory. If your site still doesn't work, view the latest entries in your error log file to see if it clarifies anything. The error log can be found in: /site/assets/logs/errors.txt If your site still doesn't work, please post in the ProcessWire support forums.

What admin theme is that? Since that looks like incomplete output, if I saw that screenshot you are seeing, the first thing I would do is CTRL+A (select all) to see if any error messages were present. If there weren't any, then I'd either look at the error log (/site/assets/logs/errors.txt) or enable $config->debug=true; in /site/config.php. Then I'd try again. When you say you moved it from /blog/ to /, what specifically did you move (files/directories) and how did you move it? If I were to do that here, this is what I would move: cd htdocs mv ./blog/wire ./ mv ./blog/site ./ mv ./blog/index.php ./ mv ./blog/.htaccess ./

If you are running into the same issues every time you migrate (regardless of server), look into what tool is being used to transfer files. Make sure you are using something that retains file permissions and that does some QA to make sure the files actually made it. Personally, I've always used rsync and it's always worked quite well. If the server doesn't give me shell access, then I'll use SFTP/FTPS with YummyFTP (OS X). I'm not aware of anything like this. While you could use ProcessWire from the API without functional sessions, you couldn't login to it if sessions weren't working. And you couldn't do anything if the DB wasn't functional. If sessions aren't working, just double check that your /site/assets/sessions/ directory is writable.

Not as far as I know. But this is a better question for Soma. From what I understand, LanguageLocalizedURL works very differently. LanguageSupportPageNames and LanguageLocalizedURL modules are not equivalents in functionality. But I think there is still some crossover, so individuals would probably want to evaluate both to see which meets their particular needs better.