Leaderboard
Popular Content
Showing content with the highest reputation on 09/03/2014 in all areas
-
It doesn't have to be core - an optional module makes the most sense since it's not required by most. I think some minor changes could be required in the core to make it work, but possibly not all I know is that ryan has on occasion made changes to the core to allow for other bits of functionality but I don't expect this workflow would be a core addition. Either way, let's not fixate on it being core or not and keep the discussion more around requirements I'm short on time at present but I might break off all the workflow posts into a separate topic later today unless someone beats me to it (feel free mods).8 points
-
I think that editing and content approval workflows are a great idea and I can 100% see the use case for them in enterprise application and large workflows. I don't think it should be part of core however. Keep core as lean and abstract as possible, not catering to any specific use case over another. These features would make an excellent module, or possibly multiple modules that work nicely together around each other such as page/node statuses, page/field version control, editing/approval workflows etc. Having them as officially supported/vetted paid modules would be the ideal scenario if you're trying to attract enterprise customers. WordPress gained a lot of larger publishers when it worked heavily on workflow / editing flow improvements (officially sponsored by Automattic as part of the WP.COM VIP program), but this was still done as a plugin because it's more than the average user needs, heck post versioning as it exists today in WP is likely WAY over the top for 99% of WP users and it just bloats the DB.6 points
-
Put your fallback image within a <noscript> tag, solves this issue (won't be inserted into the DOM /evaluated for SRC etc) unless JS is turned off, and keeps the fallback. Can bloat the code a little, but much less so than downloading 2 images. Also you could setup a build system like grunt or gulp to add the noscript fallback automatically during the build process.5 points
-
There are a few ways to do this. Option 1 (Field Dependencies in Repeaters) The dependencies are limited to field=value, and you need to be sure to change this config option. Create a page field (select) with all the "block" types you want. Create fields for each of those block types and add them to the repeater. (Example: Text, Image(s), File(s), Video, etc…) This method works, but it can be a little clunky from a UX perspective. I'm mostly mentioning it for reference, option 2 below is really much cleaner. Option 2 (PageTable or PageTable Extended) As Adrian mentioned, PageTable will be available in 2.5 (available now on the dev branch). The extended version that Marc (MadeMyDay) released is amazing, and sounds like a perfect fit for what you need. The benefit of this method, is that each block type can have as many fields as you need. You can create complex layouts (even within each block) without the user attempting to size/position things in a WYSIWYG.4 points
-
Hi Tobaco, my setup is always the same. Doesn't matter if I use PageTable or not. Here it goes (simplified): /templates - basic-page.php - home.php - /tpl - main.php - mainnav.php - subnav.php - footer.php The tpl/main.php is the overall template like: <?php include('tpl/mainnav.php'); include('tpl/subnav.php'); include('tpl/slider.php'); ?> <!DOCTYPE html> <html class="no-js"> <head> <meta charset="utf-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1"> <title><?= $page->title ?></title> <!--- styles and scripts --> </head> <body class='<?= $bodyclass ?>'> <header> <div class='wrap'> <a href="/"><img src='/site/templates/img/logo.png' class='logo' alt="Logo"></a> <nav class='main'> <?= $mainnav ?> </nav> </div> </header> <?= $slider ?> <?= $subnav ?> <section class="content"> <div class="wrap group"> <h1 class='v2 hide'><span><?= $page->title ?></span></h1> <?= $content ?> </div> </section> <footer> <div class="group"> <?php include ('tpl/footer.php'); ?> </div> </footer> <script src="/site/templates/dist/all.min.js"></script> </body> </html> basic-page template looks like this (every template renders the content and then includes the main template): <?php /** * basic page template * */ $bodyclass='inner'; $content = $page->body; include('tpl/main.php'); With PageTable the structure looks like this: /templates - basic-page.php - home.php - part_text.php - part_columns.php - part_gallery.php - /tpl - main.php - mainnav.php - subnav.php - footer.php The part_* templates are templates only for PageTable. part_columns.php could look like this: <?php $headline1 = ""; $headline2 = ""; if(!$page->checkbox1) $headline1 = "<h2>{$page->title}</h2>"; if(!$page->checkbox2) $headline2 = "<h2>{$page->text1}</h2>"; // Output echo " <div class='pageTableSection {$page->template->name}'> <div class='inner'> <div class='col one-half'> {$headline1} {$page->body} </div> <div class='col one-half'> {$headline2} {$page->textarea1} </div> </div> </div> "; And the basic page template gets enhanced by ("layout" being the PageTableExtend field): <?php /** * basic page template * including PageTable layout parts */ $bodyclass='inner'; $content = "{$page->body}"; if(count($page->layout)>0){ foreach($page->layout as $l){ $content .= $l->render(); } } include('tpl/main.php'); That way, the layout parts are easily renderable in the Admin with PageTableExtended. While writing this, I want to point to another feature of the module. If rendered by PageTableExtended, the template gets an option 'pageTableExtended' which you can use in your part template: // Output echo " <div class='pageTableSection {$page->template->name}'> <div class='inner'> <div class='col one-half'> {$headline1} {$page->body} </div> <div class='col one-half'> {$headline2} {$page->textarea1} </div> </div> </div> "; if(!$options['pageTableExtended']){ // we are not in the Admin, so we include our social media buttons which we only need in our frontend include('social/socialmediabuttons.php); } Hope that helps.4 points
-
I had written a big post here about drafts/versioning etc a few days back but silly me was doing too many things, forgot about it and forgot to hit "Post" It went a little something like this: Drafts/versioning/workflows (let's just label all of those as workflows because they are all linked) is a feature that is usually required by larger sites/companies and is something that is actually worthy of the name "enterprise" that people have been using a lot recently. A system that I used 10+ years ago when working for my local Council had the following abilities (not saying we're behind the times by mentioning "10+ years ago", more that my memory won't be great when recalling the details ): The web team manager was able to edit certain fields (META data etc whilst the rest of the team was able to edit the content fields. This can already be accomplished in PW, but not sure how easy it is to use - ideal would be a tab when editing a template that has a matrix of all the fields and all the roles and checkboxes to determine who can edit/see which fields. Once web team user has finished editing, page goes to approval with team manager who can review the edits. These will quite often be changes to pages that exist already, so this is a draft copy of that page that has been worked on. There were also X past versions of a page (in PW this could perhaps be determined per-template again as some may need no drafts and others you might want a few) along with who edited them I think (10 years is a long time). Pages could also have a review period assigned to them. This would be a trivial module to build in ProcessWire, but the concept was that you would assign each page a review period of 6 months as well as the email address of the person best suited to review the content - this is NOT always a user account in the CMS. In the Council where I worked this person could be another department head and they would receive an email for each page on the relevant review date, with follow-up reminders. The ideal here would be for the web team leader and other suitable people to be able to log into the admin and see a list of which pages were up for review, who they were being reviewed by and they would remain in the list until either the content was updated or a box was ticked to add another X months to the review date. In theory there are multiple workflow steps that might be required - I think Concrete5 has the ultimate workflow solution here (I started the video at 40 seconds but not sure the forums will cope with that ): http://youtu.be/Z1fHz5jTnw4?t=40s but I'm not 100% sure a "version 1" would need to be that fancy. I can see how the interface might start to come together though as we already have things in the dev branch at present that deal with triggers and actions, I think something like that could be applied to per-template workflows. There isn't a huge audience asking for this, but there is a huge potential audience out there. The vast majority of medoum-large news/magazine sites could use this - having run a small one as a hobby it can become problematic to keep track of what's going on with just a handful of staff. Then there's just about every local government who are on the lookout for something powerful and cheap, but have to have the workflows in place for accountability (and sanity when dealing with lots of staff editing bits). And then there are large companies with lots of content to manage. Certainly I can see all of the above wanting to use ProCache too since systems with advanced workflows can often be of the slower variety. I don't want to sound melodramatic, but without a good, coherent approach to drafts/workflows/version control we are effectively shutting out a large audience. The problem is that it is easier for people reviewing a CMS to see what it's got, not find what they want and go elsewhere rather than saying "I'd use this CMS but it doesn't have feature X", so we will never know how many people might actually consider PW if it had workflows. (On a related note, can we set up the Site Search feature in Google Analytics for the forum and site search fields ryan - then we might get a better idea of what people are searching for but not necessarily requesting ).4 points
-
Your hook and method has a lot wrong. If this all would work, then you would hook into Inputfield::render() and not Inputfield::renderValue(); And a hook to do what you wanted would look more like this: function hookAppendClassName($event) { $className = " mygrid"; $classes_array = $event->object->getParent()->getClasses(); $classes_array = array_merge($classes_array, array('item' => $classes_array['item']." ".$className)); $event->object->getParent()->setClasses($classes_array); } But this is not possible. When a inputfield is rendered in the inputfieldwrapper, the classes and markup is already set and you can not overwrite it at that moment in time. I also was looking into this and by chance I found a line of code in latest dev, that seems to be added recently. InputfieldWrapper rendering method looks for a $inputfield->wrapClass, I didn't know was there. So you can now simply do this: $field = $modules->InputfieldText; $field->label = "Name"; $field->wrapClass = "mysuperlol-col1--wonder__toootooo"; ...3 points
-
There is a new field type (PageTable) in the dev version of PW which will be released as 2.5 probably in the next week or two. There isn't much documentation on it yet, but there is already a cool extended version of it that will help you to visualize how it can work for exactly the scenario you are talking about: https://processwire.com/talk/topic/7459-module-pagetableextended/2 points
-
You should visit the Plaza de Las Ramblas and Barceloneta (at least). If you come to Andalucía let me know and I invite cafes and beer. Bon Voyage.2 points
-
We have the same experience as Pete. This is my scenario with larger teams: "draft" means: needs to be finished and approved: the editor sets the page up but has no right to change the status. The supervisor approves by changing the status. So, "draft" clearly says: not ready, work needed. (As a workaround I use a checkbox field for that at the moment.) "unpublished" means then: content is ready but for other reasons the page is not live (like a campaign/news with a start date and an end date).2 points
-
Some more updates on the multi-language front: ProcessWire now comes with a multi-language site profile Language translation files now split by site and core These are the last two things I'd wanted to add to PW 2.5 before release, so please consider it now in release candidate stage. Your help testing is appreciated and please us know if you run into anything that's not working. PW is already designed for such a feature and has been since the beginning. Development of PW2's core and development of PW1's draft system had overlapping timelines. I had planned on including drafts of published pages in PW2 until I saw how little use they got among my clients at the time. In PW2, page IDs 500-900 are reserved and recyclable/reusable for drafts, and there are already methods in the core and Fieldtypes that are there to aid in managing drafts. PW's unpublished vs. published pages system already accommodates the biggest needs in drafts. Drafts and unpublished pages are essentially the same thing in the minds of most (of my clients at least). The drafts that you are talking about are something different and really only useful in situations where you've got pages on a site that continue to undergo major changes after they've already been published. Since developing the drafts system in PW1, I've learned that most don't publish content that way. Instead, they work on something, publish it when they are ready, then move onto the next thing. Though drafts for published pages are definitely useful when/if that is the need, and I have no doubt that some clients have the need. But the reality is that it's a whole lot of overhead for something that most won't ever use. As a result, it would likely come in the form of a module (whether uninstalled core, or 3rd party I'm not sure). But it's definitely coming. In terms of technical challenges for drafts of already published pages, they are only with regard to Fieldtypes that create other pages. Specifically: Repeaters and PageTable. Those two Fieldtypes are the only two I'm aware of that don't currently support drafts for already published pages (though it's possible they could with modifications). All the other Fieldtypes are pretty much draft-ready. Technically there is significant overhead associated with drafts of published pages. It's a 2nd set of editable data. However, you wouldn't feel the effect of it unless creating or publishing a draft, and specially one that had a large amount of assets connected with it. As a result, most would likely not feel the overhead. In terms of comparing overhead, repeaters have more overhead than drafts. I'm very much sold on Teppo's versioning system, and I use it on pretty much everything now. While I have plans to finish the drafts system that's already started, I don't have plans to reinvent what Teppo has already done with regard to versioning. If people have more needs in terms of versioning, we should probably talk to Teppo.2 points
-
->getThumb() actually returns an url, not a pageimage object. You may try to use the PiM for that? (with PiM you can manipulate imagefiles, not only pageimages) But because of the lack of native PW methods, you need to use some plain PHP code: // define some vars $cropname = 'crop'; $width = 600; // build the fullpath from the thumbnail url $sourceFilename = $_SERVER['DOCUMENT_ROOT'] . $page->header->getThumb($cropname); // build the targetfilename $targetFilename = dirname($sourceFilename) . '/' . $cropname . '_' . $page->header->name . ".{$width}x0." . pathinfo($sourceFilename, PATHINFO_EXTENSION); // get instance of PiM for manually usage, do the resize and save to a new file and return the targetfilename on success $result = $wire->modules->get('PageImageManipulator')->imLoad($sourceFilename)->setTargetFilename($targetFilename)->resize($width)->pimSave(); if($result==$targetFilename) { // resizing and saving was successful, now we need to get the url from the diskfilename $url = str_replace($_SERVER['DOCUMENT_ROOT'], '', $targetFilename); // and can output an image to the page echo "<img src='{$url}' />"; } This is written in the browser, but I think you get the clue, also it looks a bit clumpsy. But if it works, ...2 points
-
@ryan. Not a lot of demand? What planet do you live Well, everytime this comes up it get's many likes. My post just got 7 likes. I and many others are waiting for versioning/drafts since a long time. Thing is that it was on the roadmap all the time, so many of users are not asking for it again and again cause it's already.. well "ordered". I agree that it might not be always needed, and I see that this is not a quick implementation (I wouldn't know how in PW this should be designed). Maybe PW just isn't designed and capable for such a feature. And also it can lead to confusion if not implemented right. And all that comes with it, all correct. But I think it's a feature many are waiting for.2 points
-
PageTableExtended Download here: http://modules.processwire.com/modules/fieldtype-page-table-extended/ Extends the Processwire PageTable field for rendering table row layouts. This is great for editors, because they actually see at a glance what the table rows consist of. What it does Turns the Processwire Fieldtype "Page Table" from this: into something like this (sorting capabilities of course still functional): See it in action: Requirements FieldtypePageTable installed (part of the core since Processwire 2.4.10.) Templates used for PageTable need a file associated (otherwise nothing gets rendered) This render method is meant for sites where the PageTable templates only render part of the layout, not complete websites. But you also can define what will be rendered (see below). Options Render Layout instead of table rows Check this for seeing the rows rendered. You can easily turn off the complete functionality by unchecking this. Path to Stylesheet Since the parts are unstyled by default, it is a good idea to define styles for them. All rendered templates are encapsulated in a div with the class "renderedLayout" so you can style them with: div.renderedLayout h2{ color: green; } The path is to be set relative to your templates' folder. Reset Admin CSS Since the parts are rendered inside the Admin, common styles of the Admin Interface apply also to your layout parts. This is not a bad thing, because especially text styles are well integrated in your admin's theme. But if you like to override the admin styles in your table rows completely (more or less), just check this box. Don't forget to define a custom CSS then! Advanced Since this module is meant for parts of your layout you already have defined for your frontend templates, it is a good idea to use a preprocessor like Stylus, Sass or Less for building the custom CSS file. Just outsource your layout part definitions in an extra file, compile that in a separete CSS file and use this as custom CSS for this module. Since your CSS is should be built in a modular way, this works pretty well ;-) Will write a tutorial with a use case once finished testing. Notes: Github: https://github.com/MadeMyDay/PageTableExtended If you want to get rid of the unnecessary step for entering a title before editing the page, just set the "autoformat" value as suggested in the PageTable settings. If you don't want to use a title field at all, see this post from Soma Will put it in the module repository once finished testing. Please test it and give feedback. I haven't used GitHub for a long time, please check if everything is in place and if this will work with the modules manager and the new core module installer once added to the repository. Have fun Module is in the repository now: http://modules.processwire.com/modules/fieldtype-page-table-extended/ Please use GitHub for instructions, I made some additions there.1 point
-
This module creates a blank dashboard page in your site admin and sets it as default when you login instead of the page list. It came from a need in a few projects where I was creating modules for various user roles to use and I didn't want them to see the page list at all, but needed to display various stats and quick access buttons. For example, if you have a person who is creating invoices or doing other back-office stuff in various other Process modules then as an admin you wouldn't want them to access the page tree anyway, and there are other scenarios where you might want to have a dashboard instead of launching straight into the page list. It also requires (and adds) a permission - "dashboard" - so you can create new roles and assign the dashboard permission to those roles - something you might want to do fairly commonly if you have a lot of admin modules that you want to restrict access to. Editing the template is simple - there is a dashboard.php template file in the /site/modules/ProcessDashboard/ folder (decided to leave it in there to keep it safe, but I might be tempted to move it into /site/templates/ ) as well as .js and .css files ready to add your code to. You can use the API as you usually would to create your dashboard experience. For example, display data based on user roles or even specific users using code like this: if ($user->hasRole('invoices') { echo "Hi staff member $user->name. View invoices to be processed below: ... ..."; } if ($user->name == 'pete') { // Show some super-awesome stuff here } You can also do away with the dashboard.php template file and edit the module directly, putting your code and output in the execute() function (the way most Process modules are written) but I decided to include the separate template file to make it easier for more people to use. This does touch on areas a few other modules have addressed to some degree (like diogo's Custom Admin Pages) but this is designed for one purpose - instant dashboard creation. You can download the module here: http://modules.processwire.com/modules/process-dashboard/ This module also uses code from diogo's ProcessHomeAdmin module so that the default admin page can be overridden.1 point
-
Hi! Just currently using this on our proof of concept and on a hackaton. It's like ServicePage module but the difference is it return data without the need of extra programming (Image field for example). Also it only coded on the template. It primary used template URL segment to identify what page should be returned. All output is generated in JSON format. You can view it here.1 point
-
Thanks BernhadB Appreciated the pointer, I know everyone has their own preference, suppose I;m just interested in different peoples preference and approach and I know there are many ways to skin a cat I'm really enjoying PW so far and realising that it's a great CMF to get people learning and thinking about projects, the ease of defining a query is truly awesome I mean: $mything = wire("pages")->find("template=my_template, my_field=special, my_field_featured_start<=today, my_field_featured_end>=today, limit=4, sort=random"); is just so simply to grasp and execute, I love the ability to tap into any field you define. Give me another week or so and I'll hopefully be posting my approaches and opening them up to either gratitude or constructive criticism, I'm looking forward to participating in this forum P.S. Even over the last couple of hours I've realised my frustration last night looking at the simple blog tutorial I was able to deviate from it all together and hash some functions together, PW makes PHP fun!!!1 point
-
This is real clever stuff MadeMyDay ! Great Job...1 point
-
Awesome stuff! This is one of the features i was always missing in pw. Great Job MadeMyDay.1 point
-
Ha! that *wink* should be bigger. BTW, this is so awesome!1 point
-
I did look there first but those logos don't have the P symbol used on the site. Google image search has mixed results but may have found something I can cobble. Would be great to have a brand section on the site.1 point
-
@Ivan: as far as I understand -aj- he is aware of that and I share his opinion / suggestion on building that not in the core but building it as a paid ProFeature for enterprise customers.1 point
-
Thanks, Pete! That is a good explanation of what I meant under "workflow" (and the video shows really good, how it could be implemented). Surelly drafts only won't do the whole workflow job, but they could start it. Granular per field/tab permissions are another step. And just wanted to add that this feature is not only needed for larger sites, but is really usefull for all of them if you have more than one person working in the team. We have SEO person doing metatags, we have content manager posting content and project manager checking on them and aproving stuff. All 3 of them sometimes do not even know each other. Workflows can help a lot building communication. I can see drafts only helping in that direction. @-aj- We are not talking here bout a full-functional workflow module yet, but rather about necessary buildind blocks for it, which probably should be in the core.1 point
-
No. The output format is only used on formatted output like "$page->date" while getUnformatted() returns the raw date as timestamp. These can easily be used by the php date functions. So there's no need to hijack the integer field to save dates.1 point
-
@pwired: contact form code was taken from here: https://processwire.com/talk/topic/407-processing-contact-forms/?p=32081 point
-
Link 1 here: https://www.google.co.uk/search?q=processwire+logo+file1 point
-
Include as normal...at the top of the class...e.g. require_once(__DIR__ . '/NameOfYourPHPFILE.php');//am assuming this is a class as well class BackendChat extends WireData implements Module { //your class methods } For $ _GET and $ _POST. See $input: http://processwire.com/api/variables/input/ In a module: $this->input->post; wire('input')->get should also work in a class I believe as well as a function. Otherwise, normal use is $input->post, $input->get, $input->cookie1 point
-
don't know if you can find something useful here, but it sounds like you can grab some code or ideas about 404: https://processwire.com/talk/topic/4884-hook-before-a-404-exception/ yes, here it is: https://github.com/harikt/Assets/blob/master/Assets.module#L59 https://processwire.com/talk/topic/5724-404-search-module/1 point
-
First of all I see that you haven't named your repeater template repeater_[fieldname]. But something different that could cause the problem is using the php short tag "<?=". Big chance that in php on the server short tags are turned off. You could try by changing it to normal php "<?php echo" and see what happens. In your home.php you don't use the short tag and so maybe, with your other repeater template it's the same, reason why that one works fine.1 point
-
I guess I am mixing purposes a bit here - your goal was to style the output exactly as it will appear on the frontend, but I guess I am looking more for replicating the ease of editing that repeaters have. Maybe I'll make a different extension for PageTable that works more that way. Maybe not worry about the ajax saving and just use the page save to save each of PageTable components. I'll mull over it for a bit.1 point
-
I do agree with Soma that over time there have been quite a few users that expressed their (big) interest in PW (page) versioning capabilities. On the other hand it's also quite hard to estimate how many PW clients would actually go on to use it. But a killer feature nonetheless, if done right. Anyway, it's on the roadmap for 2.6+ and if it stays there, i personally think it might be a good thing if the versioning, enhanced workflow and js session monitoring became a priority after 2.5. Why? Because i think these 3 items kinda go together. In my mind a versioning system really has the most use in some kind of editorial cycle where multiple people can work on a document (page) and maybe put versions up for review and approval, or other workflows. Ideally this would be be accompanied by a way to compare differences between the published version and/or draft versions. Maybe some inspiration can be taken from the VersionControl module by teppo. But maybe i'm taking this too far. I would be curious how Ryan sees the scope of versioning capabilities and related subjects.1 point
-
@Jan Romero: What version of PHP and MySQL are you running? You also mentioned 3rd party modules–which modules? (If not Textareas ProField?). The ProFields have been developed in tandem with the dev branch, so I'm fairly sure that wouldn't be it. But the commit you indicated did change the way module information is cached. I found one other instance of a similar upgrade error and we traced it to a bug in a specific PHP Version. That's why I'm curious about the versions of software you are running. I think this is largely the inclusion of CKEditor. The Iridium profile does take up some space since it has a lot of photos, so I may leave that one as an external install. Overall though, I think we're being pretty safe with file size. I can still download a ZIP from GitHub in less than 3 seconds, and we've never had any complaints that file size was preventing someone from trying or using PW. As a result, I think we're better off using file space where we can to make sure PW really impresses people when they download and try it out. On the other hand, we should also be safe and not include multiple RTEs, etc. For example, we removed TinyMCE when we bundled in CKEditor. There has been little demand for this, that's why it keeps getting pushed back. How many threads do you see posted of people asking for this capability? I agree it's a nice capability, and I would like it too. But I try and focus my efforts on what will get used the most. At least the non-sponsored new additions you see in 2.5 are largely based on what's been asked for repeatedly in the forums (as well as what I would personally find useful). So we'll count your request here as momentum for drafts. The funny thing is that PW1 had full drafts capability, had a huge amount of work behind it, and it worked well. The unfunny thing is that clients rarely used it. The primary time that clients (my clients at least) wanted a draft of something was when creating a page. That's why we've already got that in PW2. I ended up feeling that all the work behind drafts in PW1 was kind of a waste of time. Of course the PW2 user base is much larger and the potential audience for such a feature is much larger now. I personally would like to have drafts for already published pages too, but the reality is there's only a small segment that will actually take advantage of it. It's a feature that sounds good, but few use. Still, we may have the critical mass now for it to be worthwhile. And it's also on the checklist of many, even if they won't use it. I even have it mostly built already, and have been occasionally working on it, but it's been kept in the background as more popular features have gotten attention. I appreciate the interest of course, but I don't think this is necessary. We've already got commercial modules funding developing of ProcessWire. The focus on what gets added is also largely based on what are the most common needs people have around here, within the limits of feasibility and schedule.1 point
-
I used modX heavily for 2-3 years and thought it was the bomb. When I found PW I realised modx was good but was not the holy grail I originally thought. Modules in PW seem to be a lot tighter than in modX - they just seem to work. But to be honest, I hardly ever reach for a module in PW - the core and brilliant API provide so much functionality that modules are often completely unnecessary for lesser complex sites. Community in both platforms is great, the difference is there is a core of extremely knowledgable people here at PW, and they are always willing to help. The willingness to provide assistance at the modX forum is also good and the users I found to be very friendly, but I found many users were not so knowledgeable and so the information provided was not of such a high standard. Sometimes actually just plain incorrect. These are just my observations, I hope they help. For the record, I really rate modX and it's developers, it's leagues ahead of many similar CMS/CMFs, but having now experienced PW for about a year I would not go back. No way. It's be like going back to using a 56k modem, so sad!1 point
-
Blog documentation up on my website. Focused on MarkupBlog. Decided to do them as PW lessons (hehe - kill 'em with one stone!)...99% done - just have to do some example Blogs. Thanks for being patient! <btw>Next lessons up - 'ProcessWire modules'. </btw>1 point
-
I have hard time understanding the real benefits redactor offers over ckeditor? I mean the acf, plugin architecture and already available plug-ins, inline mode, easy of settings/modification etc are very well done in ckeditor. Is it better looking and few kilobytes smaller? The size is not really an issue imo, since js is cached anyways. Also really pleased to see all the small improvements Ryan has implemented into ckeditor inputfield, which make the usage even simpler.1 point
-
hi jordanlev and welcome. processwire is so flexible that you could probably emulate all of your favorite features of Concrete5 very simply and quickly, using some custom modules... I started with Joomla way back in '06 and i probably still retain a couple of concepts that i liked about that system (they might have had 1-2 good ideas); for example i tend to favor building my own navigation system like Joomla does, since i always tend to need a ton of flexibility with menus and i can't deal with being tied to the page tree. likewise there are plenty of wireites who defected from modx but still retain some of the logic of how that system worked, and apply it to their PW workflow; Recently kongondo released a blog module that is sure to close the argument for any remote reason to mention wordprass*... I started helping a couple of clients build shopify sites, and after using that system, looking at their templating language and seeing the backend management, i was surprised because i thought it would be more advanced; a simple example is with PW's image handling, which in itself saves huge amounts of time; with most other systems you have to resize the images prior to loading them into the cms.. but of course the thought immediately occurred to me about how easy it would be to 'build' a clone of shopify with PW, maybe using the shop module and a custom admin theme... so i really appreciate you explaining the pros/cons of Concrete5, and what innovations, workflow benefits etc that it uses... and i think some people here on the forum will probably come up with suggestions for how to implement those things with PW; i think you'll discover that because the way PW is structured, you can typically accomplish the same thing in PW in about 1/10 to 1/20 the code. (I know this for a fact as i have converted a couple of really complex wordpress themes to PW and the code trash was quite significant).. *spelling attributed to willyC1 point
-
Hey people, look LOOK LOOOOOK at the latest commit on dev https://github.com/ryancramerdesign/ProcessWire/commit/36ec37d171672a1b786a554539cb5123b09117bc InputfieldPageTable now supports multiple templates for child items, so this is (at least for me) solving this issue. Hack away with you flexible page designs! :biggrin: CHEERS1 point
-
Hm, if I understand you correctly there is still not a way to do it as you imagined it. I'm assuming you want the ability for the editor to add groups of fields in the page admin and fill them directly there, a bit as having repeaters with individual templates (this was discussed before somewhere). You can go with Martijn's solution. Hanna code works very well. Or you can do the same directly in the page tree. --page two ----block one (template=text) ----block two (template=accordion) --page two ----block one (template=text) ----block two (template=images) ----block three (template=text) The editor would create a new page in the tree, and those block as children of it. To choose what kind of block, they would choose the template while creating it (you can limit the templates selectable for pages of this kind). To output it on the parent page template: foreach($page->children as $c){ echo $c->render(); }1 point
-
what.i use this is good it does.work top {not buttock}, of htaccess u will.put it . enjoy <IfModule mod_expires.c> ExpiresActive On ExpiresDefault "access plus 1 seconds" ExpiresByType image/x-icon "access plus 1 year" ExpiresByType image/jpeg "access plus 1 year" ExpiresByType image/png "access plus 1 year" ExpiresByType image/gif "access plus 1 year" ExpiresByType text/css "access plus 1 month" ExpiresByType text/javascript "access plus 1 month" ExpiresByType application/octet-stream "access plus 1 month" ExpiresByType application/x-javascript "access plus 1 month" </IfModule> <IfModule mod_headers.c> <FilesMatch "\\.(ico|jpe?g|png|gif|swf|woff)$"> Header set Cache-Control "max-age=31536000, public" </FilesMatch> <FilesMatch "\\.(css)$"> Header set Cache-Control "max-age=2692000, public" </FilesMatch> <FilesMatch "\\.(js)$"> Header set Cache-Control "max-age=2692000, private" </FilesMatch> <FilesMatch "\.(js|css|xml|gz)$"> Header append Vary: Accept-Encoding </FilesMatch> Header unset ETag Header append Cache-Control "public" </IfModule> <IfModule mod_deflate.c> AddOutputFilter DEFLATE js css AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml BrowserMatch ^Mozilla/4 gzip-only-text/html BrowserMatch ^Mozilla/4\.0[678] no-gzip BrowserMatch \bMSIE !no-gzip !gzip-only-text/html </IfModule>1 point
-
nice tip: if you remove "&showoptions=1" from the url, you will have only the list without the search options. So, a very simple example of a link would be: echo "<a href='{$config->urls->admin}page/search/?submit=Search&template=article&category=general_news&sort=created&display=title,path,category,author'>all general news articles</a>"; edit: here is a quite silly example of how this could be used dynamically in a custom page (code and screenshot): echo '<dl>'; foreach($pages->get(1)->children("include=all") as $p){ echo '<dt>'; echo $p->title; echo '</dt>'; echo '<dd>'; echo "<a href='{$config->urls->admin}page/search/?submit=Search&template={$p->template}&sort=created&display=title,path'>search all pages with same template as {$p->title}</a>"; echo '</dd>'; } echo '</dl>';
1 point -
@Diogo, I haven't had time to test the second version. Will do so sometime. Meanwhile, I have been busy playing with the module and here's a taster...a CRUD system for: a db external to PW (see video) PW pages (attached screenshots) Just fooling around at the moment. It is WIP as I learn the ropes of PW. In these examples I am using jTables. Will soon switch this to the great DataTables. Soma has a module of this one in the forums. Here I show how easy it is to implement using your module Many thanks for your awesome module!
1 point
-
1 point
-
Hm, I think I should indeed have a PW shirt printed, since I’m playing the ProcessWire missionary on the 1. CMS Night Nürnberg. Promotion is everything ;-)1 point
-
ProcessWire merchandise sounds great By the way, the PW media kit lacks of color definitions in RGB and CMYK. I haven’t included CMYK versions of the logo in my zip file, because I’m working with Inkscape – and I don’t trust its CMYK abilities. (Expscially since simple converting RGB->CMYK results in awful colors. You always have to use a suitable color profile.) But I’ll take care of this soon.1 point
-
It is possible $field2 = $page->field2; $result = $pages->find("template=something, field1>$field2"); Edit: ah hehe, ok this is what you're looking for. $results = new PageArray(); foreach( $pages->find('template=something') as $p) { if($p->field1 > $p->field2) $results->import($p); } Anyway have you tried your version if it would work?1 point
-
Sounds great, I look forward to seeing it. As promised, here's a full example of a simple contact form. This is bare bones, but safe. I've left out spam prevention measures, which I'll be happy to follow-up with if you'd like. Below is an entire template file. I figured it was simpler to show this way rather than splitting into multiple files. Though when forms get really large, I tend to split them in multiple files (and include them). But for smaller forms, I do it like the example below. /site/templates/contact.php <?php $sent = false; $error = ''; $emailTo = 'nikola@company.com'; // or pull from PW page field // sanitize form values or create empty $form = array( 'fullname' => $sanitizer->text($input->post->fullname), 'email' => $sanitizer->email($input->post->email), 'comments' => $sanitizer->textarea($input->post->comments), ); // check if the form was submitted if($input->post->submit) { // determine if any fields were ommitted or didn't validate foreach($form as $key => $value) { if(empty($value)) $error = "<p class='error'>Please check that you have completed all fields.</p>"; } // if no errors, email the form results if(!$error) { $msg = "Full name: $form[fullname]\n" . "Email: $form[email]\n" . "Comments: $form[comments]"; mail($emailTo, "Contact Form", $message, "From: $form[email]"); // populate body with success message, or pull it from another PW field $page->body = "<h2>Thank you, your message has been sent.</h2>"; $sent = true; } } if(!$sent) { // sanitize values for placement in markup foreach($form as $key => $value) { $form[$key] = htmlentities($value, ENT_QUOTES, "UTF-8"); } // append form to body copy $page->body .= <<< _OUT $error <form action="./" method="post"> <p> <label for="fullname">Your Name</label><br /> <input type="text" id="fullname" name="fullname" value="$form[fullname]" /> </p> <p> <label for="email">Your Email</label><br /> <input type="email" name="email" id="email" value="$form[email]" /> </p> <p> <label for="comments">Comments</label><br /> <textarea id="comments" name="comments">$form[comments]</textarea> </p> <p><input type="submit" name="submit" value="Submit" /></p> </form> _OUT; } // include site's main template which outputs everything include("./main.php");1 point
