Jump to content

Violet

Members
  • Posts

    60
  • 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,730 profile views

Violet's Achievements

Full Member

Full Member (4/6)

120

Reputation

  1. Thank you for this idea! This sounds neat, definitely will be checking out New Relic. I hadn't heard of it before, so this is certainly helpful information. Thank you for your valuable suggestion of using timestamps via the Page Hit Counter module. At first I thought this might take more customizing/coding than I'd be comfortable with, but then I saw on the Page Hit Counter module page it says: ... so it seems a lot more flexible than I first thought! It's not just a "look at stats in the admin panel" thing, it's way more than that. I can query actual numbers of hits for a particular page, sort pages by number of hits, etc.
  2. Overall, I'm trying to make the behavior of my PW sites dependent on traffic amount, where in high traffic situations I want slightly different behavior, which I have an implementation in mind for - my only problem is how to approximately quantify traffic rate from within my template code. Any ideas? As background, I'm trying to do something vaguely similar (but only vaguely!) to Ryan Cramer's post of how he drove around a DDOS attack - you don't need to read the link if you're busy - I'm just trying to show where I'm coming from in case anyone wants the background. I already have a solution for page requests for commonly requested non-existent pages like wp-admin (return server 404's instead of letting PW handle them). So it's only the level of traffic to my legitimate pages that I'd like to get a feel for. I'd ideally I'd like to know things like rate of SQL queries or the rate of bandwidth - is there a way to get an idea of that from within a template? I already know about the PHP function sys_getloadavg() from Ryan Cramer's post linked above. That would be my default measure if there's nothing better I could use. The only downside is that sys_getloadavg() could be high for reasons other than either DDOS or legitimate traffic. For example, when my server is doing auto-backups on cron or doing other automated tasks, I'm assuming that it could contribute to a higher load average for reasons other than traffic. I don't plan to give up any of these essential tasks, so is there a way I can get an idea of traffic that is requesting normal/existing pages? In case it has a bearing, only 1 page template would be affected by this. Thanks for any help anyone can provide. Even if you don't have a specific solution to this exact question, I'd love to hear any comments/input that you might have surrounding this overall topic.
  3. 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.
  4. 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!
  5. 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.
  6. 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.
  7. 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 ? ?
  8. 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.
  9. 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.
  10. 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.
  11. Perfect thank you @Soma ! I had the exact same problem so I came across this thread and I used your code. It worked beautifully.
  12. 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.
  13. 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.
  14. 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.
×
×
  • Create New...