ryan

Years ago when I was doing hosting research Wiredtree and Knownhost came up as having good reputations at webhostingtalk.com, which is where I've always gone to research these things. Good to hear these are still recommended by folks. That's where I originally found out about Servint too. All other things being equal, I think it's good to choose a host with a data center relatively close to you geographically (ping times can make a difference). Though overall history and stability are still the most important to me.

It is possible, and I've thought we'd eventually do this but it just hasn't come up before now. Fieldtypes can modify their own schema by keeping a schema version in their field settings. Both the comments, and files/images fieldtypes do this in 2.3 to support new features. So will take the same route with the integer type to support the things you've outlined. Should be able to visit this soon after wrapping up the new version. Btw, the way I've handled this in the past is to create the field in PW, then go into phpmyadmin to tweak the details. But I'd rather people be able to do this all in PW. Still if it's something you need today, it's generally safe to modify a field_* table schema to suit a specific need.

I don't think there's any intention of replacing the logo with PW, but we just need an alternate square logo for the situations when a long horizontal logo doesn't fit (like the wiki). I agree that a mark (something other than PW) that can go with the logotype, or go by itself, would be great. But a branding challenge too.

Looks nice! I look forward to trying this one out!

Awesome, thanks for your efforts here. I'm limited to mobile for a couple days, but look forward to checking it out!

I don't get any commissions from ServInt. But they do provide a dedicated server for the ProcessWire project, which we don't have to pay for. I think this is really awesome of them to support the ProcessWire project in this way. If you get an account with Servint it's good to mention ProcessWire, just as a way to say thanks, if you want to. But just wanted to mention that nobody is getting any commissions or payments. We all are getting a great server, because Servint likes ProcessWire and supports open source.

Netcarver, thank you for the kind words, that makes my day. Though I think you give me way too much credit. It's the community here and the people like yourself that make it great.

Welcome Kongondo, very glad to have you here!

Merry Christmas and Happy New Year from Atlanta!

Thanks u-nikos! I'm now away from the office for a couple of days, but I look forward to checking this out when I get back!

I'm not familiar enough with Laravel to be able to give a good example. But I'm guessing that if someone used a framework like Laravel with ProcessWire, they would make use of ProcessWire in a similar manner to how you would when using PW's API from a command line script or outside PHP file. You'd use PW for data and the framework for routing. That's just a guess though. Originally, the framework was just called ProcessWire and the CMS was called "ProcessWire CMS". But I've never given it much thought into formalizing the terminology, but like where you are going with it.

Like you probably saw, the upgrade is primarily just a matter of replacing your /wire/ directory with the new one. Let us know if the upgrade helped to solve the issue?

I like it too, a very good match for the current branding. But my eyes have been ruined because I see a cursive "u" (with a swash tail) every time I see that "w" by itself (outside of the word "wire"). "Pu" is what I see, and can't seem to unsee. That's specific to the Mahalia font, nothing to do with any particular implementation. If we could make the "w" a lowercase Avenir, getting across somewhat of an Element symbol type look, that might fit the bill. Ultimately though, if I'm the only one that sees "Pu" then I can accept that.

Thanks Matthew, these API improvements are one of the most fun parts for me. Though I think the next step will be to get comprehensive unit test library specific to PW selectors, so that I can go in and add or tweak stuff, and be able to make sure I'm not breaking anything.

In that case it would give you flat black for the overlapping area. But u-nikos added some code that keeps it in bounds, otherwise that thumbnail I posted would show black on the right side of it at least. The way I see it, percentages are useful for targeting an area when you don't necessarily know the dimensions of the image. Whereas specifying pixels is useful when you do know the dimensions of the original image.

The main reason I'm not that into Mahalia is because of the "w". When placed next to the "P" I always read it as "Pu" which at least in English is the term for "something stinks". So whatever face we end up using for the "W" probably has to be one that doesn't carry any resemblance to the "U". That's why I swapped the P and the W fonts on that earlier one, because the Avenir W is visually very far from a U. But the W is really the only reason I'm not a fan of Mahalia.

Repeating what Soma already said, but limit has to be > 1 in order for pagination to work. Will soon remove that limitation, but until then I suggest using a limit=2 and adjusting the math a little in the API calls to get the pagination working.

Thanks u-nikos, I have pushed these updates. Do you have any idea how we might get the regular pixel cropping working (the non-percentage one)? Here's an example of how I was thinking it should work, and how it actually works. Lets say I want a 120px square crop of the point indicated. I want 354px from the left and 87px from the top. So I use this API call: $img = $img->size(120, 120, "354,87"); But the crop that I end up with is this: What's happening is that it crops after the resize. And what we need is for it to crop without resize. I've fiddled with it quite a bit, moving the crop dimensions to the first imagecopyresampled call and such, but I'm far outside my area of expertise on this one. Probably need to move it to a whole new function in the class that just handles the crop, without resize. I will keep fiddling with it, but let me know if you have any thoughts or solutions here.

If you are going off one of my earlier posts in here, this was the reason for the new tmp_pass variable. No changes are made to the password unless the user is logged in and changes the password manually. The tmp_pass is a one-time code that expires as soon as you login (whether using the real pass or the tmp_pass). The tmp_pass code is only visible at the account owner's email. I've found this method works well for simple account authentication situations. Of course, it does assume the user's email is secure, as many "password reset" functions do. For high security situations, you don't want to trust that the user's email is secure.

Nice job Soma. I think you've done about as good as can be done with the type we're using. The truth is that we need a full rebranding pretty soon. The current branding was just quickly cobbled together by me a few years ago with little time or thought. And making logos has never been a specialty of mine. As the project has grown a lot since that time, we're nearing the point where we need a better presence with our logo... one that solves all the different scenarios at the beginning. Regarding typefaces, I love Avenir but have come to kind of dislike the Mahalia face. Though when it comes to rebranding the logo, we don't necessarily need to stick with any past typefaces.

Per @nik's request (from awhile ago), I've expanded support for the parent field selectors that you can use with $pages->find() and related functions. You can now pass those functions selectors like this: parent.name=about parent.name=about|contact parent.title*=Something parent.body*=Something|Something Else parent.title|parent.body*=Something|Something Else parent.template=basic-page parent.template|template=basic-page|fancy-page // and I think this is the one that @nik requested: parent.title|title*=Something Pretty much any combination of stuff can be used with the parent selector. Previously, you could only use id or path. As an added bonus, you can now also perform partial matches on a page name: name%=something name^=some name$=thing parent.name%=something parent.name|name%=something parent.name|parent.title|title%=something|something else These new features are available via the latest commit to the dev branch (upcoming 2.3).

Thanks, tested out and it works great! Very useful for sure--I like it! A few comments: Your init can hook "ProcessModule::execute" rather than "Process::execute". That would be a little more efficient. Having all the markup generated in javascript rather than your PHP (.module) file means that the text isn't translatable. Not an issue for me, but might be for some people that are using other languages. I'd suggest changing your <span class='notes'> to <p class='notes'>, just for consistency with the rest of PW. Looks good in your admin theme as-is, but in other admin themes the <span> runs up against the bottom border, whereas the <p> doesn't. Thanks for making this great module!

I think I'm finally caught up here after 6 days. This forum software doesn't always catch all the pending messages in the "view new content", so it's possible I'm still missing some. There's so much here I can't keep track of it all manually (though did try), so if you see anything that looks like I should have replied to it and didn't, please let me know.

This looks great! I can't to try it. Only problem is that it asks me for a login/password to download? Is this something we need to sign up for an account for, or is that an error?

I've not heard of that particular issue before. But 2.2.0 is now a fairly old version, so you may want to upgrade it to the current stable (2.2.9), just in case. Can you think of any changes that took place before it stopped working? What it sounds like to me is that PW does not fully see you as a superuser. The fact that you are getting that "you are logged in" message indicates it is detecting a lack of access to something and then sending you to the login page, and the login page is saying "you are already logged in". One thing you can try is to make sure you have the superuser role by adding it back from the API. Paste this bit of code into one of your template files and then view a page that uses it: $you = $users->get('your-user-name'); $you->of(false); $you->addRole('superuser'); $you->save(); Remember to remove it after executing it.