SiNNuT

I want to mention that i don't mean to sound harsh. I just have some concerns about the emptiness of the first part of the page and the usability of this kind of 'fake page' effect design. PS i see that you use flexboxgrid? How is that working out? I thinking about redoing a site making use of flexbox but i'm not sure yet that i can skip IE<10 support.

I like it visually but i'm always a bit torn about such 'empty' first screens. Why do i need to start scrolling or clicking/tapping before i get an idea of what the site is about? Isn't the function of a brochure site of sites to inform the visitor, and do this as quickly as possible? I see this kind of design quite a lot lately but i wouldn't be surprised if it was actually harmful for user engagement. In a sense it reminds me of the (flash) intro pages of the olden days with a 'click here to enter the site' message. Bad practice. But maybe it's just me. When you go to the About Foundry part of the page via the downwards arrow click you have no visual clue that there is additional content beneath it. The only clue is the scroll bar but that is easily overlooked.

Probably, otherwise there would be no reason for the code to slow things down. It should be noted that this code should only be run after one has created a bunch of multilang pages from the API.

If you have some variation of https://processwire-recipes.com/recipes/activate-all-languages/ running in ready.php, i could certainly see how this could slow things down as the content grows. It's also not meant to be used that way, but maybe i've misunderstood.

You can also keep an eye on https://processwire.com/talk/topic/10929-developer-centric-form-processor/ (still in Alpha) I haven't had a chance to use it but it seems very promising.

1 Enable/install Reno, under modules->core->admin 2 Go to your user profile and select Reno for the Admin Theme setting Yes, Reno is the profile in use on the demo. The Admin Theme setting is on a per user basis.

PW normally is faster than most CMSs i've dealt with. In my experience, when things are unresponsive this is caused by factors outside of PW itself. I don't know your local environment but some things you could try are: Open the file site/config.php, lookup the dbhost setting and change as follows: $config->dbHost = '127.0.0.1'; //instead of localhost I have not been able to figure this out exactly, but on Windows (>8) machines, letting PHP connect to your database via localhost is very slow. On my own machine if i use localhost i get 2-4 seconds of unresponsiveness. When i use 127.0.0.1 everything is back to its normal snappy self. If you're on Windows here is some more info and things you can try if the above didn't help http://stackoverflow.com/questions/8432601/wamp-xampp-is-responding-very-slow-over-localhost Another thing you can try is opening your PHP configuration file and comment out everything XDEBUG related. Xdebug is known for slowing things down because even when you are not using it to debug things it does collect a lot of data for its stack trace stuff. As an example, here's the stuff i've commented out in my PHP ini file: [xdebug] ;zend_extension=${US_ROOTF}/core/php56/extensions/php_xdebug.dll ;xdebug.remote_autostart=on ;xdebug.remote_enable=on ;xdebug.remote_host=127.0.0.1 ;xdebug.remote_port=9000 ;xdebug.remote_handler=dbgp ;xdebug.remote_mode=req ;xdebug.idekey=default As for your live host, 'acceptable' does not sound that great. PW should run great on most hosts.

I'm not gonna be spending this kind of money but dang, the Surface Book seems like a fine piece of equipment!

It depends a bit on the type of site, it's target audience en what you are looking for in a webhost. Specific to a country or international? (managed)VPS or just shared hosting? In my experience PW runs fine on every decent host. If you tell a little bit more i'm sure you'll get some recommendations.

I don't think anyone would disagree with that but that's not what cssabc123 expressed in his post, which actually started with "Drupal is better than PW". Of course each is entitled to his/her own opinion, no problem, but when almost all of ones forum activity up until now consists of subtle or less than subtle trolling attempts there will be a time when people are fed up with it. Especially when there are no apparent signs of actually having tried PW, read some docs etc.

Quite frankly, i am starting to get annoyed with your posts. I get the impression that all you do is start threads, or digg up old ones, with the sole intention of trolling around. I suggest you stop this.

Maybe a bit late but locking this thread down because it has gotten to the stage where it doesn't contribute anything worthwhile and it's just silly and all over the place.

It's not so much 'troubles', just something to be aware of. Incidentally Ryan has a quite nice write-up about pagination (and some other stuff) in this weeks blog post. https://processwire.com/blog/posts/processwire-2.6.18-updates-pagination-and-seo/

I don't think ImportPagesCSV supports this, but it wouldn't be hard to run some code afterwards via the API: https://processwire-recipes.com/recipes/activate-all-languages/ (adjust to your needs) edit: beaten by LostKobrakai

"The data for the shoes are imported from their system va CSV." If the structure is right and the csv(s) fit nicely that is not necessarily the case. It could even be automated quite a bit.

Maybe Teppo's article can help: http://www.flamingruby.com/blog/taking-apart-a-simple-textformatter-module/ It's from 2013 but it still is all valid i think.

Cool stuff

Have you also cleared the browser cache of the browsers you are checking this with? Small chance but sometimes some old stuff sticks around (js/css).

Uh, Pete, Chrome/FF/IE inspectors aren't hindered one bit by minified html? And prolly a lot of other tools. /Edit, sorry you already mentioned it

My googling led to the zlib compression solution as well. Not sure as the why, but probably it has got something to do with fastcgi and/or config.

Running out of ideas here. Have you tried removing the <IfModule mod_deflate.c> and </IfModule> lines and see what that gives? Check the Apache error log. On a side note: you should check the h5bp Apache server config for a more complete/up to date deflate stuff https://github.com/h5bp/server-configs-apache

Have you checked that mod_deflate is actually enabled? Another possibility is that Apache is running behind a nginx frontend. When this is the case your hosting provider needs to configure nginx to do gzip compression.

Easy answer: PW uses the MyISAM storage engine, which does not support foreign key constraints. InnoDB could be considered at some point because it has some benefits and also full text search for a while now. But to my knowledge MyISAM still outperforms InnoDB in some areas and there are more things to consider.

I also recently ran into this problem on a live site on Unix where i wanted to do a quick edit. I think this was the first time trying to edit translations on the live site, and encountered the wrong paths. Because there where only a few translatable strings i deleted the translation and re-translated it on the live site, which then works correctly with a good path. It was developed on a Windows machine so i think there is some kind of directory separator issue.

Yep, noticed it on the latest blogpost as well. Refresh and all is fine.