• Content count

  • Joined

  • Last visited

Community Reputation

42 Excellent

About wbmnfktr

  • Rank
    Jr. Member

Recent Profile Visitors

603 profile views
  1. Would you mind to share your White Paper with us? Non-public or with a NDA (kind of)? It sounds interesting as a 10-pager should/might be very promising. I'd like to share my insights and arguments as well - if someone is interested.
  2. Tweak the backend with your client's brand colors, their logo and a nice favicon. BOOM... they will feel like home.
  3. That makes life a bit easier as it doesn't necessarily need critical business logic as validation, calculation, payments or whatever. Data structure My personal preference would be a data structure that consists of branches for countries, regions, years and other repetitive data that will later be referenced in each wine. And a branch with all wines. Combined with modules like PageFieldPairs or Connect Page Fields you could easily sync those datasets and references from one page to another. But every other structure might work here as well. It's a personal preference thing here. Update: You should use a more unique ID for each wine than the PW page ID. The SKU or EAN or whatever the data source can deliver. This can make updates easier in the future. Data sync This depends. How often new wines will arrive? How often a wine needs to be removed? How often details will change? What will change? Do details need attention (for example: price formatting)? A manual CSV update might work well, but JSON makes things easier sometimes. Maybe I can find something about structure and sync in my files and projects that I can post here.
  4. Before going deeper into possible ways and solutions on data-handling... What else is needed or planned for this? Will the final result be an online shop (with all kinds of shop functionality) or just a catalogue for potential buyers?
  5. Just some more thoughts on this topic I just asked myself Why would someone use Drupal or Typo3 and therefore read what they write on their sites. https://www.drupal.com/product/web-content-management https://www.drupal.com/product/commerce https://typo3.com/about-typo3/why-typo3-cms/ The shocking truth is that they don't say anything new at all. Some arguments are valid, some are BUZZword Bingo but almost all of them match perfectly well with ProcessWire, too. If we wanted to create a huge list of arguments for ProcessWire we can find a lot of material out there in the interwebs. Can ProcessWire compete with Drupal or Typo3? I think we all know the answer. Next step Who uses Drupal or Typo3. http://www.typo3-websites.eu/en/typo3-cms/typo3-references/commercial-enterprises/ https://www.drupal.com/showcases This is way more interesting to look at. Big companies, big budgets and big agencies. Absolutely well designed sites well presented. Drupal plays the showcase-game very well. Every site gets a lot of attention. Not only a screenshot, a link to the website, a link to the creator and a few links to modules. Everything is a case study. Browsing the list of sites is a really nice experience and makes me want to try Drupal and built awesome sites. Could this be done with ProcessWire sites as well? Absolutely. Should we invest more time in presenting sites and projects? You guess it.
  6. Had to play around with it and it works like a charm. Thank you @Kiwi Chris for sharing this. This will come in handy for smaller sites or prototypes. What I really like is that saving pages from the submitted form doesn't need an extra step as it does in FormBuilder. The created template is already the form and the template for the pages.
  7. I really like the idea and the direction this article takes but there is one thing that ... has some kind of aftertaste. You are writing ProcessWire ist sicher (ProcessWire is safe) and telling people that there are no documented security issues but linking out to a page that tells something different - at first people will only see: Github ... ProcessWire... Issues... Security... security... security... I know about PWs high level of security but even I had to take a much closer look at those issues. Your audience could get this horribly wrong without further explanations as they will not dive deeper into those issues.
  8. These are the Bypass options ProCache provides. Hope this helps in any kind.
  9. Just stumbled across these (marked in the screenshot)... you might want to fix them and the og:image/twitter:image:src paths. But yes... as @DaveP mentioned: super clean code and clean site.
  10. Instead of loaders: skeletons Like Facebook and even this forum does for embedded content like the preview above.
  11. _init,php isn't a regular template file. It's more kind of a universal settings file with variables and presets you might need later on your page(s). So you could add the following line to site/config.php $config->prependTemplateFile = '_init.php'; The _init.php in /site/templates/ will be included every page load and therefore the login check is always in place. Within this file you could and should add psy's / your code <?php $loginPage = $pages->get('template=loginregister'); // in my case yours might be different if(!$user->isLoggedin() && $page->id!=$loginPage->id) { // checks if user is logged in and not on login page $session->set('returnPage', '/path/to/welcome/'); // set your welcome site $session->redirect($loginPage->httpUrl); die; }; This would redirect every user that is not logged in to your login page and sets the returnPage. Be careful with the check conditions. You might want to fine tune this check.
  12. Have a look at this post: @psy's code does almost exactly that what you need/want. At least you get the idea and can adjust it to your needs.
  13. The frontend looks nice and clean but what caught my attention was the backend. We see lots and lots of frontend but this one is a nice look behind the scenes. I love it! Would be interesting to see or know more about this and some other backend solutions.
  14. @AndZyk MapMarker is a nice module and does most of the things most people want. But there is still some overhead if you build and use your own Google Maps with custom scripts and markup. All @suntrop does and probably needs is grabbing lat/long from Google and saving it to text fields. A super lightweight solution btw. I played around with Profields: Textareas and the lat/long script. Still everything is fine. With and without language support and german language pack.
  15. None of my text fields or textarea fields convert 50.43578373748 to 50,43578373748. Can you explain your field setup a bit more detailed as your description sounds kind of weird to me right now.