Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

56 Excellent

About Violet

  • Rank
    Jr. Member

Profile Information

  • Gender
  • Interests
    Reading, coffee, Linux (fave distros: Debian, BunsenLabs, and Linux Lite). I've started learning a little bit of Lisp. The Lisp is not for website stuff, it's mainly to handle math that would otherwise run too slowly as a shell script.

Recent Profile Visitors

360 profile views
  1. The final verdict is in! Thanks to everyone, I have moved the site to the new domain (actually it's duplicated but that's OK since I can erase the old one). When I started to act on the recommendations, I sort of accidentally discovered a 4th option (explained below) which worked. But I wish I'd done it the way suggested by @Robin S, @Autofahrn and @jens.martsch (updating $config->httpHosts in site/config.php). I'm sure that would have been even faster. So anyone else who comes across this thread looking to do the same sort of thing (moving site to new domain on same host), you might like to try that solution of $config->httpHosts in site/config . What I wound up doing However, I had not yet read those 2 latest responses at the time, so I was thinking about all the different methods and was looking to try the Duplicator module. Desiring to be a responsible site owner, I went to create a Softaculous backup of my site before trying the Duplicator module. This way I can restore my original site in 1 click if I do anything wrong. To my happy surprise, in the backup menu in Softaculous, one of the other options besides back up was "Clone site". Well, being curious, I thought "Let's try that, and if it doesn't work out, I can use one of the other methods people suggested". So, I tried Clone Site, and it worked perfectly! I just had to do point and click and tell it which of my domains to put the cloned copy of the site in, and boom, there it is at the new domain! After doing that, I then read the newest responses to my thread and realized that it would have been even faster to use the solution of Robin S, Autofarn and jens.martsch, but anyhow, the Softaculous method works too in case anyone has it available to them and was wondering about it. And after the site is in the new domain... A big thank-you to pwired for the advice given This turned out to be really helpful - I tried the search function in phpMyAdmin and found a few mentions of my old domain name still in there. It was clear from the results which pages I needed to edit in the processwire editor. So it may be a useful step for others too who are looking to do a similar type of domain move. Thank you again to everyone who responded in this thread. All of the suggestions were very useful. I really appreciate the sense of community here.
  2. Wow! I'm blown away by receiving so much help here, and it's very much appreciated and needed! Thank you. I will be reading all the answers again carefully, but I thought I'd also post here answers to 2 questions that came up. Great point. This is a small site, more than a landing page but less than my other sites. It's maybe 15 - 20 pages on the front-facing side (that is, excluding admin pages etc etc). I plan to add more to it later, but for now it's fairly small. It's a simple site in terms of not needing other software packages etc - it's just straight processwire. Actually no, I'd be on the same server. Sorry, I should have mentioned that, I didn't realize that would make a difference. This is my first time migrating ANY site to a new domain. I do have several other sites running on that same host though, in case that affects anything.
  3. In this case, I have a live Processwire site which I'd like to migrate to another domain name. I have come up with 3 possible approaches, and would like to please know which you think is best suited to my situation. Here are 3 factors to take into account: I have phpMyAdmin on both the old and the new domains, in case this helps. On the new domain I want to use Softaculous to do the initial Processwire install. This is for reasons other than ease of install (although it certainly makes for a fast install). I am not at all confident with SQL and would rather avoid it if at all possible. Option 1: Manual. Export field contents (e.g. title, body, etc) from current domain database into CSV format using phpMyAdmin. Install PW in new domain with Softaculous. Then in new domain, copy over the template files, and from PW admin screen of old domain export the fields and templates, save these details for import in the new domain. Copy over image files into assets folder of new domain. Create new pages manually and fill in field contents in new domain in admin office by copy-and-pasting from my CSV files. This is likely to work really well, but seems time-consuming. Anything that can give the same result but uses less time would be a big improvement. Option 2: Duplicator Use the Duplicator module ( https://modules.processwire.com/modules/duplicator/) - but I'm not sure if it's designed for use when moving to a different domain name (as opposed to just migrating same domain to a different host). Option 3: Site Profile Exporter Use Site Profile Exporter ( https://modules.processwire.com/modules/process-export-profile/) - but it's designed for use as a version of the site that you can share with others with no confidential data, while I need a regular full site. Hmmm.... Does anyone have any ideas which of the above options is best? Or is there a better approach that I have not considered?
  4. Oh thank you! Can't believe I missed it.... I actually looked at the pages table but silly me was looking for "URL" as column label so I didn't even think to look at "Name". Oops. Yes, it's there, thank you so much! I exported the pages table as CSV and all is good now! Marking as solved. Thanks!
  5. Sorry for this noob question, but I'm having trouble finding where the page URL's are stored in the database. Would anyone please be willing to point me in the right direction? Using phpMyAdmin, I've managed to find my other fields, like "body" "title" etc etc. However, I'm struggling to find the page URL's. I also tried searching the forum for this info, but I could not seem to find anything that matched. Ultimately when I find the URLs I'm going to export them as a CSV. I've already exported body, title, etc with no problems at all. But the page URL for some reason I can't seem to find. In the meantime, I've gotten some of the URLs from my sitemap.xml, but in that situation it's not indexed by page ID. Its a decent workaround for now and I'm happy to match URLs to page ID's manually, but for the future in case I didn't happen to have a sitemap.xml on my website, how should I find my page URL's using phpMyAdmin? To clarify, when I mean the URL, not necessarily the full https://.... I just mean the relative URL I defined in the place where I created that new page in the admin screen. I don't care about parents, children, domain name etc, just the url of that particular page (e.g. how-to-inflate-a-basketball ).
  6. Here is GoodKidsClothes.com, a blog about kids clothes - news, style tips, sale alerts, and more. GoodKidsClothes.com originally ran on Wordpress, and I moved it to Processwire recently, the new Processwire version is shown above. There was a fair amount to change over, since it had 4 years on Wordpress before switching! I kept the colors, background, etc in line with what it had been before - a soft, friendly look. I wasn't seeking for it to be identical to its previous appearance, just similar but updated/better/more fun. The html I did from scratch, although I used the W3CSS framework. I love W3CSS because they handle all the responsive breakpoints, and the default styling is a clean flat modern look with plenty of great pre-sets. The reason I moved this site over to ProcessWire was not looks but actually functionality: the new Wordpress editor (Gutenburg) had just come out - one of its quirks is that it couldn't keep up with my typing, so I had to literally slow down my typing, which really defeats the purpose of WP as a blogging CMS. (Processwire's editor keeps up with me just fine). Also it was anyway time for me to manually go through and update old articles, put in new affiliate links etc, so I decided to do everything all at once and switch over to ProcessWire. In case anyone is wondering, the switch-over was manual since I was going to examine every article I'd written to either a) update it, b) move it to another of my sites, or c) trash it. This was not time-efficent but this way I wound up with being certain everything was up to date content-wise, plus no unwanted bloat (like extra WP fields) could make its way into my Processwire database. I simply installed Processwire via 1-click Softaculous install in a subdirectory of the original Wordpress site, with the original site still running. Then after I had the Processwire version fully finished (this took several weeks), I simply uninstalled the Wordpress version and moved the Processwire site into the document root. This way I had less than 1 minute downtime. UX/UI The first menu link is an all-abilities-inclusive version of "skip to content". The actual text displayed depends on which page template is being used ( this text is assigned in _init). For example, the Article template will display "Scroll to article", while Search Results template will display "Scroll to results". Link styling in the body of article content is designed for both the desktop and mobile user, with simultaneous underlining and highlighting showing the entire link region to aim for when tapping on mobile. On the home page and some other templates as needed, skip links are available within the page. They offer the option to skip past a series of links such as social sharing links, pager navigation, etc for a) the screen reader user and b) the fully-sighted keyboard-only user (no mouse). These links only become visible to the eye when focus comes upon them via tabbing. Tab through the home page to see it in action - this is the template where the most skip links have been needed. Cookie manager - originally I used a slider for turning Google Analytics tracking on/off but changed to checkbox because I could not work out a way to manipulate slider without mouse. Newsletter - field, and feed One feature of this site is its newsletter, and you'll see here how Processwire shines. The setup was (and still is) that on days when a new blog post relevant to children's clothes is published, subscribers get a brief email notifying them of the new article and linking to it. This is all handled by MailChimp, which I highly recommend. Under the old Wordpress system, I had to use categories to classify which of the posts wound up going into the newsletter (kids clothes) and which posts didn't (other topics like parenting etc). There was always the chance that under default WP behavior, things would be classified incorrectly if I forgot to specify categories. Under Processwire, I've set up the article template to have a field called "Newsletter" which is a simple drop-down choice of "For newsletter" or "omit from Newsletter". There is no default value, and it's a required field, ensuring that I do remember to specify it one way or another. It's such a relief to do it this way! My newsletter feed was easy to customize under Processwire: I created a feed template that selected a) all the pages using the article template that also had b) the "For newsletter" field selected, and those are listed at /newsletter in feed format. Please note that this feed may be empty right now - I omitted my existing articles from newsletter feed as subscribers have already seen them, and haven't had time to write new articles yet. To clarify, I'm expecting the newsletter feed at /newsletter to only ever be read by MailChimp, although it's certainly possible to be used by feed readers or read by humans. XML sitemap Under Processwire, I was able to generate a list of articles in XML format at /sitemap.xml that I can then submit to Google as the XML sitemap for this site. Best of all, unlike web-based crawler-type sitemap generators which generate a static sitemap that you then upload to the document root, my Processwire /sitemap.xml auto-generates each time the page is loaded, so it's always auto-updated - any changes in back office like article deletion, unpublishing, adding new articles etc are reflected automatically in /sitemap.xml. Some advantages of Processwire features when templating 1. _init.php file - my theme was designed for subsequent use in my other sites, so selected pages for use in nav menu (About, Privacy Policy) are automagically "found" in _init.php as follows: $pp = $pages->findOne("template=BN-infopage, sort=created, title*=Privacy"); $ab = $pages->findOne("template=BN-infopage, sort=created, title*=About"); 2. Made use of Processwire's built-in retina-friendly image resizing class, class="hidpi" to ensure social sharing icon links render at a decent resolution on mobile screens. Other info To check my html and to help identify problems that are not visible to the eye, I found it incredibly helpful to use the "audit" feature available on Chromium and other Chrome-based browsers. (F12->Audit-> select options you want). The order of the blogroll looks a little odd at first glance but it's ordered based purely on publication date. However, I updated some articles and they display the last updated date, which makes the blogroll look like it's not in date order even though it's in publication date order. Also some dates (the older article dates) reflect a user-specified date field, to show the article was valid at the time it was written (e.g. time-sensitive info such as reviews, sale alerts, etc). I'd be happy to explain further if anyone's interested. Moving forward as I write more articles, there should not be an issue, since I usually update only on or very soon after the publication date, so we should not expect to see wildly different dates on sequential articles from here on in.
  7. I realize I never updated about this, sorry. It was all OK in the end - I reached out to Ryan, and it just looked like something had slipped through the cracks - my submission was made around the time that they changed they layout of the PW site directory. It got added in fine after I resubmitted. Thanks all for the input!
  8. Thank you @szabesz - the thread you linked to was perfect, I don't know how I missed it in my search of the Processwire forums for the word "search" . Oops. Yes, my situation is a simple case of the one you linked to - just what I needed. Thank you @Robin S for the response here and in that thread - the info was very valuable. I've tried it out on my site and it's working perfectly!! Thank you both. Now I'm just trying to figure out how to use the Limit selector on the resultant array (for pagination). But thankfully the main thing is that now it's giving the results I want in the correct order.
  9. I've been trying to figure this out... It seems like I'm probably missing something really simple, but I'm still puzzled as to how to move forward with this. I'd appreciate any help or suggestions anyone can give. Aim: I'm trying to modify the default search template so that my search results come out sorted firstly with those which contain the search term in the title and secondly with those that contain it in the body. The basic code where I made sure everything was working first was: $selector = "title|body~=$q, template=BN-article|BN-infopage, sort=-published, limit=15"; // Find pages that match the selector $matches = $pages->find($selector); // did we find any matches? if($matches->count) { // yes we did $entries = $matches; include("./INC-main-blogroll-panels.html"); } It gave me the search results sorted by publication date, as I expected. Next I modified the first portion of the code by using the following to generate the matches as follows: $matchest = $pages->find("title~=$q, template=BN-article|BN-infopage"); $matchesb = $pages->find("body~=$q, template=BN-article|BN-infopage"); $entries = $matchest->and($matchesb); However, the problem is that $entries in my resultant displayed list did NOT start with those matches that were in the title first from $matchest. It seemed like $matchest->and($matchesb) sorted the resultant list its own way. This is even without the added complication of trying to use unique() afterward to remove duplicates - which appears to have its own default sort. Would anyone please point me in the right direction for what what I'm seeking to do? Thank you so much!
  10. In case anyone is researching this topic, I can attest that this works beautifully on a live site! It was such a smooth and painless process! I used Diogo's advice to go from Wordpress to Processwire on a site that I wanted to switch over. I had less than a minute or two downtime. Firstly, over a week or two, I built the Processwire version of the site in a subfolder (used a hard-to-guess-name) with the Wordpress version still running live in the root. Then when I was happy with the look of the Processwire version, I deleted the Wordpress installation via 1 click in Softaculous, which gets rid of the Wordpress database and the files, and leaves behind your own folders, like my staging subfolder containing the Processwire site. Then I just moved the contents of that staging subfolder up one level, into the document root. It renders just like it should. Done, and done. Thanks, diogo.
  11. Thanks so much @kongondoand @adrian for responding. So far, I'm in two minds between a) simply assuming my site didn't meet some criteria, or b) wondering if it's worth re-submitting the form in case it somehow slipped through the cracks during a busy holiday season and some big changes to the way the PW site directory is displayed, or in case I did something wrong in it. When I submitted the original form back in November 2018, it gave me some code to add to my site pages, and I did it, so at least that part went OK. For now, I'll just leave it alone. Maybe I'm just not doing anything unusual enough or different enough with the building of my site (to be included in the directory I mean) and I would certainly understand if that is the case. Thanks again everyone, and I very much appreciated the time taken for responses.
  12. Update Jan 2019: I'm a little puzzled as to why I don't see my site submission in the Processwire site directory yet. Maybe my site didn't satisfy some criteria?? Or does it take a long time between submitting the site to the PW site directory and it being added? I submitted my site to the directory back in November of 2018. If anyone can make a guess as to which of these issues is likely, please feel free to comment here. I'm a little puzzled.
  13. Here I'm writing up about my first ProcessWire site, Reached.space, a blog and directory about shops which offer international shipping. I'm from The GrayFly Group, which is the registered trade name for GrayFly Stationery, LLC, a limited liability company registered in the state of Kentucky, USA. You might ask, why is a stationery company creating websites?! Well, in a way both activities are very similar: both activities have the goal of getting written messages across in a pleasing manner to the reader. With that out of the way, let's move on and explain what went on behind the scenes of the Reached.space site: Template I used a free CSS-based template from W3CSS at https://www.w3schools.com/w3css/w3css_templates.asp , using mainly the "Architect" template as the basis and modifying it as needed. Pagination The pagination feature of ProcessWire was very helpful here; I kept the home page to just two blogroll articles so that the reader was not overwhelmed, but upon pressing "more articles" the remainder of the blogroll is paginated with 4 articles to a page. Screen reader I made adjustments to my usage of the template to make it screen-reader-friendly. I used the Google Chrome extension to test out how the site would be handled with a screen reader. Security Security is always important, so I was thrilled to find a great all-in-one-place security guide in the ProcessWire docs at https://processwire.com/docs/security/ - I simply went through the guide and did what it said, using it as a checklist. Modules As far as I'm aware, the only additional modules I used (that were not already activated by default in standard PW install) were the Upgrade and Upgrade Checker modules. The main reason for this was security considerations, but it was also an added convenience and peace of mind to have it check for updates every time I logged in. However, I did use additional software that was not modules, as described below. Other software - Simple HTML DOM Here I was very fortunate to receive help from the ProcessWire community on the forum. Due to the site's monetization model being affiliate marketing, I wished to make all my external links nofollow and target _blank by default. User @Robin S was instrumental in showing me how to do this using Simple HTML DOM in the forum post https://processwire.com/talk/topic/17295-solved-how-to-make-external-links-nofollow-and-target-_blank-by-default-if-using-source-code-toggle-in-editor/ Other software - Google Analytics cookie manager My site requirements for GDPR were specific enough that I felt I would rather develop my own code to handle Google Analytics tracking, which I'll describe here. I wanted to be certain GA tracking was disabled by default requiring opt-in, instead of opt-out. I also included in the Cookie Manager some written info about third party cookies (these are placed when clicking on affiliate links) and how the user can avoid such tracking (turn off third party cookies in their browser settings). I also disabled front-end PW cookies as described here: https://processwire.com/talk/topic/15270-session-storage-and-lifetime/ Google Analytics cookie settings The Google Analytics cookie setting code was done using JavaScript. I used a session storage variable to indicate whether the user had a) accepted GA tracking cookies b) declined them or c) had not made a choice yet. I also had to make some changes also to the <head> code to ensure Google Analytics cookies were not set unless the user had accepted them. Efficiency - optimizing 404s I used the guide at https://processwire.com/blog/posts/optimizing-404s-in-processwire/ to sinkhole bot-driven 404 requests to a static 404 file. Back office pic Below is an image of how ProcessWire allows helpful field descriptions and displays them when used in templates, so that when I come to actually use or enter content in fields I created months ago, I know what the ramifications are. Very helpful. Also, when using the back office I found the Reno admin theme to be very pleasing, efficient, and easy to use.
  14. Oooh awesome!! I can see how that would work but I would never have thought of it myself. Thanks @SamC! I really appreciate you trying that out. I'm leaning toward using markup regions now. One question, if anyone is willing to comment: using "markup regions" vs using "includes" - which of those two would you expect to be faster to render? And are there any conditions / caveats which favor one better than the other as far as speed alone is concerned? I know it said that markup regions can take a bit longer if you're outputting a lot of markup, but how do I know if I have a lot of markup? Also, wouldn't "includes" be considered an extra step just like "markup regions", so how do we know which one of these two would be faster for PW to render? I know there's most likely no hard-and-fast rule here, but I'm seeking some general thoughts about which conditions might favor one vs the other speed-wise.
  15. @bernhard - Thank you for your awesome example! Yes, Sam had posted a link to the 3.0.49 post, but it was good to also see the updated 3.0.62 version of markup regions. The thing that made a huge difference to me was your code example. Your sample code here was MUCH easier for me to understand as a newcomer than the examples given in both of the official markup regions posts. If there are any other newcomers who are thinking of using markup regions, I strongly recommend bernhard's earlier reply above. It allowed me to see more easily how this would indeed help solve the general problem of having common bits of code. The advantage over the "includes" method is that the main layout code is in one place. In other words, I could therefore edit header and footer for all pages from the same file ( _main.php in your example), and I can see layout at a glance. High readability and ease of editing. I see I could add to _main.php all possible region ID's used in all templates; only the ones used by the specific template in use will get populated. So, it's pretty tidy, and you can get a feel straight away for what sorts of things all of your templates are likely to be doing, just by looking at _main.php. The main disadvantage I see is that I'm not sure what I would do if I ever created a page template that (for example) I did not want to include a footer on. Sure, that's unlikely to happen, but I'm not sure how I'd handle that using markup regions if it occurred. I expect there must be a way to do that, it's just not obvious to me. @SamC thanks for updating and also for mentioning the methods you are using. It is really great for me to have all of this info here from everyone all in one place.
  • Create New...