wbmnfktr

First of all check if the site is still accessible and visible in another browser and afterwards if those existing URL segments are the reason why the page is still visible. You can look into the details within the template and obviously in the template file itself.

Probably... Browser cache Template cache ProCache Less likely... custom behaviour via hook url segment Try another browser and double check that the site really is unpublished.

Wow... had this bug years back. Must have been one of my very first posts here. Nontheless... it's either the global or autojoin flag (can't remember it anymore) in the advanced settings tab for the title field that is somehow the reason for this. But yes, adding another language solves the problem as well.

Maybe it's a temporary solution. It almost looks like it. Let's see what happens and how it might change for the better.

So... you didn't activate or use any kind of cache? Then @ricks solution might work for you. Another thing... are you using Opera? That thing annoys me with cache issues each and every time I use it.

Tricky means in this case: I don't know anything about your actual PHP and there might minor things to fix. For example: if you enable caching later on and depending on what kind of caching (for example ProCache)... your PHP might never get called as ProCache bypasses PHP after a cache file was created. So... a really static website? Ok. Fine... ProcessWire will be perfect even for this. Maybe even way better than PerchCMS and others as you always can add up functionality with ease - even super dynamic stuff. This will be super easy! The way @elabx describes it, it should work pretty well. My pleasure.

What kind of cache are you running? Template Cache ProCache WireCache In my opinion caching should be disabled during heavy development. Activate it for testing purposes only. ProCache and Template Cache are both capable of such kind of caching you described. Even custom WireCache if done right/wrong. So... yes, it's normal in most cases. For testing any development progress you should be logged into ProcessWire admin to have an active session - makes life much easier at least in the frontend.

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.