ryan

Well if you are working in a text editor from the 1960s, then it's a little more tricky. But I found out how to get VIM in UTF-8 mode... just wish it knew how to auto detect it. I don't want to change the encoding on all the core files, but should be okay in specific instances like this install.php. Also sounds like I should change the default profile template files to UTF-8 encoding. Didn't realize they were showing up as ANSI for others--can't say as though I've ever seen that encoding in PW's files. For me they show up as either ASCII or Mac OS Roman with unix linefeeds, though I've always kept the character usage to pure ASCII except in specific instances (like InputfieldPageName.module).

I'm thinking we'd add the same thing to both parents() and parent(), except that parents() would return all matching, while parent() would return the first (closest) one. That way you always know you'll get a PageArray() from parents() and a Page from parent(). I'm not too concerned about maintaining consistency with jQuery, as their context is still very different from ours… different enough that strict adhesion to their API syntax would ultimately be confusing if taken too far in our context. ProcessWire takes inspiration from jQuery where it makes sense, but cloning their API is not the goal. Rather, we want to provide the clearest API for ProcessWire within our context, regardless of what jQuery is doing. The environments they operate in are very different. In terms of how you work with it, ProcessWire probably has more in common with YUI3 than jQuery, given the more specific single vs. multiple types in YUI3. But I still prefer jQuery as our syntax starting point, rather than ending point.

I could maintain a default translation pack on GitHub, which already has all the files in it (empty, ready for edits). That way, someone could just upload that to start a new language translation, or easily see what's been added (or more rarely, moved or deleted) via the commit history. This would only be necessary for the files themselves, as the LanguageSupport modules are already telling you of changes to the translations. But I'll be happy to maintain this if you guys would find it useful. This is a rare occurrence in the core. In this particular instance, we needed to add a CSS file to InputfieldRadios. That module wasn't in it's own directory before, so it had to be moved into one. The translation file would probably have to be renamed to reflect the updated location. While abandoned translation files should be rare in the core, a detection for it may still be worthwhile, especially for 3rd party modules since you wouldn't need to keep around translation files for a module that was no longer installed. There have only been two translatable files in the core moved in the last year that I can think of: InputfieldPage.module and InputfieldRadios.module. Again, this should be a rare occurrence. But another good reason for me to keep a master translation on GitHub, so there is a place where a translator could more easily keep track of it. This one may be easy for us to accomplish if we just say that a translation with nothing but a period "." in it might be considered intentionally empty, or something like that. Then I can add a bit of code to detect it and have the parser fall back to the default text when it sees that. The core on the master branch is always kept in a stable state, though individual modules may be kept in an alpha/beta stage. When the core is not in a stable state, I keep it in a separate dev branch (still on GitHub). Someday we may tie all updates to big versions, but for now, when something is ready to use or something is fixed, I like to make it available for people as soon as possible. There shouldn't be any side effects. If any text in a translation changes, then it's considered abandoned, regardless of what version. If the text stays the same, then it's considered still good, regardless of version. The translations are tied to a hash of the default version as it appears in the PHP source files, so there's no potential of the wrong information to ever be sent via the translation. Version mismatches between the original and translation are technically impossible. Upgrades shouldn't touch your translations. This is one of the reasons why translations are kept as part of your /site/ structure rather than your /wire/ structure.

Thanks for adding that Diogo. The wikipedia link at the bottom is broken: Processwire vs. ProcessWire -- I guess case matters for Wikipedia. I tried to fix it, but it's the one thing that apparently isn't editable, at least I couldn't find a way to fix it?

I've just made that function public, so should appear in the source shortly. But I'm thinking Soma's jQuery solution seems like a pretty great one.

This is definitely still on the to-do list. Schedule's been tough here lately (been out of town on the weekends), but should be able to give this a closer look hopefully this week.

You could keep a separate install directory like /src/, with a blank/uninstalled copy of ProcessWire. And then have your live /wire/ a symlink to /src/wire/. The /index.php and /.htaccess change very rarely, so those I would just replace manually when called for. You don't want an uninstalled copy of PW to be web accessible to anyone but you. To keep people out of the /src/ directory, you might rename it to be /.src/ (PW blocks access to any dirs beginning with a period) or place it somewhere else, non web accessible.

In the blog profile, I tried adding a new post under /posts/, and the family there is configured to limit it to that template (posts template only allows children of post, and post only allows parent of posts). But can't seem to duplicate this. I'm wondering if the scenario you had was a little different or maybe involved user access or something else? Either way, I'm thinking I can setup the Inputfields to not generate an error for any required fields that have a disabled attribute set, but just wanted to make sure I had a repeatable test case so that I could confirm when it is fixed.

There isn't yet a dedicated multi-language image field, like there are multi-language text fields. So you'd probably want to use a repeater for multi-language captions with images, like you mentioned.

I have to admit, I kind of liked the buttons appearing when I rolled over each image field. Assuming there is repetition (i.e. lots of images), I think it's better than having them visible for all images at once (whether the buttons or small icons, etc). That would be a lot more furniture on the page, when it's something you'd only use for 1 image at a time. So this may be more subjective than bad UI vs. good UI. When reasonable, I often prefer things to show themselves when they are in context or focus and stay out of the way when they are not. But it's good to read the different preferences here, because it seems like we would all agree on the value of an actions menu. Are you guys thinking just a right-aligned select box in each image, like this? There was also this setup in ProcessWire 1.x: Last, there was also this setup in Dictator (PW from 10 years ago) where you would select one or more images and then choose an action from the menu:

Nico, guest should already have access to it. That's actually the reason for this module: to bring what was previously an admin-only available service to the front-end/public side. View your /service-pages/ page when you are not logged in, and you should be able to test it as a guest. Let me know if you are unable to access it as guest?

@Lars282 Soma and Slkwrm have it right. Keep in mind that saveReady is called after it's been confirmed the save() will definitely occur, and right before the save actually occurs. So this is the ideal hook for you to use in your case. This is correct. We don't yet have a property $page->statusPrevious property like we do for parent or template. So there's no way for you to know what the previous status was short of loading another copy of the page, or just querying the database like in the example. But now you've got me thinking I may need to add a statusPrevious property in a future version. For your hook attachment code, I would suggest this: public function ready() { $this->pages->addHook('saveReady', $this, 'sendMailOnPublish'); } …basically the same as what Soma suggested, except that I would add it to $this->pages directly since there is only ever 1 instance of $pages, making it slightly more efficient to do this way. Your actual hook function will be in the same class as your ready() function, and would resemble the one Soma posted. This is correct. If there was no $page->id, it would be a new/unsaved page, and you wouldn't want to go querying the DB for it as we know it wouldn't be there. So that's what the $page->id check is for.

One minor question on the install update. I like that you've added the PCRE UTF-8 support check (nice!), but wondering if there's some way we can accomplish it without changing the encoding of the whole install.php file to UTF-8? The reason I ask is that once I pull the file into VIM, it's converting this line: if(! @preg_match('/^.$/u', 'ñ')) { to this: if(! @preg_match('/^.$/u', '√±')) { which would break it, once I hit save.

Thanks for this SiNNuT! Posting here is just as good as GitHub, doesn't matter to me. I will pull this into the dev branch and look at the changes and test, etc. Thanks again for these updates.

I don't have a simple solution to this one, but will do more thinking about how I could have ProcessWire provide a hook like Pages::statusChanged or something like that. But until we have something like that, here are a couple ways you could do it: Option 1 Add a hook to Pages::saveReady and have your hook function do something like this: Pages::saveReady hook $page = $event->arguments[0]; if($page->id && $page->isChanged('status') && !$page->is(Page::statusUnpublished)) { $result = $this->db->query("SELECT status FROM pages WHERE id={$page->id}"); list($status) = $result->fetch_row(); if($status & Page::statusUnpublished) { // page is about to be published // send your email } } Option 2 The other option would be to change your workflow such that user submitted pages went into a different parent than the live ones. For instance, user-submissions might go into parent /pending/ and published submissions would live in /live/. Then you could have your hook monitor for when a page is moving from /pending/ to /live/. If you wanted to, you could also have it take care of the publishing automatically: Pages::saveReady hook $page = $event->arguments[0]; if(!$page->parentPrevious) return; // if page is not being moved then stop now if($page->parent->name == 'live' && $page->parentPrevious->name == 'pending') { $page->removeStatus(Page::statusUnpublished); // send your email }

I think that's probably a question for the developer of the commercial template that you bought. Since you apparently bought a non-restrictive developer license, then it sounds good on the surface. But Pete is right that nobody can answer this without actually seeing the license and looking for some kind of language that says you can release your stuff to the public as open source. My best guess is that the developer license probably allows what you want to do, but it would be good to make sure.

This is really great, thanks PawelGIX! I took a look over the code and it looks nicely put together. I could only test on localhost this morning, but it understandably does not work there since the Pixlr service needs to operate on a web-accessible image that it can read from. Still, I got a feel for what it does and how it works and must say I'm impressed. I can't wait to try this on web server… it seems like a great capability to have, and I really like the way you've integrated the buttons and service. Only possible suggestions I have are: 1. Maybe move your hooks from init() to ready() and check that $this->page->template == 'admin'; before adding the hooks. Not really necessary, but would be slightly less overhead if the hooks aren't attached when they don't need to be. 2. Maybe rename on GitHub from 'processwire-pixlr' to 'PixlrEditor' (or 'ProcessPixlrEditor') so that people can 'git clone' and not have to go back and rename the directory in order to install. Again, not really necessary, but might make it quicker for some to install. 3. Post it in the modules directory! http://modules.processwire.com/add/

closestParent() makes the most sense to me. Though I'm still wondering about just: parent($selector); because the parent() function already implies closest parent (given that it returns the direct parent of the page). So if you provide a selector to it, then it's like saying: "closest parent that has [something]." I also like that extending the existing parent() function in this way wouldn't involve adding a new function to the API. It would also make it consistent with how the child($selector) function works. jQuery uses parent(selector) for something that isn't applicable to ProcessWire. jQuery's parent() can return multiple items, and the selector filters those. So they didn't have a choice to use the parent() function for this purpose. In our context, we don't actually need a separate function like they do.

I love the forum software here, but agree the code bug is making me a little insane. I'm tempted to try and go in the code and fix it myself, but wouldn't know where to start. If IP.Board would just replace their rich text editor, I think they'd have a near perfect product. The rich text editor bugs in IP.Board only seem to mutate and evolve… they fix one thing, and break another. But I kind of understand, as TinyMCE in ProcessWire is no different in this regard… fix one thing, break another, rinse, repeat. Rich text editors are just plain complicated and evil (though a necessary evil). But the world would be a better place if we all used lightweight markup languages instead. The only other consistent problem I run into is that I my "View New Content" button (that I depend on) often completely misses some things. And I've lately had an issue with PMs showing up in my list, days after they were sent. Though I'm also getting old and sometimes wonder if I'm the one missing things, as the IPB behavior seems very random. So if anyone has ever been expecting a reply from me and didn't get it (whether in the forum or PM), let me know (email ryan at this domain), as it's very possible I never saw it.

This all makes sense, I'll plan to get the closest() method added. The only thing I'm having a little trouble with is the term "closest", as to me it would imply not just parents, but siblings, children, etc. I realize it's just referring to parents in jQuery, but still question their choice of the term. Would it not be better for us just to support a $selector argument on the parent() method, like $page->parent($selector)? Seems like it would do exactly the same thing, but maybe be a little more readable? Maybe I just haven't used this particular method in jQuery enough. But I like the goal behind the closest() method, regardless of what we call it. I tend to use rootParent quite a lot in my own sites, for any number of things. But then again, all my sites are structured in a manner that the first level pages are always the main section pages… and that never changes. So rootParent and me are good friends.

Great ideas. Anyone want to do a pull request for this? Either way, I'll plan to get these updates in 2.3.

Is this what you think happened in the case you mentioned? I can't say as though I've witnessed that behavior, but let me know if you are able to reproduce the redirect loop--it seems plausible in the situation you mentioned. 301s are useful, but 302s can also be dangerous if used in the wrong place. I was stating this just to clarify why 301 is the default behavior of the $session->redirect function, and why you have to specify a second bool param if you specifically want a 302.

I'd be surprised if your IP is changing that often on a cable/DSL setup. If it were going through some wireless service, then it might be more likely to change often. Session fingerprinting also looks at the user agent string... is it possible anything is changing in that? (some browser plugin changing it or something)?

If you are in control of IT, why are you even using IE??

Repeaters are still pages, but I agree with what you say: content that needs to be moved around a lot will be more accessible outside of a repeater.