maniqui

Take a look at this issue at Github: https://github.com/ryancramerdesign/ProcessWire/issues/1580 It's fixed on 3.0 (branch "devns"). Not sure if Ryan backported the fix to PW 2.7.x.

Hi. Sometimes, I give a "like" to a post reply as a way not only to like it, but also to bookmark it (because it may be useful in the future). I wonder if there is a way to list & browse all the replies I've liked. Or if there is a better way to "bookmark" replies. Thanks.

Should the pages created as categories and subcategories be configured/kept as unpublished or hidden (or perhaps both)? Or for this to work, should they be both published and viewable? My main concern is that these categories (ie: Year, Model, Type, etc), being that are just PW Pages, all are directly children of Home (root), and so, are at the same level of depth than other PW Pages that may be "real" pages (ie. Cars, About, Contact). Then, the "problem" would be: iterating over the children of Home ($page->children()), for example, to display a first-level nav, will eventually show the main categories, if those are unhidden. Right? PS: great tutorial, it really helps to clear up a lot of things for PW newcomers. It also helps to think better the relation between PW concepts (products as pages, categories as pages, etc) and general web design/development. Thanks for sharing.

Try $layout = wireRenderFile("products-index-tpl", array('products'=>$childpages));

Hi. If I recall correctly, you access that screen by editing the home (the root page). It is on one of the tabs.

I'll gladly accept it and help the community whenever I can. As said before, you can find me at #processwire at irc.freenode.net

Ryan, thanks for the prompt reply. It seems both of us are right. From a ProcessWire codebase point-of-view, you are right: almost all the code written (added/removed) on those 11 missing commits is already on dev. I say almost because there are 3 lines of code introduced in master that are still missing in dev, as you can see below. $ git diff dev...master diff --git a/wire/modules/Fieldtype/FieldtypePage.module b/wire/modules/Fieldtype/FieldtypePage.module index 06e0f65..c5e2669 100644 --- a/wire/modules/Fieldtype/FieldtypePage.module +++ b/wire/modules/Fieldtype/FieldtypePage.module @@ -254,6 +254,9 @@ class FieldtypePage extends FieldtypeMulti { } else if(ctype_digit("$value")) { // page ID $result = $this->pages->get("id=" . $value); + + } else if(strpos($value, '|') !== false && ctype_digit(str_replace('|', '', $value))) { + $result = $this->pages->getById(explode('|', $value)); } else if(strpos($value, '|') !== false && ctype_digit(str_replace('|', '', $value))) { // CSV string separated by '|' characters So, again, you are correct: at some point, probably by copy-pasting chunks of code, you introduced into dev the pieces of code (the changes) on those 11 commits. A proof of that is that the changes introduced in commit 9b3039d (an atomic change, only present in master) are also part of commit 7dab612, which is a huge commit in dev. It's almost as if you cherry-picked (see git cherry-pick) but in a manual, human, untidy way. So far, so good. And the only changes you missed to move manually are those shown on the git diff output above. From a Git point-of-view, I'm right: 11 commits done in master aren't part of the dev branch. Even Github shows that same info here (dev is 11 commits behind and 4 ahead of master) and here (comparing both branches, it shows the same diff as above). Technically speaking, from a Git point-of-view, master and dev have diverged. So, now that we all have a better understanding of what happened and what is missing from dev branch (just 3 lines of code), let me suggest what would have been better options to bring the changes from those 11 commits in master branch back to dev branch. As said, Ryan, you did it manually, but that's prone to (human) errors, as changes could be missed and/or introduced with errors. First (best) option: as suggested on previous post, just merging master (righ now, or back at the time when you did those 9 commits now known as "2.2.9.final") back to dev is all that's needed. Right now, that action will just bring to dev those 3 lines of code missing, by creating a merge commit. In the graph, it will clearly show that those commits are part of dev and there won't be any doubt. Back at that time, that action would have bring the many lines of code missing, releasing you from the task (human & prone to errors) of manually having to copy-paste them. Second option: git cherry-pick. Right now, this option won't make sense, as you already "cherry-picked" the changes from master back to dev in a human fashion. Back at that time, if for some reason (I can't think of one) you couldn't merge master back to dev, git cherry-pick would have been the best option, as it lets you manually pick which commits from master you would like to re-apply to dev. Take into consideration that cherry-picking commits from a branch (ie. master) creates new commit objects on the destination branch (ie. dev). A commit created by a cherry-pick will have a different hash than the original commit (the one cherry-picked), but it will introduce the same exact set of changes (ie. the same +/- patches). Bottom line: while standing on dev branch run "git merge master" and call it a day. Mmmmm. Personally, I'll suggest to stay with the "dev" name for the development branch. Something you could do is that, after some release (ie. 2.3.0), on the next commit, on some project file (ie. readme.txt, or changes.txt, or version or whatever you use) you rename the version to 2.3.1-dev. In this example, it's important to get that "2.3.1-dev" means "the development done for next 2.3.1 version", and not "the development done after 2.3.1 release". Then, on some place of the PW admin, you could print "ProcessWire (2.3.1-dev)". But the question remains: at which exact commit of the many commits that may correspond to the development of 2.3.1 is this PW installation standing at? I'm not sure what's the answer for this, but Git may be helpful here. There is the git describe with "shows the most recent tag that is reachable from a commit". For example, if in your PW repo you run: $ git describe master You will get this output: 2.2.9.final-174-ga8024bb Which means that master branch is 174 commits above the "2.2.9.final" tag, more precisely in the commit a8024bb. The "g" is just a prefix to indicate that is a commit done in Git. So, as you can see, there is a good way to describe where is standing someone in relation to last tagged version. Ryan, 2 last things: First, as you are the BDFL and main commiter of ProcessWire, I'd suggest you to begin using annotated tags: http://git-scm.com/book/en/Git-Basics-Tagging#Annotated-Tags Second, I'd suggest taking a peek at this Git branching model: http://nvie.com/posts/a-successful-git-branching-model/ It's a pretty popular one, and it may fit into the way PW is currently being developed. Even if you don't want to follow that (or any other) particular branching model, the article is pretty good to clear up some concepts. That's all by now, thanks for reading.

Thanks for the welcome, apeisa! I've some a fair amount of experience with Git, and I'll gladly shed some light. Even if not officially announced (not sure what that means exactly), PW homepage already announces & offers to download PW 2.3.0, and it links to a zipball generated from master, as you mentioned. We could say tht PW 2.3.0 has already shipped. Problem with saying that "2.3.0 is current master" is that master (the branch pointer) may move at any time, when further development (ie. probably a merge commit from dev) happens on it. My suggestion is: tag the commit a8024bb as "2.3.0" and avoid any potential confusion, as may happen now between tags 2.2.9 and 2.2.9-final. I consider that tagging each release is really helpful & useful for others (like, well, me) that have cloned/forked the repo & may need to checkout an old version to work with. Finding a merge commit from dev to master may be a hint that a new version may have been released, but really, it just too ambiguous, imho. But there is something that worries me a bit more... keep reading . 2.3.0 is the merge between branches dev and master. Problem is: there are 11 commits (including the 1 merge commit) that happened directly in branch master, 11 commits that were never merged back to branch dev. Or, in other words, dev branch is currently missing 11 commits. I'd bet that wasn't intended (but correct me if I'm wrong), being that those 11 commits are part of both 2.2.9.final and 2.3.0 releases. Proof of this is the current output (which shows the 11 commits missing from dev branch). $ git log --graph --oneline --decorate dev..master * a8024bb (master) Merge branch 'dev' * d453a76 (tag: 2.2.9.final) Enable the findPagesCode option in Inputfieldpage for non-Fieldtype context use of Inputfield forms (like FormBuilder) * 9b3039d Fix issue with RepeaterPageArray lacking a makeNew() method. * e1c66b3 Update FieldtypePage to support setting by strings like $page->someField = "123|456|789"; * 3a76113 Fix non UTF-8 encode on InputfieldCommentsAdmin cite line * c3334a7 Fix issue with InputfieldCommentsAdmin not working with open/close of individual comments in the page comment editor * 3386764 Fix issue with InputfieldSelect.module that was appearing on select fields with Form Builder forms. * c8e832d Update InputfieldMaxWidth to be 100% rather than 99%. Add isNew reserved word to core/Fields.php. * ac24667 Minor fix to InputfieldCheckbox.module * 9b796be Fix InputfieldCheckbox so that it displays proper label (rather than value) * e937903 (tag: 2.2.9) Fix issue with InputfieldRepeater 'add item' giving a JS error in some cases. To get out of this situation, one solution (probably the most correct one) is to merge branch master back to branch dev. These are the steps: $ git tag -a 2.3.0 master # As suggested previously, add the corresponding release tag # Alternatively, you could do: "git tag -a 2.3.0 a8024bb" # as a8024bb is less ambiguous, as it is the commit corresponding # to the 2.3.0 release (the current tip of master branch) $ git checkout dev # Switch to dev branch $ git merge master # Merge master branch into dev branch # Alternatively, if you tagged the master branch as suggested, you could do: "git merge 2.3.0" That will create a merge commit and then, the 11 missing commits will now be part of the dev branch, putting PW development back on track. Please, don't hesitate in getting back to me or reaching me at #processwire on irc.freenode.net (my nickname there is Mannequin).

I've seen that PW homepage is already linking to a 2.3.0 download (which is a link to a zipball file generated from the tip of master branch), but FYI, it seems there is no 2.3.0 tag yet: https://github.com/ryancramerdesign/ProcessWire/tags There is also a "2.2.9.final" tag, that is 9 commits on top of "2.2.9" tag. These 9 commits have been there since a few months (and I always wondered why those were there, instead of being on "dev" branch). I think this adds up to the confussion: which is the real 2.2.9 version that most users have been downloading & installing: the 2.2.9 tag or the 2.2.9.final tag? (btw: Hi, n00 here, first post, just learning PW )