Peter Falkenberg Brown
-
Posts
347 -
Joined
-
Last visited
-
Days Won
4
Everything posted by Peter Falkenberg Brown
-
Dear Antti, I understand. Sounds like there's too much potential to disturb legacy code. I think I may create a var that contains a query to skip the trash, e.g. $skip_trash = "parent!=$config->trashPageID"; and then add $skip_trash to many, or all, of my gets and finds, just for peace of mind. In terms of the above query, since the trash can contain subsections, and thus 'trash' is not the parent of every page in the trash, do you think the query should be: $skip_trash = "rootParent!=/trash/" in order to make sure that all trash pages are correctly identified? Peter
-
Dear Soma, > Then why have a trash at all? You might swell just delete pages and not trash them in the first place. I'd vote for no because I want to get the page when using get(id). > It's not searching. I think the trash is very important. I'm just suggesting that it should exist in a programmatic silo. But... I'm the new guy, so I respectfully rest my case. I'm glad that the details could be clarified, and will now simply add a param to not look in the trash. Yours, Peter
-
Dear SiNNut, > There's certainly nothing wrong with it but why do you use this form for internet forum postings? Seems a bit redundant and overly polite to be honest. That's a question I've never been asked! (Of course, I'm well aware that my method of salutation is now "old-fashioned.") So, let's see. I'll be 59 in two weeks, and have been a writer for a long, long time. I still remember when people wrote letters on *gasp* -- *paper*... Pop Quiz: what is "whiteout"? From "Dear Sir", "Dear Friend" and "Dear Billy Bob", to "Hi", and then not even "Hi", there has been a rapid Net-driven descent into what I feel is a far more impersonal method of communication. I don't want to become an anachronism in the Internet age, but I feel that with the massive change in communication that has even reached the point of using shorthand for words, such as 'u' for 'you', the beauty of language and the importance of courtesy are in danger of being discarded. You see it on TV all the time. Someone will be talking on the phone and then hang up without saying, "Bye." I always think, "Those lazy script writers are destroying etiquette." Digging deeper, it's not just courtesy and etiquette that are important, but the underlying qualities of personal care, respect, kindness and compassion that are communicated between people. Thus, I'm holding out as long as I can, treating email and forum posts the way I would a letter, working hard to put my finger in a dike that will probably give way anyway. I do agree that one liners might not need the whole "Dear" and "Yours" thing, but for notes of any length, I still like them. I hope being overly polite is not rude. Yours, Peter
- 74 replies
-
- 1
-
-
- fields
- alter table
- (and 1 more)
-
Dear Soma, Thanks for those examples. They're certainly options, to tell the user that a page is in the trash. > I think you're the first even questioning this (not that it says something bad about it) I've heard that before, more than once. If Ryan is open to modifying the behavior of get() and find() when id params are used, and if it doesn't break backward compatibility, I'd vote for that. The only backward compatibility thing that I could think of would be if someone had coded something like "get($id)" and *wanted* to find items in the trash. Having get() and find() skip the trash unless specified would indeed break the code in the above scenario. But how many coders actually *code* an app to look in the trash? It's the kind of thing that might be done by hand, via the admin interface. When it comes right down to it, with a web app like mine, I'll be running a script every night (probably) that deletes the trash anyway. Yours, Peter
-
Dear Soma, I appreciate your input; thanks. To summarize then, I believe that you're stating that both get() and find() return items from the trash when the only selector is the page id? Is it thus correct that with all other types of queries, those functions do not access the trash unless include=all is specified? I think that the real issue here is that the trash is seen by many (or maybe just me?) as a walled-off area of "deleted" records that will never be accessed by regular code statements. In my opinion it makes programming much easier to think that the trashed items are in a protected silo that you have to make special effort to access. Based on that concept, one can program away, confident that no matter what one's syntax, the trash will not be accessed, unless specifically requested. I think that's *much* cleaner, in terms of design and real-world usage. Ryan, what do you think? Yours, Peter
-
Dear Kongondo, I'm fine with including a trash check. This thread has simply been a process (no pun intended) of clarifying the usage and documentation on the behavior of get(). I think the documentation (even on the wonderful cheatsheet) should state something like: * get() never looks in the trash unless: a) you use include=all, or b) your only selector is looking for a page id Then we won't get tripped up by assuming otherwise. But now I'm wondering if a find(id=$id) will also look in the trash. I'm *loving* ProcessWire: don't get me wrong. It's a joy to use. Thanks to all... Peter
-
Dear Ryan, I can see the logic of your comments above. I'm building a multi-user team-based web app, where someone can view a page that has a button to do something with a sub-page. The button has a hidden field with the target page id. Theoretically, someone could go to the page where they see the button, which is populated with that target page id, and then go get a cup of coffee. After returning, the page is still there, being stateless. The user clicks on the button to work with that target page, and finds that a different user has deleted that page. Thus, in my code, I work in two steps: 1: populate the button with the target page id, and 2: when the user clicks that button, check for the existence of the target page. I checked for the existence of the page using get($id) or get("id=$some_id"). But, in testing, having deliberately deleted the target page, I found that the get thought that the page was still there, because it checked in the trash. I based that on your notes above that get never checks the trash. So, that's why I think that get and find should never check the trash unless it's specified. Although I understand your point above, about bypassing the PageFinder engine. Based on my comments or need, here, what would you recommend? Should I add "parent!=$config->trashPageID", e.g. $check_page = $pages->get("parent!=$config->trashPageID, id=$some_id"); or is there a better way, perhaps using "include=hidden"? And... is it ONLY when one uses get(id) that the trash is checked? No other types of parameters? Does find() ever check the trash, when 'include=all' is not specified? Thanks very much for your help! Peter
-
Dear Marty, I like the idea of donating to Ryan's efforts. With PayPal donations / subscriptions, it's very easy. There is also power in numbers, i.e. if a hundred people donate $2.50 a month, that's $250 per month, which is better than a sharp stick in the eye. Of course, many can donate more than $2.50 a month, but in tough economic times, it's good to give people the option of a "micro-donation", rather than the choice of "donate $50 or nothing." I have an example of this process on my website, here: http://significatojournal.com/patron At the bottom of the page, a person can choose various levels of monthly donations, or choose to make a one-time donation, as a "Renaissance Patron." I think that if Ryan set up something like that, many of us here would donate at least $2.50 a month. Peter
-
Dear All, I like the idea, but one thing (I think) is that Kickstarter doesn't accept projects outside the USA, while http://indiegogo.com does. Indiegogo also doesn't have the stringent project acceptance requirements that Kickstarter has, so it would be easier to start with Indiegogo. Also, IndieGogo allows a person to collect funds even if the goal is not reached, which in the case of the modules might be good. It's better to get something than nothing, and the module will still be available. I also think that the software would benefit from early release and feedback. How 'bout this? - Indiegogo Project to Create XYZ Module - Goal, $Some dollars - Perks based on dollar amounts: . $5 - listed on web page as Donor . $10 - listed on web page as Helpful Donor . $25 - listed on web page as Very Helpful Donor ... etc, etc. Indiegogo works via perks, as Kickstarter does, but with the software being free, the perks might just as well be a mention on a web page. There's no requirement otherwise. And then, as the campaign progresses, the software updates can be posted. The campaign can be fashioned with complete freedom, so the "usual method" can be easily tweaked. Campaigns can be up to 120 days. The main thing is that all of the money isn't released (I think) until the date is reached. Peter
-
Dear Soma, That's good to know, but it seems to be an exception to the rules that Ryan laid out above, where he said: > $pages->get() or $pages->find() are not going to include pages in the trash unless you specify an "include=all" or one of the high status levels. Also, this accessed the trash: $pages->get("id=$page_id"); So, did it do so because the selector referenced the "id" field? Or does get() access the trash when there's only ONE selector, including such things as: parent=/xyz/ ? I'd vote for having find() and get() programmed to never access the trash unless 'include=all' is specified. Right now, the usage seems a little fuzzy. Yours, Peter
-
Dear Ryan, I just ran into an issue, I believe. I'm using the $pages->get($id); syntax, and it's returning a page in the trash. I'm pulling a page id from a form, and before I run the page->delete() function, I test if the page exists. # $delete_page = $pages->get("$page_id"); - this returns a page in the trash # $delete_page = $pages->get("id=$page_id"); - this returns a page in the trash $delete_page = $pages->get("id=$page_id,include=hidden"); - this does not return the page in the trash $delete_page_id = $delete_page->id; I test it by echoing the $page_id and the $delete_page_id on a response page, with echo and exit. I thought at first it was because I wasn't using quotes around the variable, e.g. get($page_id), but the behavior was the same, with or without quotes. Based on your outline above, it seems that "include=hidden" acts as a restriction, i.e. "status<2048". Of course, I may be doing something wrong, but the behavior seems inconsistent. Any tips? Thanks, Peter
-
Dear Martijn and Diogo, Yes, I entirely agree. Peter -
Dear Soma, I thought I must have missed something. Aarrgh. I think a good PW slogan is, "ProcessWire just keeps getting better and better." Thanks! Peter
-
Dear All, I have some code where I get a page object, e.g. "$some_page", that has a child record. Since $some_page->delete() won't work if there's a child record (unless there's a flag I'm missing), I naturally added code to delete the child page first, e.g. $child_page->delete(); After doing so, $some_page did not recognize that the child page had been deleted, and still complained, until I added code to recreate the $some_page object, after the child page had been deleted. After that, it all worked. My question is: Is there a better way to delete branches of pages than the method above? A "force flag" to delete all children would be great. I'm probably missing something. Thanks, Peter
-
Dear Ryan, Thank you for this extensive and very helpful explanation! Going back to the sub-topic of the TextUnique field type: Is there a way to not have TextUnique automatically delete duplicate data from a field, without a warning (via the API)? Thanks again, Peter
-
Dear Kongondo, Yes, you are correct. My sentence was incomplete. Peter
-
Dear Kongondo, Which by definition of PW's usage of 'include=all' means that get() does not include all by default, but rather just includes hidden. Yers, Peter
-
Dear Kongondo, You quoted this text: > Note that $pages->get("..."); is not subject to this behavior (or access control) and "include=all" is assumed. This is because requesting a single page is a very specific > request, and not typically used for generating navigation. To put it another way, if you are asking for a single specific page, we assume you mean it. That line seems conflicted, because it says "include=all" is assumed. Yet, as you pointed out, get() doesn't search the trash unless "include=all" is specified. About the variable "$current_page_id" -- you are right. I think I've been so used to putting things in simple variables, that I have to get used to using the OOP syntax. Also, sometimes one variable is simpler to use than a long string of -> arrow modifiers. So... about the get() and include=all -- perhaps the docs need to be tweaked a bit. And, going back to TextUnique -- it does seem to have the nasty habit of deleting the duplicated data without a warning, when using the API. Thanks for your help! Peter
-
Dear Kongondo and Ryan, I think I may have been confused, somehow. I wasn't able to replicate having get() pull ids from the trash, unless I used include=all. I had switched to find, but now I'm back to get(), and this seems to work. It doesn't pull from the trash. I'm not using TextUnique fields, because of the data deletion issue mentioned above. Instead, I've created an array of unique fields in my code. if ( in_array( "$field_name", $unique_fields_array ) ) { # we use include=hidden, instead of include=all, because we don't want to check the trash $field_value = $sanitizer->text($input->post->$field_name); $check_field_dupe_id = 0; $check_field_dupe_id = $pages->get( "id!=$current_page_id, $field_name=$field_value, include=hidden, check_access=0" )->id; if ( $check_field_dupe_id > 0 ) { # found a duplicate that's not in the trash $field_value_error = 'yes'; $field_error_text .= "<span class='error_text'> '$field_value' is not available.<br> Please try something different. </span><br> "; } } I tried a simple get() call also, like this: $check_field_dupe_id = $pages->get( "id!=$current_page_id, $field_name=$field_value" )->id; but that didn't check the trash either. Perhaps I had assumed that it was doing so because the TextUnique field was still in play, deleting the data. Best regards, Peter
-
Dear Kongondo, Thanks for this. I tested a get call that retrieved things from the trash, even though I wasn't using include=all. Is the dev version different? Ryan also stated above that get would include items in the trash. Yours, Peter
-
Dear Kongondo, That's great! So, any get() call could simply add this element to the selectors: parent!=$trash_page_id, (assuming that $trash_page_id had been set, i.e. $trash_page_id = $config->trashPageID;) Can one use the config call inside a selector? Like: parent!=$config->trashPageID, ? Thanks again. This resolves the issue for me. Although I still think that the *default* behavior of get() should not include the trash. (Assuming I'm understanding get() correctly.) Peter
-
Dear Ryan, If $pages->get always looks in the trash, is it correct that a selector using "parent" would not find an item in the trash that would have worked before it got to the trash, because the trash item has /trash/ in front of the url? That is, if the selector is "parent=/my_url_segments/" and then that page is trashed, the page would suddenly have the url of "/trash/my_url_segments/", meaning that the original parent selector would not find it anymore. Is that correct? In certain cases, one might want to use $pages->get with a parent selector, and not have to worry that it would find items in the trash. I wonder if $pages->get could also be set to exclude items in the trash, as you said find does with "include=hidden", instead of "include=all". Generally speaking, one wouldn't want any searches to find things in the trash unless it's specified. In fact, I'm wondering how I can use "get" safely, since I don't want to return any results from the trash. Best regards, Peter
-
Dear Ryan, I just updated my code, using the include=hidden, which indeed does NOT check the trash. However, after the code allowed a value (ignoring the duplicate in the trash), the TextUnique function *still* erased the field value, when it saved the record! Oy! This is my code: if ( $field->type == 'FieldtypeTextUnique' ) { # we use include=hidden, instead of include=all, because we don't want to check the trash $field_value = $sanitizer->text($input->post->$field_name); $check_field_dupe = ''; $check_field_dupe = $pages->find( "$field_name=$field_value, include=hidden, check_access=0" ); if ( count( $check_field_dupe ) ) { # found a duplicate that's not in the trash $field_value_error = 'yes'; $field_error_text .= "<span class='error_text'> '$field_value' is not available.<br> Please try something different. </span><br> "; } } The net result is that a TextUnique field becomes dangerous to data if the trash has not been purged. (Unless I'm missing something.) I found it convenient to not have to keep an array of Unique-Only fields, but simply refer to their backend settings. However, unless we can work around this, and not have the data deleted, it would seem that the TextUnique field type is too dangerous to use. Better to just use a Text field and do the deduping in code. What are your thoughts? Yours, Peter
-
Dear Ryan, I was in error above. As you wrote, get implies "all". So, I think your first option, with find, but excluding the trash, is best. $check_field_dupe = $pages->find( "id!=$current_page_id, $field_name=$field_value, include=hidden, check_access=0" ); if(count($check_field_dupe)) {// you found a duplicate that's not in the trash} What I meant previously, about the get option, is that since get only returns one page, which could be in the trash, one would have to check again, in a loop, to make sure that there wasn't another page, that wasn't in the trash. Thus, I think your find option is better. Thanks again, Peter
-
Dear Ryan, (and Martijn, thanks, too.) > It should exclude trash unless you add "include=all" to it. This, combined with the get function, is perfect. Thanks! I do want to point out again, however, that the TextUnique function, when used with the API on the frontend, with no programming checks, simply erases the duplicate value, and saves the field without a warning. I think that's less than ideal, because it's so easy to miss that point (that the data is erased). Perhaps the function should NOT erase the data, and instead throw a warning. Thanks, Ryan, as always, for your help. You are a mensch! Peter
