wbmnfktr

Found that post from @ryan a while back about this "custom backend styles/theme" topic: https://processwire.com/blog/posts/processwire-3.0.54-and-adminthemeuikit/ Maybe this is a good starting point.

<?php // ... $portfolio_pages = $pages->get->projects; Looks suspicious to me. What's that ->projects part?

Images can stored very well in an image field. Enable/use tagging within that image field, place it in your settings template and your done. Add as much images you want or need and depending on its purpose add a tag like logo, frame, background to that specific image. https://processwire.com/api/fieldtypes/images/#image_tags I used it in one project and the maintainer (client) used this ever since and was comfortable with that way. This might not work in your case but at least there is a way to use one field for images and using them in different places. Regarding the module, that you already have, you can set up those specific fields in that module too. Users just have to edit the module settings then. Don't know what's more comfortable in your project.

Just guesses and thoughts but... Do you use one of the ProcessWire site profiles or did you build something on your own? Which modules do you use? Did you place custom files within the /wire folder or changed files in there? Did you change the original /index.php or /.htaccess files? Most of the time something like that happens to one of my sites I walk this way... 1. Turn on debug mode /site/config.php <?php //... $config->debug = true; Maybe this already helps or shows more details about that error. 2. Refresh modules & clear compiled module files http://yourdomain.tld/processwire/module/ a) top right corner b) bottom left corner on Site tab 3. Delete other caches ProCache, Template Cache, Markup Cache, whatever server/pw-side cache. 4. Looking into your page template Investigate your code that should have been displayed where the error message starts. Maybe... there is something.

Exactly. It's similar to your solution but with a page reference field for your links and therefore more structured and future-proof. But it won't be automatically accessible. Therefore your page needs a real template.php which isn't needed at all. Second part could be that you hide that page in the settings.

A settings template is just as any other template. The name doesn't matter as long as you remember it for later use. What I missed to tell was that you have to create a page with that field as well. I often use that page with the template as a container/place for all kinds of custom settings then. You could place your footer-menu field in your home template that doesn't matter. Placing that field and other custom settings on a dedicated page can make your life much easier as you could build something like this. <?php // get your settings page $settings = $pages->get('template=settings'); // get your footer links $footerMenu = $settings->footerMenuField; // render the output somewhere foreach($footerMenu as $footerlink) { // ... your code here }

There are many other ways... just a few examples here. 1. Module Menu Builder by @kongondo Create a footer-menu in module add pages or custom links render on the frontend https://modules.processwire.com/modules/process-menu-builder/ 2. Custom page reference field Create a settings template create a footer-menu field (type: page reference) edit settings matching your needs (for example: only certain templates) add field to template add pages to field render on the frontend 3. Static links Just add plain / good old static links to the sites you want to appear there

headless Just a little game and play with words here. headless = kopf·los [/kópflos/] which translates in german to due to confusion, surprise or similar unable to think clearly, to act meaningfully ProcessWire is (no doubt) very well planned and executed and therefore absolutely not kopf·los. Which could be used and translated to something like: Headless without confussion [in marketing language] Comparisons Regarding comparisons... they work well in tables with key features like themes, templates, user management, priviliges, workflow, etc. Something like this on satellite.me - a small competitor compares itself with the biggest players. Other CMS sites As @Robin S already mentioned other CMS sites here have a look at typo3.org and typo3.com as well. Or something very exclusive like inxire.com (kind of a unicorn - but still with a very dull website). They are the... let's say biggest and most known CMS in their field and are kind of milestones. Alone the inxire clients tell a story.

Well... I'm excited to see Ryan's work (new processwire.com) that showcases what he created in the last years (ProcessWire). I'm excited to see how and what Ryan has built in the last weeks. If there is real need to fix something, we'll fix it. If there are ideas worth discussing, we'll do so. Ryan built several websites in the past. I guess he knew what he did. Always remember: release early, release often. (like PW Dev Branch)

It's not that I don't trust people but... I'd be careful with things like that. First off all most people just take code they get from whoever and place it somewhere without knowing what will happen afterwards. If there are tools and services like Facebook Pixel, HubSpot or similar they want to use, give them the option to enter only the necessary details like Pixel ID or campaign ID and let your system do the rest. Maybe you can ask your users what they want to add to their landingpages and start from there. In my opinion that's much safer and easier for everyone. If it was my service I wouldn't allow them more than that. At the end I'm the one that risks everything.

Yes... no... maybe... most of my PW sites are in german, so if I get this wrong, it's my fault. Otherwise I missed a thought. ? But yes, it would be nice to set a "real default" language in PW and therefore a PW-wise session/redirect. Nontheless this snippet saves me most of the time if I miss-configured something. Hope this helps in your case.

I used this way very often in the past @benbyf <?php // create /site/modules/LanguageDefault // create file LanguageDefault.module // refresh modules in PW admin // https://processwire-recipes.com/recipes/change-homepages-default-language/ class LanguageDefault extends WireData implements Module { /** * getModuleInfo is a module required by all modules to tell ProcessWire about them * * @return array * */ public static function getModuleInfo() { return array( 'title' => 'LanguageDefault', 'version' => 1, 'summary' => 'A work around to changing the default language.', 'href' => 'https://processwire.com/talk/topic/9322-change-default-language-for-homepage/?p=89717', 'singular' => true, 'autoload' => true, ); } /** * Initialize the module * * ProcessWire calls this when the module is loaded. For 'autoload' modules, this will be called * when ProcessWire's API is ready. As a result, this is a good place to attach hooks. * */ public function init() { $this->session->addHookBefore('redirect', $this, 'setDefaultLanguage'); } public function setDefaultLanguage($event) { if ($this->page->id == 1 && $event->arguments(0) == $this->page->localUrl('default')) { $event->arguments(0, $this->page->localUrl('de')); } } } Found at: https://processwire-recipes.com/recipes/change-homepages-default-language/

I have had similar event-situations in the past and went different ways. Solution 1: I added a date_end (to keep your naming) field to my events and displayed an additional "from/ab (german: from)" to the event itself when listed somewhere - so no repeaters needed (in my case). It's almost like a date range for a single event. Works really well and can be found at: https://www.musikschule-neumuenster.de/termine/ Solution 2: I created one main page for that event and used @psy's recurring events module to create follow-up pages/events I can show in my lists. In your case I'd probably go with solution 2. That way you can although create semantic JSON+LD markup for each day/event if wanted.

Ah... okay. Sorry got that wrong.

Maybe this is interesting as well: Multi-site: https://processwire.com/api/modules/multi-site-support/ Multi-instance: https://processwire.com/blog/posts/multi-instance-pw3/ Depending on your needs, existing sites and setups this could become handy.

L'Chaim! Zum Wohle! Cheers!

Have a look at your console in Chrome or Firefox. There should be more details telling you what the problem is. I have had a similiar issue due to a missing setting in Google API Console.

Have you ever heard of citations in Local SEO? It's almost the same with plain text domains and URLs. They aren't as powerful as nofollow or dofollow links (and all their flavours) but they will work. Mentioning a domain or brand name will give some kind of signal to Google (and some others). It's the same with press-release spam and how it works combined with some more reliable and trusted methods. To answer your question: no, it's not that easy for black-/grey-/bluehat people. They do much more than just that. There are much more effective things that work way better and are sometimes as easy as press-releases or mentioning a domain. I guarantee you that a few hundred mentions of your domain spread across the internet can help your rankings. The more trusted the place (a PW forum for example) the better. If you want to challenge yourself get a copy of GSA Search Engine Ranker or Scrapebox, some proxies, a few domains and play around.

Doesn't matter. Even in plain text Google would see something like a citation and therefore thinks "Hey, they talk about www.whatever.tld so let's count it in.".

@Pixrael you should remove the link to that SC*M/SP*M site. Or do you want to support that kind of business? ?

Kind of similar as in providing snippets. The main focus will be different and will include solutions for often used scripts like OwlCarousel and modules as well. I want to show how certain thinks can be done in/with ProcessWire.

I guess... we all love and use 3rd party scripts, tools, services and modules for our ProcessWire projects. From image galleries to contact forms and newsletter subscription services lot's of things are already there and ready for use. So I am looking for your most common used and trusted scripts, tools, services and modules. You may ask yourself why I want to know this and before hiding everything behind curtains here is the answer: I plan to create a collection of ready to use ProcessWire snippets for common and often used scripts, tools, services and modules. Therefore I'd like to know what you use for your projects so I can create those ready-to-use snippets. I already have a broad collection of snippets I use everytime but I think there could be much much more. For example: I like to use Owl Carousel 2 and Slick slider for image galleries and/or sliders and Mailchimp as a newsletter subscription service. The main goal is that I want to provide working solutions and answers for ProcessWire starters. More and more questions in the forums are 3rd party related (How do I use this gallery script in PW? or How does this service could be used in PW?) and for those I want to create a copy&paste / ready-to-use collection of snippets. So... I ask you to tell me your most used scripts, tools, services and modules. Feel free to share your trusted 3rd party options with me. P.S.: I don't ask you for your snippets and solutions as they are your business secret and someone already paid you for it. But... if you want to share your scripts with me and the public you are more than welcome. P.S. 2: Modules will be part of this collection Things, thoughts and details about my project so far: Idea: born Domain: registered Hosting: paid / sponsored Scripts: in progress Tools: in progress Services: in progress Modules: in progress Free, premium, freemium: free (no ads, no tracking, no affiliate links) Authors: you & me (full credits given to you) Ideas, thoughts, questions, answers? Let me know!

auto-accept is like a silent opt-in until someone decides to block cookies. auto-accept doesn't hide the cookie banner at all. Without auto-accept and without user consent (allow cookies) you couldn't trigger analytics or anything else. That's fine, too. Visitors have a chance to opt-out. Their very first visit will not trigger any analytics or third-party cookies as they aren't at that point. When you deal with Google Analytics, Adsense or affiliate/marketing cookies this possibility and settings are nice little helpers.

I don't want to show the banner. That's the point. auto-accept mode + allow user to manage + user blocks cookies = banner does show up auto-accept mode + allow user to manage + added line to .js + user blocks cookies = banner does not show up

The negative viewCount becomes relevant (at least in my case) at this point around line ~257: // if they haven't explicitly accepted it (ie: auto-accept) then display the banner if (pwcmb_settings.auto_accept && cookieMonster.cfg.viewCount != -1) { cookieMonster.ui.show(); } I don't know if it's really necessary for you to get your head around it - at this point. Maybe in the future. To be honest... I think my actual case seems to be kind of special.