Leaderboard

There's a variety of ways to go about it. The approach you choose ultimately depends on how flexible you want it to be. This is a situation I've faced many times, and my approach has become more and more refined over time. Approach 1: You could assume that there will always be those 7 sections, in their exact configuration and only on one page. If so, you could simply code the section grid structures in your template. As far as what goes in each block within each section, they can either be coded in the template file, or there could be custom fields representing each block, or a combination of the two. This approach is not the most flexible, but would be the easiest for your end client to manage because there a 1-to-1 relationship (meaning each block is defined by a specific field). Approach 2: You could create a section system using the PageTables field as described in the previous replies above. It would involve the following: Templates: template: content-sections.php template: content-section-type-1.php, -type-2.php ... -type-7.php (make sure to disable prepend of _init.php if using direct output) Pages: /content-sections/ (uses content-sections.php; set this page to hidden)Fields: content_sections (PageTable, allow use of content-section-type-1,2,3,4,5,6,7; pages created get stored under /content-sections/); auto-name based on a date timestamp; apply field to the template(s) you wantNow edit the page that contains the content_sections field and create your 7 content sections. Edit the template file that this page uses and output the blocks: <?php foreach($page->content_sections as $content_section): ?> <?php echo $content_section->render(); ?> <?php endforeach; ?> Write the necessary HTML and CSS for each content-section-*.php file. Limitations of this approach are the following: It forces you to assign the "content_sections" field to the template(s) that you want to use it on. Due to the nature of the PageTable field, you can't re-use an existing content-section on a different page. You'd have to re-create it the content-section. (a regular Page field allows re-use of existing pages, however the interface isn't slick like PageTable; look into this PageFieldEditLinks for an easy workaround) In the event you want to insert a different kind of content between content-sections, that means you have to create yet another content-section type to handle that situation. This will get intense if you have a lot of different situations. Approach 3: This approach is what I like to use if the situation is right. Like Approach 2, create the templates and pages as described. Now, if you want to create a content section, simply create it as a child page of /content-sections/. Now you obviously want to insert these content sections on your page, but since we're not using PageTables, we need a way to do this. Hannacode to the rescue. Create a Hannacode called "content-section". Give it a variable called "_name" (notice the underscore... "name" is a reserved word which Hannacode will complain about but no big deal). Make sure it's a PHP Hannacode. Now we need to program this Hannacode to output a content-section. This code will work fine: <?php $content_section = $pages->get("/content-sections/{$_name}/"); if($content_section->id) echo $content_section->render(); Now in your page, simply insert something like this in the body field: Welcome to my page. [[content-section _name="the-name-of-content-section-1"]] [[content-section _name="the-name-of-content-section-2"]] [[content-section _name="the-name-of-content-section-3"]] You can put text between content sections because we're just inside of a CKEditor field. No limitations! [[content-section _name="the-name-of-content-section-4"]] [[content-section _name="the-name-of-content-section-5"]] [[content-section _name="the-name-of-content-section-6"]] [[content-section _name="the-name-of-content-section-7"]] The key thing here is how Hannacodes are being used. Notice how I'm just calling on the render method, so the Hannacode itself is not dealing with the any complex logic. It's simply being used to load a page with its template... nothing more. This approach is good because: it'll allow you to insert content-sections on any page with a body (or similar) field, regardless of the template. you can insert random content between the content sections content sections can be re-used (unlike with pagetable) The drawbacks of this approach are: you have to use hannacode, the syntax and know the name of the content-section you want to insert. (although this could be solved with some sort of ckeditor button... I wish there was a ckeditor hannacode smart inserter; apeisa has thought up this idea as well; SOMEONE DEVELOP THIS! ) because the hannacodes are just text, it's not a "true" relation behind the scenes. so, if you were to delete a content-section (or change the page name) from the page-tree, the hannacode will still be present (unless some sort of special text formatter like the page link abstractor is made) -- The thing about ProcessWire is that you can create any approach pretty easily based on your needs, and I think that's what it comes down to. There's no "right" answer, but rather whatever suits the site the best.

@adrian Success!!! I have completely migrated a wordpress blog into a ProcessWire site running the Blog module! I will be writing a quick summary and explainer on how to successfully do this. I am sure there are others who are going to encounter this at one point. It will be nice to save a headache and get it done quickly.

-X is not a command, maybe you want a "curl" in front of it.

If you having issues getting this to work, I have posted two separate ways of doing this: https://processwire.com/talk/topic/1716-integrating-a-member-visitor-login-form/page-5#entry89599 and https://processwire.com/talk/topic/1716-integrating-a-member-visitor-login-form/page-5#entry89616 Pros and cons to each version, so you should read all the posts in between as well. Personally I would go with the second one, just be aware that if you want it to work on the front-end you need to consider the name of your form fields.

As I’m getting a bit more into the e-commerce idea I was talking about in one of the other threads, I have been thinking about the PW template system. In a shop system you’d need a kind of basic product template with certain necessary fields like default price or something like that. But you’d also need the possibility to have variations of a product template, where additional fields can be defined individually for a certain kind of product. I know that there is the possibility to clone fields from an existing template. But I don’t think, that is a good solution for this particular problem, as you were able to delete some of the basic product data fields. So my thought was, that it maybe would be a cool thing to be able to define a kind of relationship between templates. Like a class extending another one you could define an existing template as parent and the child template would inherit all fields and settings. New fields could be added, the inherited fields were kind of protected, the settings could be overridden by the ones defined for the child templates. I guess, this could be achieved by a module pretty easily. But I think it could also be a pretty nice enhancement as a core feature.

It's the same as wire('page') wire('config') Same goes for all PW variables (https://processwire.com/api/variables/)

I saw those two, but figured that since they are $pages->count() calls they wouldn't be a problem as they are not loading those page into memory - right ? Oops, they are count($pages....), rather than $pages->count(). Maybe that simple change would make a big difference.

I am going to chime in and say that isn't really correct There are lots of acceptable ways to do something, but even as brilliantly thought out and architected as PW is, it doesn't prevent you from writing template code that results in slow/inefficient queries and also potentially dangerous holes that users could exploit. Keep in mind that there isn't any CMS out there that can prevent you from making these mistakes. PW makes it easy to do it the RIGHT WAY, but you still have to think things through, follow best practices, and if in doubt ask someone more experienced if you are doing it right, or at least make sure you are not doing it wrong!

Doesn't sound right at all. 500M makes it sound like all your posts are getting loaded into memory all at once. Taking a quick look at the ProcessBlog.module, there's actually a bunch of queries without proper limits defined, such as this one for an example: wire('pages')->find('template=blog-post, include=all, sort=-blog_date, parent!=7'). If you want to debug this further, I'd try disabling all queries that find blog-posts without a proper limit, and see if that helps. Kongondo would know better how to handle these, if they're the issue here. Loading all posts into memory at once definitely shouldn't be the only option

Copied curl.exe to C:\cygwin\bin\ Putting curl after the cygwin terminal prompt $ does it ! Now I can execute those commands exactly the same way as on mac: split over different lines with \ and without escape characters Thanks Charles and LostKobrakai

ahh yea i use this codes and page refresh does not increase view. it looks only session $key = "pageview" . $page->id; if(!$session->$key) { $page->Counter += 1; $page->of(false); $page->save('Counter'); $page->of(true); $session->$key = 1; }

Sounds like you want to run a "LINUX/UNIX terminal" program on MS Windows. https://www.cygwin.com/

Not sure but I remember something about replacing the index.php might help. Are there any messages popping up during login ? Did you turn debug mode on ? This will ensure that errors are sent to the screen, exceptions reported, etc. This can be found in /site/config.php. By default, it is false. You'll want to change it to true: $config->debug = true;

I think this opinion by Chris Coyier is quite to the point https://css-tricks.com/the-trouble-with-preprocessing-based-on-future-specs/

Yes, I've used it (as a "consumer"). I have mentioned this in a thread about grid systems before: https://github.com/corysimmons/lost Here is a recent article introducing the system: http://davidtheclark.com/its-time-for-everyone-to-learn-about-postcss/

At the moment Raymond's answer seems to be the only working solution. This is essentially the same thing that @thetuningspoon posted in this issue: https://github.com/ryancramerdesign/ProcessWire/issues/1121, and it's been one of the very few major headaches for me since the beginning. In my opinion when something is set as "required", it should mean "required", not "recommended". The page should not be saved under any circumstances unless all required fields are filled in. From what I can remember, this has been discussed before, and the general idea was something along the lines of "a page with a lot of fields and couple of them required could result in a lot of lost data if it wasn't saved when one of the required fields was left empty". Essentially the page can be saved, but left unpublished, and thus considered as "temporary storage". This, again in my opinion, would be better solved by storing those values not within actual pages, but a) some temporary alternative, b) within browser memory, or c) within session variables. Of course that would be a new concept for ProcessWire, and Ryan might also have other reasons to stick with the current behaviour Just my (relatively unhelpful) two cents. Edit: Just wanted to add that one specific issue with the current system is that once I fill in all fields I can publish the page, but after that I can clear required fields, save the page, and it remains published. This, at the very least, is not what I'd expect.

Now I feel silly, it was a selector issue, this works: template=user,role*=coach

I'd suggest you read the first three of those linked topics here: http://processwire.com/api/multi-language-support/ The URL one does explain how you'd get those urls without doing anything to the .htaccess file. The first one does explain how the internationalization of static texts in templates work and the middle one is about how you can setup the fields for your dynamic content, so everything is language aware, too.

The source is on GitHub, knock yourself out https://github.com/mindplay-dk/SystemMigrations

Yeah, sorry about that. I just added an "EDIT" in bold to the original post, so others can decide whether they want to read through it all ;-)

I have done something like this half a year ago. I made an intranet for a company with 200 employees. There are no problems I heard of so far. It has a full text search, a searchable image repository with thousands of photos, every user has his own profile with his portrait... Most important thing was: every download of this intranet (PDF, Word, Excel, image files and so on...) is a page. I have build a small multi file importer which allows to upload many files at once, which leads to creation of the according amount of pages with these files attached. I did this to give each file more properties (think of it as an" asset management" - every file can have properties like view rights, tags, relations, descriptions, authors etc.). To assign this download pages to their parent "content pages" (the page the visitor sees in frontend view) I did use page tables very much. I think it works very good and I enjoyed it to develop and customize.

Regarding languages for these modules, I don't see language alternative fields (ie: text, text_fr, text_it) being avery usable option. Consider having 5 text inputs, I have to create one field for each language and put them all one after another, that will give me 3x5 inputs scattered over the page editor. For site editors this doesn't feel quite intuitive and is mixing approaches. So creating 5 textfields is still the best way to go and those profields aren't of much usage except for multiple inputs not needing languages like phone numbers, which is very seldom. EDIT: Regardless, I also wanted to say thanks for those amazing nice new tools! (just wish that "restriction" regarding languages wasn't there).

What I think is most promising is using CKeditor widgets for image positioning, galleries, videos, text-columns, content highlights etc... and then just regular pages and repeaters for everything else (like featured products, carousels etc). Probably the ultimate solution would be something that ties hanna codes with CKeditor widgets. For me using repeaters and field dependencies here feel little hackish - both UI and backend wise.