Leaderboard

PW has to support a broad range of MySQL versions. One of PW's distinctions is making all of the data highly accessible, behaving as if it was all in memory ready to be used, while still being able to scale to millions of pages. One of the important keys to this is fulltext indexes. InnoDB did not support fulltext indexes for a long time, not until recently, in the overall MySQL timeline. While InnoDB now supports fulltext indexes, that's only if your server has a newer MySQL version that supports it, and a great many out there do not support it. Whereas it is universally supported on MyISAM, and has been forever. PW also performs reliably and particularly well with MyISAM (though does with InnoDB too). Like SiNNuT mentioned above, there are no foreign keys in MyISAM, so it's not even a consideration to be debated. While having foreign keys would have certainly saved time on the development side of PW, and are a nice-to-have feature at the DB level, the lack of them is not going to "lead to data inconsistency" either. We manage our table relations very carefully and thoroughly, as we know we don't have foreign keys managing that for us. To the end user of PW it makes no difference. I'm quite certain that whatever issue you are running into has nothing to do with the lack or presence of foreign keys. You can take advantage of InnoDB in PW now if you want to, and we've confirmed it working quite well across several installations. In fact, it's now an installation option available to you. If you click on the gear icon during install (MySQL settings screen) you'll see an experimental option to use InnoDB. While PW won't use features that aren't in both MyISAM and InnoDB (in order to be compatible with both), there are still some benefits to using InnoDB. Specifically, if the power goes out on your server, you won't have a potentially crashed table (needing a repair command). In addition, tables aren't locked during writes, making it work better in high traffic environments that are having to do a lot of INSERT or UPDATE operations in PW (i.e. constant updating or importing pages).

suhosin u su hosin ? do this.it do u disabble suhosin

Hi jsantari, Here's how I'd go about it: (1) Make the following templates: products.php product.php product-categories.php product-category.php options (no need for php file) option (no need for php file) (2) Make the following page structure: /products/ (uses products.php)/product-1/ (uses product.php) /product-2/ (uses product.php) (etc) /product-categories/ (uses product-categories.php)/product-category-1/ (uses product-category.php) /product-category-2/ (uses product-category.php) (etc) /options/ (uses options.php)/colors/ (uses option.php)/red/ (uses option.php) /green/ (uses option.php) /blue/ (uses option.php) /sizes/ (uses option.php)/small/ (uses option.php) /medium/ (uses option.php) /large/ (uses option.php) (3) create the following fields: color (Page field; single value; use /options/colors/ as parent; regular select box); assign it to product.php size (Page field; single value; use /options/sizes/ as parent; regular select box); assign it to product.php products (Page field, multi-value; use /products/ as parent; ASM select or even better, PageListSelectMultiple since you have over 2000 products); assign it to product-category.php Now we need to handle what you said: "The twist is that each product category will have attributes like color, size etc. but the values for color, size etc. will be different based on what category is selected." The way I'd approach is to create 2 more fields and assign them to the product-category.php template: filterable_colors (Page field; multi-value; use /options/colors/ as parent; ASM select preferably); assign it to product-category.php filterable_sizes (Page field; multi-value; use /options/sizes/ as parent; ASM select preferably); assign it to product-category.php So those two filter fields will pretty much allow your category to have specific filters. Ideally, you would then code your product-category.php template to loop through and output all the products assigned to the category, as well as loop through the filterable_colors and filterable_sizes which would act as filters to the list of the products on that page. If doing the filtering client-side, here's a cool library: https://mixitup.kunkalabs.com/ Hope this helps! Jonathan

In the last few weeks I've notices some request (e.g. here and here) to be able to get pages based on if they are selected in page fields of other pages. I think adding a method for this would be a nice addition to ProcessWire, as it's often the case that the pages itself are options we just want to get, if they are used somewhere. Currently the task "Get all tags used by some blogposts" has to be done manually like this: $tags = $pages->find("template=tags"); foreach($tags as $tag){ // Filter unavailable if(! $pages->count("template=posts, tags=$tag") ) continue; // Do stuff with it } Now it would be nice to have something like this, where we don't need to have a selector for tags (this is done by the pagefield already). // Find all pages, which are selected in the "tags" field of the selected posts $available_tags = $pages->findSelectedPages("template=posts", "tags"); I'm not that big a MySQL guy, but I can imagine this not only improving readability, but also reducing database calls.

maybe this might help? http://docs.ckeditor.com/#!/guide/dev_styles

This was the problem. I have forgotten to include the child pages template. Thanks Wanze

You have the full ProcessWire API available in your Pages2Pdf templates. Did you output the children also in the template inside "site/templates/pages2pdf"? If so, they should appear in the PDF files. Only problem I can think of is that the PDF enginge can't handle your markup, you might need to simplify the HTML. But for testing purposes, you can also just list the prices-pages in a simple list. If it does still not work, please post the content of your pages2pdf "pricelist" template. Cheers

I've not used the Pages2PDF module by now, but you can use the WirePDF module, which is part of the installation, to render any html content you pass to it.

You probably discovered a bug or an inconsistancy. With a multilanguage set up the following two fields can each have an unique value per language: - Date Input Format Code - Time Input Format Code Altough the Select boxes are not seperated per language - Date Input Format - Time Input Format While it is expected that it picks the language that is active with the current user. When you are loggedin and have selected German language in your account it will get the values from the corresponding language specific fields. When the field is empty it will use the default language as fallback value. edit: Reported it as a possible issue on github: https://github.com/ryancramerdesign/ProcessWire/issues/1268 - Have to see what Ryan has to say about it. It could be by design and have a logic explination.

Thanks for your help Horst, the problem was that an _init.php file already existed so the layout was nowhere set and the default name for it is of course not one-column, but default.php Working like a charm now!

@Jonathan great example for structuring such kind of content - thanks for that lession! i've it crosslinked to this topic: https://processwire.com/talk/topic/3579-tutorial-approaches-to-categorising-site-content/#entry35127 regards mr-fan

Crosslink to a interesting categorising post for products with extra options for pagefields: https://processwire.com/talk/topic/10306-product-catalog-with-a-twist/#entry97847 (i like to keep such really good examples organized together somehow...) regards mr-fan

You can create multiple user templates, since 2.5.14 (https://processwire.com/blog/posts/processwire-core-updates-2.5.14/). I'd use them.

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.

Hi Fred Just in regards to this comment above - your other thread was posted on a Friday and it's the weekend so I'm sure people will chime in during the week if they can help (the forums are almost always quieter on the weekend). Any replies in the forums are from community members giving up their time to help - there is no guaranteed support, so please be patient if you don't receive any replies for a day or two when posting.

Sounds interesting. Here's one way you can do it: $table = $fields->get('your_page_field')->getTable(); $query = $database->query("SELECT data FROM $table GROUP BY data"); $ids = $query->fetchAll(PDO::FETCH_COLUMN); $items = $pages->getById($ids); // $items is a PageArray echo $items->implode("\n", "<a href='{url}'>{title}</a>"); If we were to add this to the API, I think I'd want to make it accessible from a regular find() selector, rather than as a separate findSelectedPages method. That way it could be used with things like InputfieldSelector. Perhaps something like this: $pages->find("your_page_field=:selected"); ...where ":selected" is a keyword is would recognize to execute this behavior.

Luckily I do not have to work with WP sites, as I'm also build very less sites, mostly private things. There is only one site that was built with WP, it's a private site for my son and me. We haven't made any updates to it since two years. And I want to port it to PW since I know PW, but haven't found the time until now. My 10 years old son has made some photos that he wants to see on the homepage there and I need to remember where the admin / backend / login page was. I tried some URLs that all fail. Than I opened a FTP client and looked to the directory structure and found the name of the subfolder which contains the wp-admin folder. After typing this URL and failing again I got a bit dazzled and was talking / grumbling to myself. My son began to laugh and rolling over the floor and shouts: "You are not able to write wp-admin you have written pw-admin. Everything you can think of is PW!". And he is right: after finding PW, I just want to wipe out any past memory regarding WP. After porting this site I can fullfill this to 100%. Until then I have to live with mistakes like pw-admin.

A bit OT, but if you can plan the languages hirarchy right from the start of a new site, you can do it this way: enable languages support set Title / Label of the default language to your desired none english native language, (e.g. 'Deutsch' (German)) drop in the none english language pack (for admin backend) into the default language, (e.g. german langpack) add a new language to it and drop in a language pack for any none english language or simply don't drop in a language pack to get the english version (but not as the default one!) As a nice sideeffect every new user in your system gets the native language per default without have it to select from the list. So, yes, this is no solution if you once have set it up and need to switch the default language afterwards, but just want to note it.

Just wanted to throw in my two cents. If you come at it as a front-end developer that's a complete beginner to CMSs, then PW should be very easy to get going. It's built around working the same way that existing web technologies work… Pages map in the same way that URLs do… Template files are just plain HTML/PHP files… the API is largely the same as a front-end API (jQuery)… and so on. So if you know your basic web technologies outside of CMSs, then you won't find a simpler system than ProcessWire. The problem is most other CMSs don't work that way. So the line gets more blurry when you've become used to the terminology and approach of another CMS, because PW can be quite different. Sometimes you have to unlearn what you know from elsewhere in order to appreciate the simplicity of PW. People are always trying to find complexity that isn't there, especially those that grew up on other platforms. PW is a system that rewards you by being curious. We aim to show you how to fish so that you can catch the big fish. We're not here to catch the fish for you. You don't have to know anything about fishing, but you should know how to yell for help if you fall in the water. And you should be willing to learn by example. I learn best by example, so this is the way I tend to teach too (and I recognize not everyone learns the same way). PW is a CMS and CMF, not a website builder. If you are curious and willing to explore, you'll find it is very simple indeed. Certainly far simpler than even WordPress in creating a custom website. You do have to come from the point of view of "I want to create and have the system adapt to me" rather than "I will create something based on what the system provides." If you already know what you want to create and it's something unique, you won't find a simpler path to get there than PW. WordPress is a different beast, in that it's basically saying "YOU WILL CREATE A BLOG or modify this blog and call it something else." Some people like that underlying structure… "okay, we're starting with a blog, what can we do with it?" Others do not like that underlying structure. Our audience consists of those that want to have a system support their original creation rather than mash up an existing creation. There was a PDF posted earlier that I think hit upon some good points, and I appreciate the effort that went into putting it together. The fictional character being scripted in the dialog is not our target. I can go into specifics if anyone wants me to, but I was definitely left feeling at the end of it that we have to be careful about hand-feeding too much or else we'll start attracting people beyond our support resources. Folks that want the fish cooked and filleted rather than folks learning to fish. Perhaps in time we will want to attract more of the consumer-type audience, but currently I don't know how to support users looking to find all the answers in a sitemap file. Keep in mind that unbridled growth is not necessarily desirable. Most of us don't get paid for most of the work we do here and we do best if we grow in a more healthy manner, attracting more thoughtful designer/developers that are here to learn and also contribute. Obviously the author of the PDF is one of the thoughtful ones (and the PDF is a great contribution), even if his fictional character isn't necessarily, but we'll welcome him anyway. But we will definitely be going through the PDF in more detail to learn and improve from it where appropriate, while keeping our audience in mind. I think we're doing something right, because our audience is growing rapidly. I'm nearly full time on ProcessWire now, and it's still difficult to keep up with everyone. At present, I like that our audience is largely open-minded, curious and thoughtful designers and developers. Somehow we've attracted an incredible quality of people and that's what makes this place great. We could not ask for a better group of people here. I'm reluctant to lead PW towards a website builder direction because I think that's when the quality of the community could go down, as people come looking to eat fish rather than learn, catch some fish, and throw some back. The reality is that part of our long term goals include converting the rather large audience that has outgrown WordPress into ProcessWire users. I'm convinced that we do that by giving them more ProcessWire, and not more WordPress. But at the same time, we always have to keep an eye on WordPress and learn. They've been lucky no doubt, but they are also doing many things right. So we have been and always will be working to make the WP-side of users more comfortable in ProcessWire, while also trying to help them grow by distancing them from the limited WP mindset.

If you have a robots.txt, I would use it to specify what directories you want to exclude, not include. In a default ProcessWire installation, you do not need to have a robots.txt at all. It doesn't open up anything to crawlers that isn't public. You don't need to exclude your admin URL because the admin templates already have a robots meta tag telling them to go away. In fact, you usually wouldn't want to have your admin URL in a robots file because that would be revealing something about your site that you may not want people to know. The information in robots.txt IS public and accessible to all. So use a robots.txt only if you have specific things you need to exclude for one reason or another. And consider whether your security might benefit more from a robots <meta> tag in those places instead. As for telling crawlers what to include: just use a good link structure. So long as crawlers can traverse it, you are good. A sitemap.xml might help things along too in some cases, but it's not technically necessary. In most cases, I don't think it matters to the big picture. I don't use a sitemap.xml unless a client specifically asks for it. It's never made any difference one way or the other. Though others may have a different experience.

maybe: $options = array( 'has_children_class' => '', 'levels' => false, 'max_levels' => 2, 'show_root' => true, 'outer_tpl' => '<select id="select_mobile">||</select>', 'inner_tpl' => '<optgroup label="¬">||</optgroup>', 'list_tpl' => '||', 'item_tpl' => '<option value="{url}">{title}</option>', 'item_current_tpl' => '<option value="{url}" selected="selected">{title}</option>' );