wbmnfktr

This approach would and will work in ProcessWire as well. There is a video showing how it could be done. It's quite old but most of it is still the same today. ProcessWire and some dialogues look different now but it might be a good starting point. Depending on the design, functionalities, dynamic data and some other things one approach might be slightly better than another but each and every will work. It's important to know which parts of the site need to be translated, where to store those details and who will be in charge for maintaining that. Think about footer content, navigation and small things like that... those could be tricky at first in a multilanguage scenario. There is a great intro to multilanguage as well which can be found here: https://processwire.com/docs/multi-language-support/ and of course the support forum for all kinds of questions. My workflow is almost the same. I build the website in a static way to see all the details and later on move everything into ProcessWire. Looking back to my first projects... they were exactly like your situation here. This part could be a tricky one as well depending on what's going on there. You might end up with some custom functions, maybe even a module but in most cases even this should be quite easy. Oh... welcome to the forum and the world of ProcessWire.

Next step here would be to find out WHY this was disabled/commented out. The same for the slider that stopped working a while back. Both weren't something that ProcessWire changes on its own. So it either didn't work for a long time or someone is still changing things on your site. Just a thought!

Ok, that's a solid starting point. I found your other post in within the link to your site here. There is one JavaScript file that might be the problem here - but is just a guess for now. It's located here: yoursite.com/site/templates/js/scripts.js In this script is a part connected to the accordion and its function starting in line 201. //////////////// Accordions /* mr = (function (mr, $, window, document){ "use strict"; var documentReady = function($){ $('.accordion__title').on('click', function(){ var accordion = $(this).closest('.accordion'); var li = $(this).closest('li'); if(li.hasClass('active')){ li.removeClass('active'); }else{ if(accordion.hasClass('accordion--oneopen')){ var wasActive = accordion.find('li.active'); wasActive.removeClass('active'); li.addClass('active'); }else{ li.addClass('active'); } } }); $('.accordion').each(function(){ var accordion = $(this); var minHeight = accordion.outerHeight(true); accordion.css('min-height',minHeight); }); }; mr.accordions = { documentReady : documentReady }; mr.components.documentReady.push(documentReady); return mr; }(mr, jQuery, window, document)); */ As you might already see here the functionality is commented out and therefore disabled (see /* in line 202 and */ in line 236). That would be my starting point for further actions. I wouldn't suggest testing it within the real live website as other things could go wrong. Do you have a testing or development version of your website? Or maybe even better still contact to that agency?

Quoting questions from the other thread: What ProcessWire version are you using? Did you change something in the code just before the accordion stopped working? And some other questions: Who is maintaining that site? Wo built that site? Are you experienced in web development?

I assume that there is no content or anything else visible here http://mypsblog.tld/domains/ or http://mypsblog.tld/. Is this correct? If this is your current setup you have to check your domain settings within your hosting. You have to define a new web root (starting point) to tell where your website really starts.

Maybe a bit off-topic but still interesting (for Linux users at least)

How did you migrate the site? Did you copy all files over and imported a DB dump? If so... try the Duplicator Module as it exports each and every asset you might need into an installer. There are some errors in the console which are... weird... and therefore out of my knowledge. You might also check the following things: delete all compiled files from modules via admin interface or... delete ProCache cache if ProCache is used delete cached parts of the site (/site/assets/cache/) use only the PW version the site was already reading use PHP 7.4 (for newer PW instances) In addition to the above you might give us some more details about: What modules is the site using? Which version of PW? Which version of PHP? Which version of MySQL/MariaDB? Do you still have access to the old version of the site? Could you switch back and create a staging environment for the new site?

Can you outline the desired and working HTML output you would need in your case? Maybe not only the current item but a whole pagination block. That way it would be much easier for us (at leat me) to know and understand exactly where to look. And... what about writing your own little CSS snippet for that case?

Ok... so you are already deeper into ProcessWire than I previously thought. And yes... upgrading an existing project or site can be quite painful - at least when there is a ton of content.

No matter if multi-site or multi-instance you should not only read and think about possibilities here, you actually should really build out at least one test setup for each of both options. Did this last year with the multi-site approach and found things I had to iron out I never thought before. You can do this locally with either MAMP, XAMP or any other LAMP stack and local domains. Keep those local domains close to the real ones. I have to look it up but there was one thing that didn't work well with the real domains later on but with my test domains. Hope I can find those older posts and will paste them here.

I had very very similar entries in my logs on not that cheap hosting providers over in Switzerland and here in Germany ... I can't remember all the details but the end-result was... their database servers where more crowded than any Walmart on a Black Friday. Those servers were packed with users that even minimal resources couldn't be applied to each and every client. I hesitate to say your hosting provider is [not that good] but for me it looks the database server is lower spec than a Raspberry Zero. Or at least connections to it, memory and maybe even disc space or whatever is insufficient. There is a very huge company (EIG) out there, that buys small, medium and large hosting companies just in order to milk them. Similar to Hostgator and others. Maybe that's the case here too. https://www.shoutmeloud.com/hostgator-sold-endurance-endurance-group.html

Your provider isn't blocking anything at this point. Editing the files is quite easy. download the module from either processwire.com/modules or the Github page extract the ZIP file to your local machine open up the module files in VS Code or whatever tool you are using add the namespace upload the module try again

Just installed the module BUT I had to add the ProcessWire namespace to the module files. My overall setup is exacyly like yours (3.0.165, 7,4, 2.3.3)

Try this... Enable $config->debug in /site/config.php FieldtypePageTable (or how it is called) is installed? I guess but better check this. Check if the module has the ProcessWire namespace in it. Maybe that's an issue here. If you are running PHP 8 maybe try PHP 7.4 instead. Use the latest stable version of ProcessWire

Yet another style but at least super comfortable while working: JustMyFavStrangeMusic: https://www.youtube.com/channel/UC3svqWpPzbHghQPT36HAldg

Electro... Techno... Mixes... Even more mixes and sets: ElectroJunkiee https://www.youtube.com/c/ElectroJunkiee/videos FearNLoathing https://www.youtube.com/c/FearNLoathing/videos Those who know about youtube-dl... get those mixes!

I played around with a fresh install of ProcessWire and tried to replicate your issue. There are a few things I found: the select/option ID needs to be unique (obviously) the select/option value can be the same between different options the select/option title needs to be unique as well While this works: 1=0305|Håbo kommun 114 A 2=0305|Håbo kommun 114 B 3=0305|Håbo kommun 114 C This doesn't: 1=0305|Håbo kommun 114 2=0306|Håbo kommun 114 3=0307|Håbo kommun 114 See the differences there? So... the easiest explanation would be that there at least one other entry with the same title. My testing setup looks like this: If you like drop me a PM and send me the list of all counties you have and I'll test it here.

Two thoughts here: Just in case... ask your hosting company if there are any security measures in place that may slow down external connections on purpose. I know at least two companies that route external access to databases through such a small bottle neck that it becomes almost unusable. Add the remote database server's IP to your local hosts file to remove at least DNS lookups and maybe even some routing issues. That helped me a while back when using DreamHost. Still slow-ish but at least usable.

Kerim Pamuk https://www.kerimpamuk.de/ Client details Kerim Pamuk a turkish/german author and cabaret artist with such a kind of detailed humor for details you have to listen very closely and think twice to really appreciate his Wortspiele (en: puns) and anecdotes. Some more details about Kerim Pamuk (one of our first clients with a personal Wikipedia page): https://de.wikipedia.org/wiki/Kerim_Pamuk Design details As you can see... Bright colors, big typo, and subtle animations to emphasize the already bold visual statement. No miss but a lot of hits wherever you watch, like the stage program performed by Kerim Pamuk himself. The original design and the entire frontend were built in Webflow by the designer but was migrated over to ProcessWire later on. Some tweaks were made during the migration process to keep things a bit more flexible and easier to maintain on the long run. Technical details There is not that much in the backend to show or tell. Only a few tweaks and hooks in order to maintain all events automatically. Adding additional press statements, books or any other kind of content is simple and straightforward as always in ProcessWire. Modules used: Cookie Management Banner: for the obvious reason FieldtypeColor: for custom colors on sub-pages if needed PageHitCounter: as alternative to Google Analytics and Matomo ImportPagesfromCSV: importing new events to the site with ease (maintained by the client) Markup Sitemap XML: you know why Jumplinks: in case things change or someone needs a nice pretty link ProCache (Pro): ProcessWire is fast - with ProCache even faster VerifiedURL (Pro): to keep track of all linked event locations The team behind this: Muskaat for the technical part (yes, I'm part of Muskaat) https://www.muskaat.de/ Polimorf for the design part https://www.polimorf.de/ I hope you'll enjoy this site as much as I do!

The $page->created is empty at that very moment you query it because it hasn't been set yet. <?php namespace ProcessWire; $timestamp = time(); $page->setOutputFormatting(false); $page->created = $timestamp; // that quiet=true part is important in this case $page->save(array('quiet' => true)); You could add the date on your own if the date is necessary for whatever reason in that moment.

In case you are using tools like Xenu, Screamingfrog and some others you might want to remove those from the lists.

Awesome! My sunday is saved with some new fun I never really got into.

<?php foreach($page->heroimage as $image): ?> <li> <img src="<?php echo $image->url; ?>" alt="<?php echo $image->description; ?>"> </li> <?php endforeach; ?> You might want to try this instead. In your foreach() the $image has to be adressed and not the $page->image. And also the <li> should probably be in there too.

Just played around with UTF8 page names here in a local setup and it throws 404s here as well. Can't really say why as I rarely use that feature. I might have to dig a little deeper into this.

In order to have UTF8 support in URLs you have to define a whitelist as well. See here: https://processwire.com/blog/posts/page-name-charset-utf8/ With "social chars" you mean Umlaute? I guess... so you can have those either with the UTF8 page name support or you transform the classics like ä,ö,ü, and ß to ae, oe, ue, ans ss within the page name settings. You will find it here: domain.tld/processwire/module/edit?name=InputfieldPageName