SiNNuT

Hi there and welcome to the forums. I'm a little short in time right now so i won't go into specifics about search with dropdowns. Some general info: - I don't think that there is a dedicated page on this site detailing the security(features) of PW but you can be assured that it is excellent security-wise. A strong password mechanism, session fingerprinting and a lot more. I haven't heard of PW installs being hacked or otherwise compromised. - PW can be an excellent way to get acquainted with PHP (programming). Some basic PHP combined with some PW API 'magic' will enable you to become productive in a short period of time. Of course, if your serious about learning PHP it will require some effort to learn a language and general concepts of programming. - The best advice i can give is just install PW and do some tutorials that are on the wiki. Once it all starts to make sense definitely read through the API documentation on the site. - Also, browse the forums. A lot of great info can be found, although admittedly sometimes a bit hard to find. Post like this could be interesting for you

Peter, i think you are missing something because that module in essence allows for exactly what you are after. You can define shortcodes for basically any combination of html/php/js you wish. The whole power of raw php and PW API is at your fingertips. After you have defined your shortcodes they can be used in any text field in the PW admin, including tinymce/ckeditor fields just by using [tagnamehere] . An example from Nico: <?php //Template code $shortcode = $modules->get('MarkupShortcodes'); $shortcode->add('config.urls.root', function($atts){ return $config->urls->root; }); $shortcode->add('config.urls.templates', function($atts){ return $config->urls->templates; }); $shortcode->add('url', function($atts){ return $page->url; }); $shortcode->add('id', function($atts){ return $page->id; }); echo $shortcode->render($page->body); //end template code. // the shortcodes can then be used in a textarea/tinymce (in this case the body field) with [config.urls.root] , [url] etc. ?> Read carefully through this http://processwire.com/talk/topic/1819-markupshortcodes/ , you'll get the hang of it.

Or look in the status bar while hovering a page edit link, this can be quicker diogo - resident forum ninja - strikes, once again

I don't think wappalyzer claims to be 100% correct, but if we take a vanilla installation of PW i think the combination of things above is enough reason to assume something is PW. The fact that you could quite easily make some customisations so that it can't be detected doesn't invalidate the wappalyzer tool (not that i particulary like it though). I'm thinking of adding <meta name="generator" content="Joomla! - Open Source Content Management - Version 3.0.0" /> to my templates just to throw them off.

A straight up export->import of database dumps from dev to live seems like a disaster waiting to happen. Definitely read this: http://processwire.com/talk/topic/1284-best-practice-for-staging-to-live-database-synchronization/#entry12752 I would also look into some tools that aid in comparing and syncing. Did some Googling: http://blog.webyog.com/2012/10/16/so-how-do-you-sync-your-database-schema/ http://stackoverflow.com/questions/225772/compare-two-mysql-databases http://blog.webyog.com/2012/10/23/all-you-wanted-to-know-about-sqlyogs-schema-comparison-tool/ http://www.red-gate.com/products/sql-development/sql-compare/screenshots http://www.quest.com/toad-for-mysql/

Bah, this EU Cookie directive and corresponding implementations in national laws are an abomination. I honestly think it has done more harm than good. Annoying the hell out of people leading to blindly accept any popup that mentions the word cookie.

Wappalyzer has a pretty impressive list of stuff they can detect. I think they are pretty smart about it. In addition to the suggestions of apeisa and krems04 i think they could probably do something with the http headers. PW's cookies always (or most of the times?) seem to start with 'wire=' , which seems like a pretty unique indicator. Not entirely sure about this though.

-edit: i hate this forum, every time you take a second too long to come up with a reply someone else steps in and beats you to it - Look at it this way, you will have to create the fields for holding *any kind of data* anyway. I don't think there will be a lot of overhead in adding all the fields to one template. From a UI perspective look at FieldsetTabOpen: You could just have your 'title, body, images' on the main content tab. Additional fields for Reviews and/or Graphics can be put on 1 or multiple other 'tab(s)' in the user interface. It's an easily overlooked feature but very useful: in 95% of page creations you won't visually be bothered by fields that are on other tabs.

-What exactly is going into the $langpath variable? It's a long-shot but could the path given to $pages->get be somehow compromised? -What database queries are getting performed? Any joining or other cross-table/column operation can give problems when the collations don't match.. I'm no expert in interpreting (PW) exceptions but http://somedomain.fr/?/ just seems strange to me. Not sure if relevant to the problem but couldn't all tables and columns have the same collation?

I'm not aware of any ready made modules that do exactly what you need but the placeholder creation part seems pretty straightforward. Some searching reveals this and this. Might be helpful. Part 2, the skipping of name creation technically doesn't seem possible, because every page needs this. I guess you could make it so that 'name' is automatically/under water, populated by an id value. I'm not sure that a page id is already available before a page is first created though. Don't know how to tackle this.

Why would you want to do that? During installation you can choose your desired admin name an password. After that the pass is getting hashed and salted and stored in the db. You shouldn't put stuff like that in a config file (if it's even possible).

Ouch! This almost rivals http://www.theworldsworstwebsiteever.com/

There's nothing like waking up to some of these yoda-like pearls of wisdom..thx Willy

... I think the forking and merging concept is a great approach that can be extended to various areas of life other than only coding. ... If only you could fork (certain parts) of someone else's life....now that would be great

Matthew, a framework like Laravel is mostly based on the concept of routing. This is really an almost completely blank canvas. The routes describe what happens at specific points, this can be controller actions but something completely else just as well. Out of the box controllers say nothing about url's. You structure 'your' application from the ground up. PW on the other hand already is an application (a CMS/CMF) so a lot of choices have already been made. It's a very flexible app so you can override most of the behaviours but i'm not sure what you mean when you mention a ProcessWire controller.

Something like that would be fine. If i understand correctly you want clients who create a page to be able to choose some predefined options for the way the content is displayed on the front-end. I think you envision about the same but anyway: Create a template called 'layouts'. This is only a container so only the title field needed and no template file. Create a template called 'layout'. This is only for other pages to reference, so only the title field needed and no template file. Create a page with template 'layouts'. Title can be anything, but layouts would probably make sense. Create children pages with template 'layout' for each layout you want. Fill in some descriptive titles: 2 Columns, 3 Columns, 5 Columns Add a page reference field to each template you'd like to add layout choices to. The parent setting to 'layouts'. Call the field 'layout' or whatever works for the clients. Now everytime a user who creates a page based on a template that has the page reference field, they can select wich layout they want. On the corresponding templates files you can use $page->layout to choose the file to include. About template vs template file: We've had discussions about this before but i must say i think that once you've taken a couple of moments to work with the system it's really quite obvious how the pieces fit together and what they do, or can do in PW.

Not a direct answer to your question but this seems like a really inefficient structure you got there. You could do something like this instead. /stores/ /store-1/ /store-12/ /store-13/ /cities/ /berlin/ /munich/ /cologne/ /categories/ /cat1/ /cat2/ /cat3/ and then enable URL segments on the category template, allowing for further filtering by city. So it works like: /categories/cat1/ ---> show all store that have this cat. /categories/cat1/berlin ---> show all stores that have cat1 and are located in berlin In this case berlin would be urlsegment1 (not an actual page). If you don't know already some info is to be found for example in this thread. In your case, a store can probably only be in 1 city, so you could even further structure it like: cities -city --store

It's hard to say without knowing the exact app requirements and the types of data you wish your users to work with but the custom app approach seems like the way to go. Everything you describe seems pretty doable as well. You've already wrote a big post but if you could shed some light on what functionality and types of data a logged in user would typically work with we could come up with some suggestions of how to structure your app.

Nico, a little site feedback: the navigation seems a bit off on FF and IE. Windows 7. Chrome for some reason is fine. https://dl.dropbox.com/u/14376901/20120329_1.jpg https://dl.dropbox.com/u/14376901/20120329_2.jpg

Setting it in config.php always works for me but i've never enabled language support. If you enable this you would have to set it in the language pack, as per http://processwire.com/talk/topic/1751-cant-get-pw-to-output-german-month-names/?p=16345

1. I think it's a great idea. I'm not aware of similar initiatives. 2. Don't think so but of course only Ryan can really answer this question 3. I would (if i had something worth showcasing ) 4. The second option, but it probably could also run on a processwire.com subdomain. 5. For starters, the site would have to be built with PW itself and follow the processwire.com look. Feature wise i would keep things to a minimum. Focus on the subject. The site you mentioned does a pretty good job, or even something really simple like http://expo.getbootstrap.com/ . So a couple of pictures, a link and some optional room for additional info.

I know virtually nothing about the inner workings of search engines but wouldn't it be hard to make make a module that comes close to the power and features of some proven technologies out there? Lucene based solutions like Solr or ElasticSearch, or http://sphinxsearch.com/ seem hard to beat. Of course, you won't be able to run those on relatively cheap hosting but when a project requires this kind of search power you are looking at some dedicated stuff anyways?

guenter55, couldn't you just include the setlocale directive in config.php? Seems easier to maintain in the long run.

Also wanted to add that you can take a look at http://modules.processwire.com/modules/data-table/ for some inspiration. It's listed as 'non-stable' and works as a back-end module but maybe it can be of some help.

In most cases there's not a lot to it: 1- Transfer all files from your local environment to the desired location on the 'webspace'. You would probably do this via ftp. I assume you know how to do this. Make sure to also transfer the .htaccess file, because sometimes this is hidden. 2- Make a database export of your local database (via PHPMyadmin or other tools). Do a database import of this stuff in your new database on the webserver. 3- Check the database credentials in the file site/config.php on the server (near the bottom of the files). If needed adjust to the online environment and databasename, login etc. That's it. All things should work now. There are a couple of things to keep in mind though: - if locally you developed the site in a subdirectory (e.g. localhost/test/) and you move the site to the webroot or subdomain, most probably links to files and images inside richtextarea's stop working. You would have to adjust the paths in your database export before importing it. - sometimes you need to change directory permissions for certain dirs to write permissions.