Jump to content

thetuningspoon

Members
  • Content Count

    624
  • Joined

  • Last visited

  • Days Won

    2

thetuningspoon last won the day on May 8 2015

thetuningspoon had the most liked content!

Community Reputation

504 Excellent

3 Followers

About thetuningspoon

  • Rank
    Hero Member
  • Birthday 11/03/1986

Contact Methods

  • Website URL
    https://si.design

Profile Information

  • Gender
    Male
  • Location
    CT, USA
  • Interests
    Design, Programming, Tiny Houses

Recent Profile Visitors

12,415 profile views
  1. I've encountered users who don't even know what a tab is, and are confused when they cannot get back to the site they were on before by just hitting the back button! It's no use keeping your site up in the background if your users don't know how to get back to it 🙄 So on principle I agree with @adrian on this, but our clients still keep asking for target="_blank", so that's that.
  2. Something else important to note here: If you are returning pages with your find that have page fields on them, and you are subsequently accessing fields from those subpages that you also want to have autojoined, you should use Robin's method rather than passing in the joinFields option into your find. It's worth noting that autojoining a page reference field only automatically joins its id. It still requires a separate database query to get the page, which occurs the first time you try to access that field or one of its subfields. If you have the fields you want to be autojoined flagged, they will be loaded along with the page at that time.
  3. The problem is in ProcessPageAdd on line 1021: https://github.com/processwire/processwire/blob/649d2569abc10bac43e98ca98db474dd3d6603ca/wire/modules/Process/ProcessPageAdd/ProcessPageAdd.module#L1021 It is calling Page::setEditor, which is overridden by User::setEditor, which performs a redirect instead of actually setting the editor. Removing this line fixes the issue. Github issue: https://github.com/processwire/processwire-issues/issues/977
  4. Just came across this thread again after running into this issue again on a new project. It's still a problem. Right now I can only create new users with an alternate template from the the Access/Users page, which does not fit my needs.
  5. I found the commit where that line was added, and the issue that it was related to: Commit: https://github.com/ryancramerdesign/ProcessWire/commit/8d126246772633be773d72f5262acdf14f4c1e31#diff-bbe4731226c86c286f0e4e95a4756eda Issue: https://github.com/ryancramerdesign/ProcessWire/issues/1942 One question that comes to mind is whether a clone should be considered a "moved" page (have a parentPrevious property set), since the original page still exists. If it were considered new instead of moved, I think the line in question would not apply. It still seems like there is a lot of overhead here for a move operation. But I still need to study the issue report linked above more closely.
  6. I know this is ancient, but I've also run into a bottleneck at PagesEditor::saveParents() on one of my projects running PW 3.0.123. The scenario is as follows: 1. I am cloning a single page (not recursively) which is in a list with several thousand siblings. 2. I am manually looping through the original page's children and cloning them over as children of the new page. (I am doing this manually because sometimes I don't want to clone some of the children) I've timed this entire process at around 7 seconds for a page with just 2 children. Using the Debug timer, I discovered that the initial page and its first child clone over at just .1s each, but the second child clone (and any subsequent children) each take around 7 seconds to complete! Although I am manually looping through the children and cloning them, using PW's recursive clone seems to encounter the same issue. In fact, my test came in at 8 seconds for the same set of pages. The relevant code begins at line 733 of PagesEditor.php where saveParents() is called and passed the parent’s parent when a page has changed parents and it has more than one sibling. It seems that the code is recursing into all of the parent page's thousands of siblings, perhaps unnecessarily. It looks like this line was added in at some point after the fix ryan provided in this thread.
  7. Just found one possible inconsistency here. On a pager with a numPageLinks value of 3 and 23 pages total (I think the total number is effecting it somehow), the fifth page shows 4 page links between the ellipses instead of 3. See https://www.kba-architects.com/projects/page5 for an example.
  8. Hi @matjazp - I just tested with values of 2, 3, 4, and 5 and it works perfectly 👌 A value of 1 or 0 should probably be ignored and replaced with 2 as the minimum. Here is the link to the GitHub issue for this: https://github.com/processwire/processwire-issues/issues/969 Do you think you can submit this as a pull request?
  9. Repeater Matrix extends the regular Repeater, so it supports all of the same methods as the repeater field, including getNew(). I am not sure how you would set the type for the new item, however.
  10. Good call @Robin S. I should have done more testing before I started exploring a fix. Maybe this is a core bug. Should I submit an issue report?
  11. A client has requested that the pager always show the next page number when the total number of pages exceeds the numPageLinks. This is what it's showing right now when on Page 7: Prev 1 ... 6 7 ... 24 Next This is what they would like: Prev 1 ... 6 7 8 ... 24 Next I think it is a little more intuitive for some people to be able to click on the next page number rather than on the Next button. I looked through the options and didn't see anything for this. I started looking through the code as well to see if I could hack it but I'm having trouble pinpointing where this determination is made.
  12. I find that the need to set the value of one field to another field is so rare in practice that it cannot possibly outweigh the time, frustration and possible security flaws that dealing with turning off and on output formatting has caused me over the years. It is not hard to use $page->getUnformatted('field') in the rare instance when that is what I actually want to do. At least if I am unintentionally saving formatted values to other fields, it is just a mistake and not a potential security concern like outputting fields to the page that are not entity encoded is. And it certainly doesn't seem like it should be an application-terminating error. One example I recently ran into was calling a function to send an email while in the midst of editing a page via the api. In such a case you need to remember to turn off output formatting and back on again before calling the email function (and then back off again before doing your save), or your email will be outputting unformatted fields. it took me ages to figure out why the dates in my emails were sometimes coming out as timestamps. I use setAndSave() now wherever I can, but I do wish I could use the regular object setting syntax sometimes. I think this is why people say that "global mutable state" is dangerous.
  13. That is correct. A page can be thought of as a particular record and the template as the table/schema. But if you are creating a front-end form for populating data to pages, you may want to create a single page with its own template which has the form on it for creating the records, and then have a hidden area in the page tree where the data-only pages are kept (this is in essence how PW's admin page editor works). The possibilities are endless. But either way, you're just working with pages--no outside database.
  14. For the initial live deployment, we just make a copy of the database on the server, sync the files up, and update the config file to point to the correct database. There's no need to run through the actual installer again. For ongoing database updates, we usually use PW's import/export functionality for syncing templates and fields, and then have to remember to add any new pages that are needed. But that is not always ideal, so a solution where all DB changes are done by script (as with the migrations module) is probably a better long term approach if you can pull it off.
×
×
  • Create New...