Jump to content

Violet

Members
  • Posts

    51
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by Violet

  1. 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.
  2. 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.
  3. Perfect thank you @Soma ! I had the exact same problem so I came across this thread and I used your code. It worked beautifully.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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?
  9. 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.
  10. Oh thank you!! 😀 Can't believe in all this time that I never thought to look there! 😳 I tried it out now with one of my sites and it worked! I love the range of options and reverse sort being available. Whew! That's probably my biggest PW problem and turns out the solution was already in the core all along. A huge thank you! This is why I love the wonderful community here.
  11. I use PW on multiple websites that I admin and write content for. I'm therefore often updating my PW sites, either by writing new content (most commonly) or doing template coding, or coding other features such as logic-specific ad display. Based on my experiences across all my websites, here are my thoughts on the OP topics: Flexible content or page building - I've never needed it and can't see myself using it in the future. I already have a few things set up like footer content where I write footer-left, footer-middle, footer-right content as the body of non-templated pages, and I simply code my footer to display the body content of those 3 pages using what's already in the PW core and API. Easy, and perfect. I don't see any need for anything beyond that, such as flexible content or page building (for my purposes at least). I absolutely love the CKEditor 🤩 and I'm not sure why or what use case anyone would want for a block editor (in fact, a block editor is a reason why I moved away from WP to PW - the WP block editor was slow and frustrating and I could achieve way faster content creation with PW). I have a few page templates where there are multiple "body" contents, and I simply use additional "body" style fields in those templates. I understand the PW CKEditor is not going to be replaced, so I'm not worried there, but I'm not doing anything that ever needs more than defining fields and displaying them with a template. Admin theme improvements - a really quite massive "pain point" for me across all my sites is the inability to order the page tree in PW admin in a way other than the default 😭. When you have 90+ pages of content (which I do on several of my sites and hope to on the others later), not being able to specify a default order is very frustrating. Sure, for a 20-page site, no big deal. For anything more, it's quite hard. In particular, I'd like these 2 features: It seems both features exist, although I'm struggling to find a way to combine them. The ability (or the default) to be most recently created page at top (not the oldest created page which it seems to default to - it's basically in the reverse order of what I want.) And yes, there is the "recent" menu available in Admin, but that's not as helpful as you might think. [SUBSEQUENTLY EDITED - This feature already exists in the core! - see comment below by @adrian ] The ability to put some "sticky pages" always at the top of the page tree. For me, this would be regarding specific to ads I want to show/edit frequently, but I expect there are other people with other use cases who want certain pages to always appear at the top of the page tree. This feature is of equal or higher importance to me than changing the default order. [SUBSEQUENTLY EDITED - This feature exists in the AdminOnSteroids module - see comment below by @adrian - however, I am not sure whether or not this feature can be used with a specified sort order as mentioned in the previous point] File/media manager and more file sharing options - Yes, BUT ONLY if we can somehow specify a different alt field for an image each time that a central image is used in a new page. If that's not possible, then I'd rather stay on the default of having to re-upload the same pic separately for different pages (which is what I'm doing now anyway). For me, it's crucial that the image if used freshly in a new page, has a fresh image alt tag. Because you might want to re-use the same pic for slightly different reasons in each case. External file storage - I don't use this and can't see myself ever using this, although I can see how others might want it. I purposely like having everything on one host/location. Live preview and auto-save: Auto-save is certainly nice, but ONLY IF it does not over-ride a user-specified save. I sometimes change page content around, but then decide I don't want those changes, so I purposely don't save it. In this case, auto-save could cause me big problems if it saves the page when I did not want it to. On the other hand, I've lost content before by my own fault, by forgetting to save and then going away and my session timed out after I came back. So I certainly could use autosave as long as it saves the page in another location so as not to overwrite an existing page. Preview options are already very rich, with "new tab" and "modal" options that I use frequently, so I cannot see a use for live preview for my use cases. The existing previews are pretty amazing already! That's it from me. All of that said, I love PW, and admin-ing my sites is a breeze thanks to PW and its wonderful community of people!
  12. This is probably something I'm doing wrong or don't understand, but I've seen on several of my websites some slight differences in PW selector results after switching my web host. Would anyone please be able to explain why this is so? It's resulted in a few unintended ramifications, although it was easy enough to fix these. In switching hosts I've also changed several things at once - the PHP version went from 5.6 😭 (I know! part of why I was switching!) to 7.4. The mysql version may have changed too, but I wasn't able to look up the old one now because the domain is pointing to the new host. The new MySQL version is 10.3.27-MariaDB. I have zero SQL knowledge, and I simply look at the processwire selector docs when I want to use a PW selector, without worrying or considering what sort of SQL that might translate to. The PW version was the same at both the old and new host, 3.0.165 i.e. at the time of writing the latest master (but not dev) version. The specific problem as far as I can boil things down from tests I've done, is that on my old host, the ~= selector when used in findOne would return a page that contained all the specified words even if there were additional words to the specified one (example coming). But on the new host, the ~= selector seems to fail if there are additional words present in the field besides the ones specified. Here is an example: $adstr = "Article body end"; $thatspotinfo = $pages->findOne("template=banner-slot-info, title~=$adstr"); This will NOT on my new host allow the finding of the intended page, which is titled (without the quotes) "Article body end position 300x250". It comes up with nothing on the new host, even though on the old host this exact same selector came up with the page I mentioned. On the other hand, if $adstr is set to "Leaderboard position", then it does in fact find the intended page titled (again without the quotes) "Leaderboard position". So it seems like the extra words of "position 300x250" on the first page I mentioned is causing the selector not to find that page (although this was not the case on the old host, also I didn't change the page titles). Both of the page titles I mentioned will be found correctly if I instead use the "contains phrase/text" selector of *= Example: $adstr = "Article body end"; $thatspotinfo = $pages->findOne("template=banner-slot-info, title*=$adstr"); and $adstr = "Leaderboard position"; $thatspotinfo = $pages->findOne("template=banner-slot-info, title*=$adstr"); These find the intended pages of: Article body end position 300x250 and Leaderboard position Likewise, the intended pages are also found if I use the "starts with" selector ^= For example, title^=$adstr Am I correct in saying that the ~= selector on my new host means "contains all the desired words but only with no additional words present?" If not, what am I doing wrong? Ultimately, what selector SHOULD I be using to say "contains these words in any desired order, additional words are allowed to be present too?" For now, the workaround of "starts with" selector ^= is fine, but I'm keen to know what's going on. BTW here is a pic of the title field of the pages of interest in phpMyAdmin, which looks correct to me, I mean nothing got garbled from the looks of it. ADDED: I'm also getting the same sort of thing from moving another site from a different old host to this new one. In that case, for the record, the PHP version of the old is 7.2.34 and the MYSQL version is 10.1.40-MariaDB. The new host has PHP version 7.4.14 and MYSQL version is 10.3.27-MariaDB.
  13. This tutorial is largely to remind myself of the sequence of steps, but if this helps someone else too, that's wonderful! I've recently moved several PW sites to another host, and I've been refining the order of steps to minimize downtime. Please note, this tutorial is for those moving a site from one host to another host, NOT for local computer to live host (although certainly the same general principles apply). This is written from the point of view where both web hosts have cPanel - for convenience I only use hosts which have cPanel. The nameservers are one of the last changes you'll make, so don't do that yet! In the old host, go to phpMyAdmin and export the database to your local computer. In File Manager, export your website files as a zip and save to your local computer. Do the same for your email files (e.g. inbox and sent folder). Please note that if you get a lot of email coming through, and/or if you do not plan to complete all the following steps quickly, you might need a more sophisticated solution so as not to miss emails while switching over. Think about what you want your new db, db user, and db password to be (I like to change all this for security reasons). Even if you wished to keep these identical, you couldn't, because your new host will automatically force a different prefix for the db and db user, so you'll wind up with a new db and db user name anyway. The next steps are all done in the new host. In MySQL Databases in the new host, create a new database, db user, and user password from what you decided above. Also, still in MySQL Databases, add that user to the database (this is surprisingly easy to forget). In phpMyAdmin, import the database you exported from before into your freshly created empty database. If your domain name is NOT the main domain name of your new hosting account, create the new domain using Add-on Domains. Otherwise, move on. Go to the main directory for that domain (if your domain is the main domain of your hosting account then public_html, otherwise the folder of your new add-on domain), and upload your zipped website files there and unzip. Go to site/config.php and edit dbname, db user, and user password so that they match the new ones you set up. At this point, be sure you at least have a plan for SSL before moving forward. If your host does AutoSSL that's probably the easiest, at least to get started. If not, or if you're doing e-commerce, look into purchasing a new SSL cert that fits your requirements, either through your host or via a 3rd party if your host allows installation of 3rd party SSL certs. Just as importantly as minimizing downtime, you'll also want to minimize the time your site is without SSL. Then, and only then, change your domain's nameservers at your domain name registrar to point to the new host. Once this change is live, set up SSL right away - however you want to do that is up to you. For cPanel hosts running AutoSSL, just go to SSL/TLS Status and click on "Run AutoSSL" - wait until that domain's status turns green, it could take several minutes. Finally, set up your email on the new host and move the mailbox folders over (don't forget the "sent" folder!) Optional: If you have Softaculous (which I highly recommend for its auto backup capabilities), go into Softaculous, go to "ProcessWire" and click on "Import" and go for the local option not the remote one. Select your site in the fields and it will automatically import your PW installation. Then to set auto backup schedule, still in Softaculous, go to "all installations" at the top right menu, then on your list of installations go to "edit" (the pencil symbol) next to your new domain's installation. Leave all details the same except for "Automated backups" - select your desired backup rotation options and then click "Save installation details".
  14. I had this exact style of error message also when moving from one server to another, in my case it came from a different issue than the OP (OP's looked to be a problem with the web host). In case anyone else is also experiencing this, I found I had made a simple error: on my new host where I created a new database user, I had forgotten to add the database user as a privileged user of the database. Doing that fixed the problem: in a cPanel host, just go to Databases > MySQL databases and then "Add User to Database". After making that change, my site was live! Yes, it's a total facepalm moment on my part, but it IS surprisingly easy to forget after creating a new database and importing the old one into it, then creating a new db user and password, changing the equivalent credentials in site/config.php to match the new info and... it doesn't work! So when creating the database user, remember that it needs to be added as a privileged user of that database.
  15. I'm coming in late to this discussion sorry. A huge thank you to @Christophe for bringing this thread to my attention. I had a strong need for the Schedule Pages module but was hesitant to use it on my PW 3.x site as the documentation was unclear whether it is compatible for 3.x. But the comments above from @3fingers, @teppo, and @Zeka seemed encouraging about the safety of using Schedule Pages on a 3.x site. So finally I decided to install it on one of my 3.x sites and I can attest it worked perfectly! Be aware that my test case is a simple one: my site GoodKidsClothes.com doesn't have anything unusual about it from a development perspective - it's a blog that has been going for several years and has a decent amount of content, but there's nothing complex. It displays articles I've written. Extra details about my experience installing and testing Schedule Pages are shown below. Firstly I do want to point out that the manual solution of clicking the publish button on the page on the correct day is technically do-able, but is not ideal in many situations, and certainly not in the situation where I would use it. On those occasions, which fortunately are not frequent, this has entailed me getting up at 3am to press the "Publish" button (explanation below). So yes, it's do-able, but not ideal. Here is the real-life use-case I'm talking about: a brand I am promoting wants my article to come out as early as possible on day x. This means timezone has an effect. "As early as possible on day x" for a U.S. brand really means 3:01 a.m. US Eastern Time (= 12:01am US Pacific time) on day x. I cannot just publish the minute it turns to the next day here on Eastern Time because that is still the day before on Pacific Time. For brands that have time-sensitive news and deals, I am not allowed to leak it the day before, even if I'm in another time zone than the leak. A breach in trust like that is serious and would result in the brand severing any relationship with my site. So it's not just the day, but also the time, that is critical here. I can attest that Schedule Pages works fine on all counts. When I installed the SchedulePages module, it did come up with a warning: However, I carried on with the install and it all went fine and the module worked perfectly. A huge thank you to all of those who posted above, and especially the people I mentioned personally in my comment here, as it inspired me to try the SchedulePages module. You've all literally saved me from a 3am wakeup next week for a post that needs to be scheduled 😃😴😎 I'm sure all the other solutions people mentioned would have worked fine too, but I like to use modules to limit the amount of custom coding I need to add on my own. A couple of points to note about SchedulePages (besides what others have said): For first-time users, while the date picker is straightforward, the time entry part of it to schedule the post might be a little bit confusing. It certainly took me a few tries to work it out. The default time on the field says something like hh:24:11:ss , but basically you should just enter whatever 24-hour time you want like this: 14:34 (I didn't worry about adding seconds, and it just set seconds to zero). For others such as myself who have time-critical needs, SchedulePages seems to take it from timezone of the site (site/config.php ?), which is what you'd typically want, and not from the server time. I tested out the module using same-day and next-day scheduling. My server time is US Central Time, and my site is in US Eastern Time according to site/config.php. Based on setting my LazyCron to 5 min intervals and testing my schedule pages publication times, it looks like the time is being taken from my site time (US Eastern), which is exactly what I want, and not from my server time (US Central time).
  16. A huge thank you to @Gadgetto for this tutorial. This is my first time with multi-language, and Gadgetto provided the perfect tutorial for beginners such as myself to learn from. I worked my way through the tutorial and can attest it works beautifully and I could follow along without getting lost. I now have a wonderful language switcher on my site AND the html lang tag AND the href lang alternate tags, all thanks to Gadgetto's great tutorial above. The screenshots were really helpful too. His code really should be a must-read for those making their first multi-language site. Thanks again! 😀
  17. I too am grappling with this issue for an image gallery page that I'm trying to paginate. My template file contains code for groups of things in general (e.g. blogroll), laid out in a similar way to the desired gallery page. The blogroll is working just fine so I don't want to make a whole different file just for the image gallery, I just want to use different logic within the same template. I suppose I should clarify: my image-gallery template file is very short: just a php include of the blogroll template. Inside the blogroll template I have different logic for image gallery versus blogroll where applicable. I do have the page template set to allow pagination in the admin side. I like the code solutions presented previously in the thread that involve piggybacking onto the MarkupPagerNav module, since I'm using pagination for my blogroll anyway. 🤔 My question is, I'm wondering if there is (or could one day be) a function in the ProcessWire API that as a one line command, converts images on a page to a (temporary) page array, each element of which contains one image? 😶The idea being that the resultant page array could be used directly for pagination purposes just like any other page array, which is handy for image gallery situations such as this. It seems like it's a common issue people are facing. For now and for my site's situation, even for the solutions that piggyback off MarkupPagerNav, it seems like a bunch of extra code to add to a template that is otherwise working fine (I mean for blogroll purposes it's working perfectly). I really like the idea of passing a page array directly to MarkupPagerNav (with limit in the selector, I mean) without keeping track of total, start, and slice. So for now I'll probably instead from the admin office make a bunch of child pages from that page, each containing one image, and get the desired page array from that so I can handle the pagination with the same type of code as I've used for my blogroll.
  18. This is an update about how it's been running blog sites using ProcessWire. I hope it's OK for me to post in this category even though I've already showcased my sites awhile back. I thought it would be helpful for people to get a feel for what it's like to use ProcessWire on an ongoing basis for blogging. Often people talk about the development of a site, but it's not quite as often that we hear about the ongoing running of a PW site and how the PW API influences that, which is what I'll cover here. As background, we at The GrayFly Group own and run the blogs goodkidsclothes.com and flipfall.com. The development of these PW sites has been covered in a showcase thread for GoodKidsClothes and another for FlipFall. Here are some of the unique experiences I've had running these two sites. "Running" covers everything from coding and making modifications to the templates, to writing our articles, to interacting with ad partners or with others seeking us out for something related to one of those sites. So this is a different experience from agencies who develop for others; we develop for ourselves. As background, the main traffic to the websites comes from organic search results. Income from sites is from affiliate marketing and advertisements. GoodKidsClothes PW experience: "to think it is to do it." For GoodKidsClothes.com, one of the things we noticed was that if we could think it, we could do it, thanks to the easy-to-use PW API. The need for a change Here is a concrete example of what I mean: we noticed that many people would enter the site on an older article (e.g. via a search result). However, we continually put out a lot of time-sensitive information, e.g. a style guide, a piece of news relating to a change in a children's clothing company, etc. I didn't want people to miss out on this, yet many were, because after reading their entry page, they'd leave. They had no idea (unless they clicked on the link to home page) that there was another article that could be of value to them. All too often, by the time people learned about that new article via search results, they'd be too late for the news to be relevant - in fact, it wouldn't even be the newest article anymore by that point. The solution So, using the PW API, we modified the article template so that if someone was reading any article that was not the most recent article, then at the end of what they're reading, they'd see a small section highlighting the most recent article. Here is a screenshot: As you can see above, our newest article is highlighted immediately below the article they're reading, unless of course they are already reading the newest article. In the case shown above, the newest article (recipe-related) did not happen to be time-sensitive, but in most cases that article would be time-sensitive, so that's why we made this change. To make the change we simply used the PW API to query what the latest article was and store its identity in a variable - those sorts of queries we set up in _init.php. Then we modified the article template such that if the current page was not the latest article, to include the featured box that you see above. Another need for a change You'll also notice links in boxes above and below where the featured article box is. These are ads (they blend OK right?!) These ads brought another problem to our attention: we'd put the ads blocks on all articles equally. However, in the case of the most recent article, often the most recent article would usually have a time-sensitive offer or some other call to action e.g. signing up for our newsletter (well, not in the case of the recipe article above, but in most cases the latest article would have something we prefer the reader to do). We didn't then want our readers to get distracted by the ads and either leave the site, or click on an ad and click away from the site, instead of doing whatever the call to action is. The solution Again using the ProcessWire API, we modified the "article" template so that there was conditional logic on the ads: if the current page is not the latest article, include the ad code (otherwise no ads). This mean no ads were seen on the most recent article, allowing for less distractions to the reader on time-sensitive articles and more likelihood of them following through on the call to action. Conclusion for GoodKidsClothes We were able to make all these changes within minutes of thinking of them! In-house, without a ton of knowledge of programming, thanks to the awesome ProcessWire API. We actually made all those changes live, i.e. going in there and making changes to the code of the site as its running live. Yes, we had backups of the entire site and we always first save a copy of the template file under a different name (usually prefixing it with OLD_ ) before modifying the live version. This is how helpful ProcessWire is. We can make changes that benefit our site and make them in-house as we think of them. If this was done under some other CMS, we would be unable to make those changes without either a) hiring a developer or b) training up in whatever the other CMS is to make the changes in-house. Either way, it would take considerably more time to do anything. So, despite not having a formal programming background, we now have a very "nimble" site that we can adapt as needed to changes that we desire, within minutes of thinking of the change we need, with only needing to know a little PHP, html, and CSS, just the very basics, and looking up the PW API. FlipFall PW experience: "the answer is yes." In the case of FlipFall, there have been times when a potential ad partner asks a question like "can you put different ads on different categories?" or other things. Sometimes they are questions I ask myself of the website "Can we do A/B testing of different ads; i.e. show a certain ad block 50% of the time totally randomly and another ad block the other 50% of the time?" "How about ads from this company some of the time and a different company other times?" The answer is always "yes." Coming from other CMS's (that I used but did not program with) I used to brace myself a bit if I saw an email that asked "Can you....?" but now thanks to ProcessWire I don't have that bracing reaction any more. So long as I can think of a way to do it (and so far I always have, thanks to the PW API), I can say "Yes we can." More to the point, I can actually say "Yes, we can make those changes in-house within [whatever brief timeframe I think it will be]" instead of having to be vague about timeframes because of needing a developer. So I no longer worry about "Can you ...?" questions because the answer is yes. Overall conclusions ProcessWire is a superb CMS for those who own and run a site. The PW API makes it easy to make changes to the look and functionality of the site as needed. Such modifications wouldn't easily be possible on alternative CMS's that are heavily "theme-based".
  19. Thank you @Robin Sand @tpr for taking the time to respond. I tried Robin's solution and worked beautifully thanks. It's working well, I've enabled that option in one of my sites and I'm about to do it for all of them. Even though I had gone through the field options in the body field, I somehow missed the "Counter" option! 😳 [facepalm moment] I really appreciate this. I had no idea this feature was already in ProcessWire! So, no need to add it to wish list. Sorry! I will mark the thread as solved, and maybe a moderator would be kind enough to move it out of wishlist category... or is that something I can do myself? Anyway thank you both for solving the problem and hopefully anyone searching the forums will now see that this feature already exists.
  20. There are a couple of small features that I feel are needed in ProcessWire for the serious blogger. One of these is a word count in CK Editor. When writing the body of a blog post, it can be a little frustrating not to know the current word count. (If you're not sure what I mean, take a look at this online editor just as an example https://html5-editor.net/ - the ongoing word count is displayed at the bottom right.) That sort of feature is built into the core of many other blogging platforms. Writing the blog post directly in the editor is important, because if writing it in an Office program and copy-pasting it into the body field in Processwire, we can wind up with unwanted stuff in the html (like the font used, etc) - plus, it's not an elegant solution. Likewise, I find it frustrating doing what I currently do, which is writing in CK Editor and having to copy-paste into an Office program every so often, just to ascertain the word count. Why is word count so important to bloggers? When working with brands. When writing an article that's a sponsored post, usually the brand and the blogger have agreed upon a word count (e.g. 500+ words). That's quite a typical situation in the field, yet right now the CK Editor gives the author no info about the word count. For SEO purposes for their own articles. The blogger may have a certain word count they are aiming for in an article, even if they are not working with a brand. Short articles don't always do as well on Google search results, so the blogger might be looking to create a longer article. Writing without an ongoing displayed word count is rather hard on the process of writing. I can't describe it very well, but it really is hard. So, the ability to display the ongoing word count (to the author while writing) in the CK Editor is a feature I'd like to propose for the ProcessWire wish list.
  21. Thanks for your input and for taking the time to respond. I had no problems with a sub-directory in a WP site. I didn't have to do anything with WP's .htaccess rules first. This was the case for all our WP sites we transferred to ProcessWire, and also the case for a different WP site we had that had an OpenCart store attached to it in a subdirectory e.g. thesite.com/store. In case it is of relevance, all the installs I did (of Processwire, Wordpress, anything) were via Softaculous. Hmmm. Would the fact that flipfall.com/stagingfoldername had its own .htaccess file (i.e. the Processwire .htaccess) and its own index page have an effect, versus some random directory that didn't have those features? I don't know. I'm out of my depth there, I just know it worked! This was the case on the 2 different web hosts I used for our various sites we converted from WP to ProcessWire; there was nothing unusual about the hosting environment in each case. It's interesting that you ask though because I did have a Wordpress thing that would "bleed through" while I was working on the ProcessWire site in the staging subfolder. This was the Wordpress security plugin Wordfence. It refused to let me put in any iframes (I have a few iframe ads) in my ProcessWire body field. If I tried to save a page like that, I'd get a Wordfence logo with a 403 forbidden. It likewise refused to let me embed any videos etc. So I made a list of those things as they came up (it was literally just a few occurrences) and added those in at the end, after uninstalling Wordpress and moving the staging subfolder to the document root. I had only managed to find one of them beforehand (Schedule Pages) and had taken a look but it said it was compatible to version 2.x and since I'm using the latest version of PW (3. something) I figured it might not be compatible, and I didn't want to try it in case there would be some problems with non-compatible fields or something like that. I wasn't worried if it simply didn't work, but I was concerned in case a 2.7 module would have some unintended consequences to a 3.x site. I had another look at the modules and searched the forums, but couldn't seem to find the other module. I'm guessing the various search terms I tried didn't quite catch it. UPDATE November 19, 2020 I recently tested the Schedule Pages module on another of my sites and am pleased to report that it works perfectly on a 3.x site! Thank you for this solution, it's perfect.
  22. Here I'm introducing FlipFall Magazine, our multi-topic blog. It used to run on Wordpress but we recently switched it to ProcessWire. This was done the usual way we do it when converting our sites: install ProcessWire in a subfolder of the original Wordpress site under a hard-to-guess name, set up the new site there, then move content over manually, inspecting and updating each article as needed. After the ProcessWire site was ready, when we un-installed the Wordpress one and moved the ProcessWire site up one level to the document root, and... done. We used the W3CSS framework because it handles the responsive breakpoints so well (no extra work for us 😉), and it tends to default to a clean modern look. We wanted full control over the back end of the site and do customized things without having to hire a developer. As FlipFall has grown, the ability to have in-house back-end control has become even more important. Case example: Ad partners - we now can quite easily, if we wish, place different ads on different topics on this blog at a moment's notice - no need to hire a developer. Changes like this can be implemented in-house right away. The fact that we can easily incorporate this sort of thing is really nice when we're talking with potential ad partners. Helpful features of ProcessWire during this experience: The ability to export and import fields in PW was key here. We had a few other article-style sites I had done in PW recently, so having the same types of templates was very helpful. We were able to export fields and templates from our existing sites and import into FlipFall as a starting base point. No need to re-invent the wheel here! Another helpful ability of PW was when we were dealing with the categories. We built the site without category templates (but with the category page field), then added the templates in later as needed - no disruption. In other words, a template-less page field worked perfectly for the categories until we needed the template, then we just created the template. Not every feature of the site needs to be thought out in absolute full beforehand, some can be added in later as needed. Very extensible and convenient. Internal links within blog posts worked well using the page select option in the link button on the editor. When moving out of staging folder and into document root, the links auto-updated, which was nice. Creating new articles is a breeze, because under PW our fields are now customized for our needs: we created all of the fields we need and none of the ones we don't. Again, this is unlike most blogging CMS's, where they try to guess what you want (and usually get it wrong). Even for people who are solely doing blogs/article sites, I feel that ProcessWire is a much better option than most blog-specific platforms, because of PW's flexibility. The only thing I miss about Wordpress is the ability to auto-schedule post publication, which for the serious blogger is important. For example, there were some occasions on some of our other blogs where we needed to schedule posts to auto-publish at 3:01am Eastern Time to allow a time-sensitive post to come out as early in time of day as possible on publication date (3:01 am US Eastern time ensures it's that same day 12:01 am on Pacific time). We were delighted to see that ProcessWire is much, much lighter on resources of the hosting environment than the same site on Wordpress - we could see this empirically on our web hosting stats before and after the switch.
  23. +1 for Agree that multi-sort would be even better, but if not, then a simple page tree sort order flag ascending/descending preference setting would be so very helpful. For anyone who is making anything bigger than a simple few-pages site, this is so important. I have 2 sites that run ProcessWire which have 60+ pages each, and typically I'm much more likely to edit the most recently-written pages, not the oldest pages. Similar to Mikie, I don't want to install AOS just for this one purpose, nor do I want to install a module just for this. I like the UIKit admin theme, and I'd prefer it if the core could handle the sort order. As you can see in the case of one of my sites above, I have to click on "2" every time I want to edit any of the most recent pages. It's not a massive problem, but it can be a lot more frustrating than you may think for anyone who is regularly updating existing content. As a blog owner, this happens fairly often for me, and this is not my only blog. Also, 68 pages is not a large number of pages by any means, so sort order will affect anyone who is running anything more than just a small number of pages. I actually found this topic while searching the forum for a way to change the sort order of pages in the admin tree, but it looks like it's not possible, so I thought I would voice my support for this as a wishlist item. I love ProcessWire; the lack of sort order options is a miniscule price to pay for all the benefits that come with ProcessWire, so even without a sort order option I still enjoy ProcessWire. ADDED: I realized after writing this that (at least on UIKit theme) that in the admin panel I can select Pages>Recent instead of Pages>Tree, and I can get to the most recent pages that way. So, this is a decent workaround for my purposes thanks but I can see that other people might still prefer to have a pre-specified sort order for the tree, depending on their purposes.
  24. Wow! This is perfect! 😍 Thanks for the different options of solutions you offered @dragan. I will go with this one you suggested: I am about to switch over one of my other sites. Am thrilled that with altering 1 line in the .config file I will save some clicking, and to be honest it's not just the clicking; I forgot to do it on one template, and then it took me awhile to figure out what was the problem when the rendered page looked weird. So this will save me quite a bit of time. Thanks again!
  25. I know that we can disable the append of _main.php by clicking the box in the template file. However, is there a way to disable it by default, so that new templates created do not append _main.php? For those of us that never use _main.php, it's something that needs to be clicked every time a new template is created. Not a big deal, but is there a way to set it up in the settings to default to NOT appending? I tried different searches on the forum and haven't come up with anything yet. I understand more the default automatic prepend of _init.php because most people have variables to populate there before the rest of the page loads. Anyway, if there is no solution to my question, it's a minor thing, but thought I'd ask as I'm in the process of moving several of my sites to ProcessWire and this is a question that I think of often.
×
×
  • Create New...