Jump to content

Violet

Members
  • Posts

    57
  • Joined

  • Last visited

  • Days Won

    2

Violet last won the day on January 28 2020

Violet had the most liked content!

1 Follower

Profile Information

  • Gender
    Female
  • Interests
    Reading, coffee, Linux (fave distro: Linux Mint). I've started learning a little bit of Lisp. The Lisp is not for website stuff, it's mainly just for fun.

Recent Profile Visitors

1,378 profile views

Violet's Achievements

Full Member

Full Member (4/6)

118

Reputation

  1. Wow! It gets even better! 🎉 Thank you Ryan for the detail, including an example of actual code (I would never have figured that out on my own). I will definitely be implementing this so I can add my affiliate disclosures at the click of a button! There will no longer be the need to retype the same sentence of text at the top of my articles, or even to copy and paste it... instead I will be able to add it at the click of a button! That is wonderful.
  2. Wow! Thank you Ryan! 🤩 I read the post and am already drooling over the upcoming editor and its features. If this seems a bit extreme, I should mention that what prompted me to move to ProcessWire (from Wordpress) was the switch to the Gutenberg editor in Wordpress - it was a definite downgrade upon their previous editor, it simply wouldn't let me type my content in as quickly. After moving to ProcessWire I quickly reaped the rewards of its editor and in addition, all the other advantageous features of ProcessWire. As a blogger who owns multiple sites I am constantly writing articles and therefore the choice of editor is extremely important to me. I am crying tears of joy over the stickybars feature in the new editor 😅 No more need for scrolling up just to get to the editor buttons again, yay!! I was also thrilled to see that we'll still be able to get spellcheck and wordcount on the new text editor - essential features. And retaining the ability to edit the text as source code is a must-have for those of us who are including affiliate links or ad code in our articles, thank you for ensuring that continues to be provided. The configurability of everything via toolbars and plugins looks great. I'm excited that we can add an undo button on the toolbar (maybe we could do that on the current editor too but if so I never figured it out 😳) Thank you for the thorough explanation and all the screenshots, it's very helpful to see what we will be getting. I am very excited about the new editor and am looking forward to using it!
  3. Wow thank you! Everyone helped a lot. This was great advice. Thanks to all of you, the problem is now solved. I was checking each of the things that all of you said, and this was very valuable because in some cases I uncovered some errors or problems that were unrelated to this issue but that needed to be fixed, so I fixed those as I went. So checking php logs, admin panel logs, and using debug = true in the config file turned out to be extremely helpful things to do. My site is simple, with only 1 extra module installed (the PW updating system), and no libraries or other code. So there were a limited number of places where the problem had to be, and I went carefully through the list of suggestions that all of you gave. The solution In the end, it was @pwiredthat came up with the correct idea - my template had an include for a non-existent file! I didn't notice it before and I had no idea it was non-existent, but when I looked carefully in each line for includes, sure enough there was no file of that name. Thank you pwired! And thank you also @Gideon Soand @flydev - your suggestions helped me identify other errors or problems with my site that I have now fixed. Thank you both! I was a bit surprised that in php 8.1 the include resulted in a 404 not found page, yet in php 8.0 the page was displayed properly (the bad include was ignored). The include was a little way down the rendering of the page, so I expected instead of 404 I would have gotten the top of my site rendering at least (everything above the include, such as the top menu etc). But I don't know much about the different versions of php so maybe 8.1 has a different way of dealing with this. Certainly I should have never written code with an include to a non-existent file! 😳 It was not at all intentional, I removed the file of the include at some point but forgot to delete all references to it in the template file. I will update the title to mark this problem as solved. Thanks again everyone! I couldn't have done it without you, I didn't even know where to start.
  4. I originally set up my ProcessWire site under php 7.4 and then moved to php 8.0 and then to php 8.1 at my web host. However, one set of pages with a particular template refuses to display under php 8.1, instead giving a 404 page not found. It's the standard 404 that I get if the page does not exist. But the template file does exist! And the pages are published! I can work around the problem by taking the php version back down to 8.0 (7.4 also works). But if I bring it back up to 8.1, those pages are not able to be displayed. Does anyone have any suggestions of what I should first start looking at to troubleshoot this issue? What I have tried so far: I tried to duplicate the template under another name (and yes it did produce a template file in my templates folder with the new name as expected) and I switched one of the problem pages over to the newly duplicated template, but the 404 still persisted under php 8.1. I have another template that is very similar to the one whose pages won't display, but the similar one works just fine in all php versions. I can't understand why one template would work but a similar one gives a 404 (in php 8.1). They all work fine in php 8.0 and 7.4 I'm not too concerned for the short term as my site works fine with php 8.0, but I'd like to do something about it because I do eventually want my site to work with php 8.1. I realize this is a pretty large/open question, but I would love it if anyone can give me any ideas of where I could start looking to fix this. I would love to be pointed in the right direction.
  5. Thank you @TheMick- it looks like I did miss that. It sounds like it would work, although I admit it's a bit beyond me - I'm not an experienced programmer. I was hoping to avoid writing functions. I can't remember what I did in the end on my particular project - I think I just decided to use a reasonable number of images that would look OK on 1 page and didn't bother paginating them. If I need to go back to that I will definitely take another careful look at the solution you mentioned and implement it for my situation. Thank you for bringing this to my attention, as other people who come across this thread will now be able to direct themselves to the solution you mentioned ? ?
  6. Thank you, this was a huge help! I had gotten really stuck until I read this post. One tip in case it helps others: at least on 3.0.184, it isn't clear how to mark the childless new-parent page before moving the other page to it. Clicking the new parent and moving the other page still didn't work for me. Maybe I was doing something wrong. In any case, what DID work for me is to create a temporary new page (e.g. call it 'test') as a child of the new parent. Then drag and drop move the other page in there. Then trash the test page. This is a clunky solution, but it will work if all else fails.
  7. Sorry, but can we please remove this site (https://reached.space) from the showcase? I have been running it for 3 years now, but sadly it has not done as well as some of my other sites and I haven't had as much time to devote to it as I would have liked. I have therefore had to make the difficult decision to shut it down in the next few weeks. From about 30 days from now it will no longer be running, and the domain name will no longer be in my control.
  8. My question relates to one of my live sites. I empirically managed to solve my login issue of "This request was aborted because it appears to be forged" [details below], but I don't understand the inner workings of PW, so I don't understand the theory behind why/how I fixed it, and thus, I don't know if I've managed to inadvertently introduce a security issue/loophole. Would anyone please be willing to let me know if my change, moving forward, is likely to cause any such issues? I don't have any reason to believe I *do* have a security issue (I made my change only an hour ago) but I am hoping other users can weigh in on this. DETAILS: The problem: Yesterday I updated 2 of my sites from 3.0.165 to 3.0.184 from within PW admin page, using the upgrade module - this is the way I've always done it. Immediately afterword, both sites appeared to be working fine from front-end and admin, and I even wrote and saved an (unpublished) article in what would become the problem site, then I logged out. Unfortunately, this morning, although both sites were fine from front-end, I could not log into the admin area of the problem site, getting "This request was aborted because it appears to be forged". The other site was fine and I could log into that. The solution: Since both my sites were on the same web host and had a lot of similarities, this was actually incredibly helpful as it let me narrow down where the issue might be. I won't go into everything that *didn't* work (although I noted it all down at the time so I have it if anyone asks for it), EXCEPT for 1 thing that might turn out to be relevant: the "good" site had site/config.php perms of 0644, and the "problem" site had perms of 0400. I tried changing the problem site perms to 0644 but that didn't fix the issue, so then I changed it to 0600 so I could at least write to it (e.g. to change $debug to true, etc). By comparing the contents of the 2 site/config.php files, I was able to narrow down the difference (this was AFTER ruling out a bunch of other things that I won't go into here). The difference is that the problem site had these extra lines which were absent in the good site: $config->sessionAllow = function($session) { // if there is a session cookie, a session is likely already in use so keep it going if($session->hasCookie()) return true; // if URL is an admin URL, allow session if(strpos($_SERVER['REQUEST_URI'], $session->config->urls->admin) === 0) return true; // otherwise disallow session return false; }; I commented out those lines and afterwards everything worked and I could log back into the admin area of the problem site. So, problem fixed, yay!! But - WHY were those lines there in the first place? They must have been from an older version of PW that I was running in the past. So they must have been doing SOMETHING, so have I caused a security issue in deleting them? Any advice you have about that would be very helpful. And also, was it therefore a bad idea to have my site/config.php perms on 0400? They're on 0600 right now on that site in case future PW upgrades need to change config.php. I thought 0400 was 'good' based on https://processwire.com/docs/security/file-permissions/#potential-permissions-for-site-config.php but perhaps I should have done 0600. Thank you for reading this and for any insight you can provide.
  9. Perfect thank you @Soma ! I had the exact same problem so I came across this thread and I used your code. It worked beautifully.
  10. I came up against this same issue recently, and I was able to find a solution at least for my case that did not require a module. It turned out there are 2 things going on: 1. The way the redirect is set up in .htaccess 2. Browser caching So what you would want to do is to put your redirects in section 8 of the PW .htaccess file. Do not do this, it will give the ?it= Redirect 301 /security.txt https://yourdomain.com/.well-known/security.txt Instead do it like this: RewriteRule ^security.txt/?$ $1/.well-known/security.txt [R=301,L] At this point, test it out in another browser and/or on another device because you will run into issues with browser caching where it'll seem like it's still adding the ?it= but it's just from the cache. If you don't want to try another browser or device, then clear your cache on your current browser. The browser caching issue set me back for awhile until I thought to check it on another device! At least, the above solution is what worked for me and for my use case. Besides using it for security.txt (where that page is not written in PW, I just created it manually and uploaded) I also use it when I'm redirecting a regular front-facing PW page to another, and it works there too. I just put all of those in section 8 of the .htaccess file and it works.
  11. Thank you so much @Robin S and @Jan Romero for your detailed answers including full code, I would not have been able to come up with that on my own with my current coding ability, I only deal with my own sites and I have not figured out hooks on my own yet, so your code that I can copy and paste into my files is much appreciated. Sorry about the late reply - I had meant to get back to both of you much earlier. Likewise to your concerns, I did not want to derail this thread with my question. But to get back to the OP topic at hand, which is possible future changes for PW, specifically the admin panel, I feel that there is some relevancy for considering additional/dual sort order options built into the core. Maybe an option such as "sort children first by ..., next by ....." could be a possible feature for consideration in the PW core? This is because I feel like perhaps one thing that could have a bit of emphasis in PW is the experience for the admin. If a designer is handing over a site to an admin, the admin is the one who will be adding more and more pages to the site, and ultimately they (hopefully) will wind up with hundreds of pages of content, some of which needs to be updated more frequently than others. In this case, having the page tree displayed by sorting by 2 different options could be very helpful. For example, in my case I'd like to sort by custom field "sticky" first, and then by "date published, reverse". I'm not trying to derail this thread into my use case, but I'd like to point out the general use case of a PW page tree of hundreds of pages, of which some will be more important/significant to quickly locate than others. The use case where all pages fit on one page of the page tree should be considered as an edge case rather than a typical use case in terms of the admin UX experience. All of that said, I love the admin panel menu Find, and I love than I can narrow down to the pages I want there by selecting the combinations of templates and/or fields that are relevant. So that is a way of finding specific pages without looking manually at the many screens of page tree. Indeed, this Find menu itself can be used in combo with Jan Romero's custom "sticky" field, where any pages labelled "sticky" can be found easily. The existing Find menu as it stands is admittedly much better than any equivalents in other CMS's that I'm aware of. But I would love to see a dual way of sorting children in the admin page tree, I mean sort first by.... and next by..... To be fair, I'm not sure if that's a feature that others see as important. Site admins who have hundreds of pages may well feel the need for something like this though.
  12. Updating on the final situation - a huge thank you to @Zekafor pinpointing the problem and getting me to the correct solution. I wound up using the solution you mentioned by @ryan in your thread you quoted. So the final code is: $flinks = new PageArray(); $flinks->setDuplicateChecking(false); $recentarticle = $pages->findOne("template=article, sort=-published"); $flinks->add($recentarticle); $flinks->import($homepage->desiredpages); $allarticles = $pages->find("template=article, sort=-published"); $allarticles->remove($recentarticle); $flinks->import($allarticles); $items_per_page = 3; $start = ($input->pageNum - 1) * $items_per_page; $flinks->setLimit($items_per_page); $flinks->setStart($start); $glinks = $flinks->slice($start, $items_per_page); foreach ($glinks as $onealink) { // ... here I display info about each item ... } echo '<a href="#afterpag" class="skip">' . $pagenavend . '</a>'; echo $flinks->renderPager(array( 'nextItemLabel' => $nexttext, 'previousItemLabel' => $prevtext, 'listMarkup' => "<ul>{out}</ul>", 'itemMarkup' => "<li class='{class}'>{out}</li>", 'linkMarkup' => "<a href='{url}'>{out}</a>", 'currentItemClass' => "active" )); I tested it with different values of $items_per_page and it all worked fine. Thank you so much! I was thrilled to get it working so quickly! I have marked the topic as solved.
  13. Thanks @Zeka for mentioning about the start set to 0 and pointing me in the right direction. I am working my way through the thread you mentioned. I was hoping to not have to slice the array and keep track of the start point for each page etc. I wanted to just have PW handle everything automatically like it would for a simple $pages->find with a limit on it. But it looks like I will have to do something a little more complicated, according to the thread. I have been making some progress by using some of the approaches in the thread you linked thanks, I'm hoping to get to a fully workable situation eventually.
  14. I have constructed a PageArray with pages in a specific order, as shown in this code below. I then try to apply setLimit and setStart to the PageArray to paginate it, but that doesn't seem to work. When I do that, the entire contents of the PageArray (5 items) are shown identically on both page 1 and page 2, instead of the first 3 items on page 1 and the last 2 on page 2. Where have I gone wrong with my code? $glinks = new PageArray(); $recentarticle = $pages->findOne("template=article, sort=-published"); $glinks->add($recentarticle); $glinks->import($homepage->desiredpages); $allarticles = $pages->find("template=article, sort=-published"); $allarticles->remove($recentarticle); $glinks->import($allarticles); $glinks->setLimit(3); $glinks->setStart(0); foreach ($glinks as $onealink) { // ... here I display info about each item ... } echo $glinks->renderPager(array( 'nextItemLabel' => $nexttext, 'previousItemLabel' => $prevtext, 'listMarkup' => "<ul>{out}</ul>", 'itemMarkup' => "<li class='{class}'>{out}</li>", 'linkMarkup' => "<a href='{url}'>{out}</a>", 'currentItemClass' => "active" )); The template allows page numbers, I checked it, and I've set it to page URL's requiring a trailing slash, but I've also tried it with page URL's set as either/does not matter. I've hunted around the PW API and forum and I can't seem to figure out what I did wrong. I've gotten pagination working fine in other situations, e.g. on a different template where I obtain the PageArray from a simple $pages->find with a limit in the selector. But when I instead build the array by adding to a PageArray like in my code example, then pagination doesn't seem to work. Why is this?
  15. Thanks so much for the info! I have been testing out AOS for this purpose, which I had actually not used before. I have been struggling with trying to combine AddNewChildFirst with a previously specified sort order on the parent page. Hmm. Either it's not possible, or it's not obvious to me. I have been playing around with it but can't quite seem to do it. I have read the documentation at https://github.com/rolandtoth/AdminOnSteroids/wiki/AddNewChildFirst but I don't quite understand. It says "Unlike setting the sorting on the parent page this tweak enables manual sorting afterwards." But I don't know if that means it IS, or IS NOT, compatible with setting sorting on the parent page. If you or anyone else has any advice, I would be eager to try again. I'm probably doing something wrong but I don't know what.....! I'll explain my use case, which I imagine would be a not-uncommon one: A blogger (me) has a PW site with around 100 pages with a very flat structure. The vast majority of the 100 pages are a direct child of the home page, with very few having child pages themselves. This blogger wants to sort pages by reverse creation date so newest page is at top of page tree, which thankfully I learned from adrian's earlier comment was possible through setting sorting on parent page. Yay!! But I ALSO want to make a few pages (the ones that contain ad units that need to be updated more often) always stay at the top of that same page tree. Ad unit template is different from other pages, if that helps, but even when I set AddNewChildFirst to apply to ad unit template, it still won't allow me to move the ad unit pages to the top of the tree due to my previously specified sort order. (I do not want to manually drag and drop sort order for these 100+ pages. ) So what I'm asking overall is, is it possible to specify that the page tree get sorted first by any pages labelled as "sticky pages" always at top of tree, then the remaining pages by reverse creation date? I've updated my main post further up to mention AOS AddNewChildFirst and to reflect where I'm currently at with this.
×
×
  • Create New...