ryan

There's really not much to it, it's nice and simple. This article is a great intro to Composer: http://blog.fortrabbit.com/handle-your-dependencies-with-php-composer/

Once the multi-language page names module is stable and in production use. So will probably start developing the namespaces stuff in May. Namespaces are the primary aim, with PSR-0 being a natural extension of that. I plan to shoot for PSR-1 too if it looks like it'll benefit our audience. Also as a natural extension to these updates, I am interested in supporting Composer, and will do so if possible. I agree it's a great asset for PHP, though am less certain if it's as much of a draw for ProcessWire's primary audience. Throughout all of these 2.4 updates, I feel a lot of care will have to be taken to balance these updates with other improvements to the system. After all, our audience is primarily web designers and developers, and less purely PHP coders. I think a majority of our users doesn't actually care about namespaces, PSR standards and Composer, so I don't want to get too far off track, even if I personally have a strong desire for these things. But the driving aim of 2.4 is to help ProcessWire benefit from PHP 5.3+ as much as possible. This likely includes all of the things outlined. I've always been interested in this. PW started as just the content framework, and underneath it still is. I'd like to retain and reinforce those roots. But don't think I want to actively maintain PW as two projects until there is real need for it (just as a matter of resources). I'd like to make it easy for people to integrate components if they want to, and I think Composer is probably the way to do that. But don't currently see a need for any of our core components to come from another framework. Though I'm always open to the idea if there is a real benefit to our users. IoC is not a new concept. ProcessWire was written with an emphasis on best practices, patterns and concepts like this, everywhere beneficial to the project goals. The primary need for unit tests in PW has been with the selector engine, both DB and in-memory, and the consistency of the two. Luckily this is an active project, and it has already been hugely helpful and influential in ProcessWire 2.3 (thanks to Nik). In fact, I would probably consider the issues discovered and resulting solutions the most important upgrade to come with ProcessWire 2.3.

You probably already know this, but you can also specify a path to your own "contents.css" file. It's basically the same as in TinyMCE, where you would want to copy out the default copy and place it somewhere in your /site/ structure, and then modify it to suit your needs.

In addition to what Nik mentioned, I would see if you can narrow down where the bottleneck is. Add the following to the beginning of each function: $timer = Debug::timer(); And add the following to the end of each function: echo "<p>" . __FUNCTION__ . " with page $category->path executed in " . Debug::timer($timer) . " seconds.</p>"; That might help to narrow it down. But if these function calls really are generating navigation with 400+ items, I probably wouldn't expect it to be lightning fast. It would be a good candidate for using MarkupCache. To use MarkupCache, replace all your "echo string" lines in the function with "$out .= string", so that you are populating a variable with the output rather than echoing it. Ideally your functions return the output so that the caller can do the echo, but you could also just put your echo at the bottom of the function. Once you've done that, you can use MarkupCache by putting this at the top of your function: $seconds = 86400; // 1 day, or 3600=1 hour $cache = wire('modules')->get('MarkupCache'); $out = $cache->get("homeHeader($category)", $seconds); if($out) return $out; // or echo $out; // ...the rest of your function code... $cache->save($out); return $out; // or echo $out;

Actually it has support now, and it's there in 2.3. But it's considered "beta", so I don't recommend using it on production sites until I'm at least using it on a production site (which should be about a month from now). But I think it's perfectly fine to go ahead and work with it now for testing and/or development.

In this case, you'd probably have the reverse the logic of the addable() hook. You'd give them the template access. But your addable() and editable() hooks would take it away. That's one approach you could take anyway... But if the blank templates list was the only issue before, you might just want to edit that /wire/modules/Process/ProcessPageAdd/ProcessPageAdd.module file and prepend the getAllowedTemplates() function with 3 underscores, renaming it to: ___getAllowedTemplates(). Then it becomes hookable, and you can modify the value that it returns from your module. Currently in your case, it's returning nothing (since they have no edit access on the template). So you'd want to make your hook modify the return value to include the templates you want them to be able to select from. If you find this worthwhile, let me know and I will update the core to have that function hookable.

I think that some kind of aggregate fieldtype that encompasses others would be a fine way to go. I don't see it as something I would personally use all that often, but I can understand why others might find it useful–it's a worthwhile idea. From the implementation side, a single item repeater probably would be the quickest/simplest way to implement such a type of grouping. But there are some significant differences to the point where it may be better off as it's own fieldtype, perhaps that extends FieldtypeRepeater. Either that, or something new that just takes a similar approach. After all, an aggregate field wouldn't need but 1 "ready page", it wouldn't need a repeater parent page, and could be built around the Fieldtype class interface rather than the FieldtypeMulti interface. It would have less overhead than repeaters would in some areas. There are surely even more efficient ways it could be built, but the repeater-model approach would be the most likely way to make it something tangible in a shorter period. I'll keep marinating on it here.

Glad you figured it out. We give first choice to $config->uploadTmpDir (if set), but prefer to use PHP's 'upload_tmp_dir' setting since this will presumably be somewhere outside the web accessible structure. It sounds like in your case, the server did not have PHP's 'upload_tmp_dir' setting defined. Now we could have uploadTmpDir set to something like /site/assets/uploads/ by default. But that's under the htdocs structure (though we do block it in htaccess) and I think it's a little more secure to have the server tell us where these files should go… at least as a default.

Not sure I understand the question (if it's still a question?) but want to mention that MarkupAdminDataTable is just a markup generation helper, and you shouldn't feel confined to it. If you have some table generation needs that aren't being covered by it, there's no harm in generating your own table markup.

I'm not sure I understand all the code examples or what the structure is underneath well enough to say what's wrong. The logic here is difficult to follow. But I see a few things I would change with the code: This block of code has problems with the $thisCategory variable: // Grab the page name from the url $thisCategory = wire("page")->name; // If the category is not called "news" then output the category name as a selector for the find. if($thisCategory !="news") { $category = "article_category.name=" . $thisCategory; } // Get the news posts - limited to ten for later pagination $newsposts = wire("pages")->find("has_parent=$thisCategory, template=news, sort=-date_time, limit=10"); Note that the $category variable above never got used–was it supposed to go somewhere? I'm making the assumption that was supposed to become $thisCategory, but don't know for sure. Double check that your "has_parent" shouldn't really be a "parent" instead? I can't say without knowing the structure, but the use of has_parent seems unusual here to me. Also, I don't think there's any reason to have $thisCategory be the page name. You should just keep that as the page object instead. This becomes a problem in particular where you are using it in that last find() because find("has_parent=$thisCategory") is resolving to something like "has_parent=some-page-name", and that's invalid syntax because has_parent expects a page ID, object or path. So I would change it to this: // Grab the page name from the url $thisCategory = wire("page"); // If the category is not called "news" then output the category name as a selector for the find. if($thisCategory->name != "news") $selector = "article_category=$thisCategory"; else $selector = "has_parent=$thisCategory"; // or maybe: parent=$thisCategory ? // Get the news posts - limited to ten for later pagination $newsposts = wire("pages")->find("$selector, template=news, sort=-date_time, limit=10"); I would also recommend passing in $thisCategory as an argument to the archivesNewsList() function, rather than pulling it from wire('page'); just because pulling it from wire('page'); means that the archivesNewsList() function can only be used on category pages, and maybe you'll want to use it somewhere else? Next up is an observation or a question. But if this is valid PHP syntax, I didn't know it: $out .="<img class='align_left' src='{$newspost->article_newsimage->getThumb(listingthumb)}' Does that really work? If so, I guess I didn't realize you could make a function call like that from within a string. So if that really works, then I guess I've learned something new. But if it doesn't, I'd suggest changing it to this: $out .="<img class='align_left' src='" . $newspost->article_newsimage->getThumb("listingthumb") . "'>"; You really don't need to redefine all the markup for the pager unless you want to. This is unnecessary extra code since it's already outputting an unordered list with these same labels: $out .= $newsposts->renderPager(array( 'nextItemLabel' => "Next", 'previousItemLabel' => "Prev", 'listMarkup' => "<ul>{out}</ul>", 'itemMarkup' => "<li>{out}</li>", 'linkMarkup' => "<a href='{url}'>{out}</a>" )); You can just do this: $out .= $newsposts->renderPager(); Last thing to mention is that there's no point concatenating everything into an $out variable when you are just echoing it at the end of the function. The purpose of stuffing into a $out variable is so that the function can return the value, to be output by the caller (which is what I usually do). So I would suggest making your function return $out; rather than echo it, and making the function call: echo archivesNewsList($categoryPage). If you'd rather have the function echo it, then don't bother with $out, just echo the strings as you go.

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).