Leaderboard
Popular Content
Showing content with the highest reputation on 11/15/2013 in all areas
-
You get a like for your response. (Do yourself a favour, invest some time in PHP. Starting is hard, the rest will follow!)3 points
-
Hi there, just launched a new website with ProcessWire! Here it is -> LINK Cya, devcow3 points
-
I have just pushed a new version of the module that supports "Load" rather than "Redirect" so the url that is entered which includes the 4 digit page ID will stay in the browser address bar. Not sure if this will suit your needs or not, but it was an easy addition so I thought I'd add it anyways.2 points
-
This module installs a page on your Setup menu in the admin where you can manage comments (assuming you have a comments field installed). Download from the modules directory at: http://modules.processwire.com/modules/process-latest-comments/ Features include: Easily find the latest comments needing approval or moderation. Shows comments from all pages on 1 screen, paginated and in chronological order. Enables you to change the status of any comment, edit the text or delete. Filtering by status/type, cite, email or IP address Screenshot: I've been wanting to build this for a long time, and something like this should have been there from the beginning, as it's a bit tedious to keep track of all your comments on a large site without this. So this module may be moved into the core for version 2.3, in which case it'll be renamed to ProcessComments, so as not to conflict with those that may have this installed.
1 point -
Hey guys, I'm new here, and I'm loving ProcessWire and the community spirit so far. We're just about to start using ProcessWire for our new clients requiring PHP solutions. Moving in a Rails direction, structure in our projects is becoming more and more of a necessity. As such, I've tried to employ some MVCish techniques in creating a boilerplate for ProcessWire for getting projects going quickly. One of the primary goals of this structure is to make it easier to separate logic from markup, and to prevent tags from being split over templates. Keeping `body`, `html`, and structural markup open and close tags in the same file greatly reduces cognitive overhead, and reduces opportunities for mismatching tags to exist. This approach also reduces duplication, and is great for keeping files small, focused, and organised. The main structure of the boilerplate is well defined, and ready to use in production. The repo is available here: https://github.com/fixate/pw-mvc-boilerplate (link updated 2014/01/17) Structure Although not completely MVC (using classes for controllers feels redundant, there are no models, and a full MVC approach will require a fair amount of customisation), it is heavily MVC inspired. Additionally, the structure is an extension of Soma's delegate approach. File structure: ├── site ├── assets ├── modules . . . ├── templates // boilerplate contents here ├── assets // css, js, fonts, images, etc. ├── controllers // variables and functions specific to templates ├── errors ├── partials // markup not specific to any particular template ├── views // layouts specific to a template ├── _init.php // used to load global and template-specific controllers ├── main.php // the 'alternate template' for all templates . . . **NB: This structure has largely been updated and improved - see the UPDATE - 2014/01/17 at the bottom of this post! Controllers Controllers hold template specific variables and functions. There is also a global controller responsible for making global fields, such as SEO fields, available everywhere, as well as being responsible for the actual delegation. Template logic should be handled as much as possible from within controllers. Views Views are responsible for handling markup and output. Views have available to them both the global controller, and their own controller. Logic should be, as much as makes sense, handled in a controller, with the view pulling the results in for display. Partials Partials hold markup not specific to any particular template on its own, such as the `<head>`, header, navigation, scripts, or footer. As with views, it is best to keep these as logicless as possible. _init.php _init.php is responsible for making controllers available to views. Controllers are only included if they exist - sometimes a template-specific controller may not be necessary, in which case you won't need to create one. main.php main.php is the default layout (equivalent to layout/application.html.erb in Rails) into which everything is rendered. This file has been kept small deliberately to let partials and views manage more fine grained markup structures, while this file serves the main site structure. A call to render_view(), defined in global-controller.php, is responsible for delegating rendering to the view of the current template. Additionally, there is a constant defined in globals-controller.php useful for serving different assets depending on if you are working in a local environment, or if your site is live. This is useful for preventing Google Analytics from running in a dev environment, or for using unminified scripts for debugging. This boilerplate eliminates the need to do much configuration when beginning a project, apart from having to change each template's alternate template in the admin. I hope this will assist in quickly organising and developing new projects! ------------------------------ UPDATE - 2014/01/17: ------------------------------ All files for rendering are postfixed with .html.php in good ol' Rails fashion. main.php has been removed in favour of mvc.php. mvc.php requires config/boot.php which then handles which controllers, views, etc. are used the main layout is now found in views/layouts/application.html.php - like Rails again. partials are now kept inside views/ each page template can have its own optional controller, or simply inherit functionality only from ApplicationController ├── site ├── assets ├── modules . . . ├── templates // boilerplate contents here ├── assets // css, js, fonts, images, etc. ├── controllers // variables and functions specific to templates ├── core // core mvc files - base controllers etc. (project specific stuff does not go here) ├── errors ├── views // folder for template files, layout files, and partials ├── layouts // application layout ├── partials // markup not specific to any particular template ├── mvc.php // the 'alternate template' for all templates . . .1 point
-
Lately there have been lots of people that are not enjoying the default admin theme, so we've been working on making something new. Not trying to solve all issues or add every new feature we'd like, but just trying to come up with something to have as an interim replacement for the default admin theme until we can afford the time to do something broader in scope (like Phillip Reiner's great admin theme design for example). So this theme doesn't necessarily break a lot of new ground, but hopefully has some of the improvements that people are looking for. Visually, the goal here was to find a lighter, more modern look and reduce the boxes-in-boxes feel of the current admin theme. I've opted to commit it to the dev branch because it requires the latest version of ProcessWire on the dev branch, and likely will continue to with updates. Meaning, I can't distribute this one as a 3rd party theme very easily. This is because I'm making core updates related to the admin theme at the same time. So if you want to help test this new theme, you'll need to grab the dev branch of ProcessWire. The new admin theme is in /site-default/templates-admin/. That means you'll see it as the default theme if you are installing a new copy of PW. But if upgrading an existing copy, you'll continue to get the old theme. If you want the new theme, then just copy the /site-default/templates-admin/ directory to your /site/templates-admin/ directory on your existing PW install. This would be in addition to replacing your /wire/ directory with the latest one from dev, as usual for PW upgrades. The existing default admin theme also remains in place in /wire/templates-admin/. So if you want to stick with the existing/stable admin theme, then just make sure you don't have a /site/templates-admin/ dir in place (unless you are using a 3rd party admin theme). This admin theme is probably not production ready, as it's not been tested in many browsers yet. I personally haven't yet tested it in anything but Chrome and Firefox in OS X. Please let me know if you experience issues in other browsers. I fully expect things won't be pretty in IE... but they never are. To start, this comes with 3 color schemes (though we'll be adding more too): Warm: Modern (similar to processwire.com site colors): Classic (similar to existing admin theme colors): To switch to one color theme or the other, specify a GET variable of 'colors' in any URL you are accessing in the admin: /processwire/?colors=warm /processwire/?colors=modern /processwire/?colors=classic To specify a default, edit your /site/config.php and set to one of the following: $config->adminThemeColors = 'warm'; $config->adminThemeColors = 'modern'; $config->adminThemeColors = 'classic'; We'll probably make this switchable in the user profile at some point, but that comes later. This theme also comes with some new features (most of which have been copied/inspired from the work of others here, whether in other admin themes, modules or designs): It now uses Font-Awesome icons rather than jQuery UI icons. We now only use jQuery UI icons for actual jQuery UI widgets. Note that asmSelect and our file/image inputfields are built as jQuery UI widgets, but I don't think anything else is. Basically, the majority of icons in the system are now Font-Awesome icons. You can associate Font Awesome icons with templates. When associated with a template, the icons will appear in the page list, in front of the page title. To use this, edit any template and go to the Advanced tab. In the "List of fields to show in admin page list", you can type in any Font Awesome icon name (in addition to the field names you could before). For example, in the Page List screenshots above, I have my "search" template configured with the value: "icon-search title". You can associate Font Awesome icons with fields. When associated with a field, the icon will appear at the beginning of the input. For example, I associated a coffee icon with my "title" field in the screenshot below. To do this, edit the field, click on the Advanced tab, and enter the icon name in the new field provided for it. The top navigation now supports simple dropdowns. A new "user" dropdown has also been added that contains profile and logout links. The main Pages screen contains an "add new..." button, that is itself a dropdown to a list of templates that are configured adequately for us to know where they would be added. To use this, you have to configure your template "family" settings. The search box is now ajax powered, though this was introduced a couple weeks ago in the existing admin theme too. The theme is responsive too, of course. This is all kind of preliminary and open to changes. I'm trying to keep the scope of the project fairly small since I don't have much time to work on it. But just wanted something to quiet the haters a bit for a little while, so that we can take our time on the bigger admin theme project for longer term. We'd appreciate your feedback if anyone has time to help test.
1 point
-
ProcessWire Site Profile Using Zurb Foundation 4 This is a drop-in replacement for the default ProcessWire site profile. See the live demo at: http://processwire.com/foundation/ It is mobile-first and fully responsive, capturing all the benefits of Zurb Foundation 4. Ready to be expanded upon with built-in support for deeper levels of navigation nesting in the sidebar. Pagination ready with Foundation-specific pagination output, when/if you want it. Improved search engine, relative to the basic profile. Library of Foundation-specific markup generation functions included, primary for generation of navigation (in _nav.php). Uses ProcessWire 2.3+ prepend/append template file settings making it easy to work with. It is largely stock Foundation 4 in terms of look and feel, with a few tweaks. To Install Download this profile from GitHub or mods.pw/4u. Start with a copy of ProcessWire 2.3 or newer, and its default site profile. If starting with an uninstalled copy of ProcessWire Replace the /site-default/templates/ directory with the templates directory from this profile. Replace the /site-default/config.php file with the config.php file from this profile. Run the ProcessWire installer. If starting with an already-installed copy of ProcessWire Replace the /site/templates/ directory with the templates directory from this profile. Add the following two lines to your /site/config.php file: $config->prependTemplateFile = '_init.php'; $config->appendTemplateFile = '_main.php'; Desktop Screenshot Mobile Screenshot1 point
-
I'm really please with my first attempt at a site: http://www.garagesalefinder.co.uk It uses the map module which was fairly easy to implement; Uses the simple news tutorial which I've also adapted to make a cool links block; Uses a Pete's email to page module that I've also adapted to feed straight into the simple news tutorial; Anyway, I'm very pleased with my first little project Thanks to everyone who has helped me on the forum1 point
-
Had fun to create a webfont with only one single glyph: Processwire-Logo Unicode-Letter: (Unicode Block "For Private Use") I created first an svg with inkscape and created the font-set with http://icomoon.io/app (very nice website!) Like it, use it, waste it. font-package with demo file here: attachment=1836:processwire_webfont.zip updated 23.11.13 (4 Glyphs: 'processwire', 'process', 'wire' and 'w') processwire_webfont.zip
1 point
-
Hi, There is a section of a new website I'm building where there is a need to publish longer form articles, where I intersperse paragraphs of text with images, quotes, videos, and galleries. I'm wondering if anybody has a good approach for constructing this kind of article in ProcessWire. I was originally using a TinyMCE field to embed my images in the correct place in the flow of the body text, with the float classes floating the images appropriately. Including other types of content such as videos and galleries looks a little bit harder to manage, and I can only thinking of including strings to match on in the body text and replacing them in the template, which isn't quite as user friendly as I'd like. It's also a bit of a nightmare to make it work with Susy Compass plugin which is handling the responsive grid. My other idea was to include a repeater field, with each field including optional places for paragraphs of copy, galleries, videos etc. However this doesn't feel that natural, and it's difficult to make the text flow from section to section. Does anybody have any ideas about a good solution for this kind of article? Many thanks.1 point
-
No problem at all - happy to help. I just pushed another small update that adds a canonical link to the page if you are using the new "Load" option. This is to help identify the ID based URL as a duplicate of the proper PW url so Google etc won't penalize you for duplicate content.1 point
-
Hi adrian, This is awesome you added this and so quickly! I think it will definitely do the trick. I looking forward to digging into the module to see how you are adding the page id to the url. Thank you for sharing and adding the addition.1 point
-
Seems to be working perfectly now - thanks. Awesome new functionality!1 point
-
Late to the party, but may I suggest superfish.js? Does wonders for my dropdowns! I'm so excited about the changes you've made, Ryan! Can't wait to try it out.1 point
-
Thanks Adrian, I decided to just use the Google Maps API and the values created by the ProcessWire module to assist in that. I used the visibility: off for the POI and that worked. Thanks.1 point
-
I don't really have an answer for you, but I think it would be worth your time to read through this thread: http://processwire.com/talk/topic/4189-flexibility-in-page-design/ Lots of good ideas and even an alpha version of a module that soma is working on that might be helpful for your needs.1 point
-
Oh yes it is. It is showing '2' on the first line. Indeed, I named 'admin' for the default superuser when I installed PW at the first time. I guess this is why I got stuck. Thank you so much to help me, adrian. =D1 point
-
You should not modify files in the /core/ directory - they get lost when updating Pw Go to Setup > Fields > your_field > Input > TinyMce Advanced Configuration There you can set your style attribute to valid elements.1 point
-
Hi RJay Each page in ProcessWire has a unique path - this one is solved. As for the digits, you can enter some in the page name. To add for example the creation date of the article automatically to the name field, you could use a hook that hooks after saving the page, then modifies the name attribute.1 point
-
I haven't used it but it seems that http://processwire.com/talk/topic/4611-redirect-id-based-urls/ would be a possible solution. I'm sure Google has a reason for the 3 digit requirement but it seems strange to me...1 point
-
Just found this thread: http://processwire.com/talk/topic/1920-processwire-logos-download/ - Michael van Laar did the vector work for the logo. I actually don't think there will be a legal problem with making a font of it: As long as you don't alter it to say "mySuperAwsomeOwnCMSWire" it's used as intended (for branding pw instances). I think the best way to implement this would be ligatures (process and wire) as well as the letter "w". There is an option in iconmoon to do this: you can just upload 3 .svg graphics, select ligatures from the options menu, enter process for the first ligature and wire for the second and there you go (in fact i already did that for my theme yesterday ).1 point
-
If the template where the pdf's are stored is not viewable by the guest role, then you can set $config->pageFileSecure to true. Then only roles that have view permission to the template are able to access the files directly.1 point
-
I would fully expect those guys to come up with a pretty implementation for matrix fields. After all, aren't they the ones that wrote the EE matrix fields plugin? I think that matrix fields make good eye candy, and provide a quick n' dirty way to solve some things in lieu of real structure. But I don't think they are great for the long term or large scale. I'm much more interested in creating timeless tools with well defined data formats and structure, and separating our clients from getting involved with defining schema. I can see the solution presented there being a bit of a monster as the format of data becomes more ambiguous than a rich text field (chances are it actually isn't much more than a rich text field from the storage end). Chances are that data can't be indexed, searched and plucked field-by-field the way ProcessWire's repeaters can. But I haven't actually used it, so maybe I'm making assumptions from what I see on that page. Such things would certainly be possible in ProcessWire, but I'm just not convinced it's right. I can see why the Craft guys are doing it, because they are trying to sell stuff and candy sells. Whereas we're trying to make the best, most sustainable tools for the long term and large scale... the meat and potatoes rather than the candy. So something like this from Craft is not something to "catch up" to, because their bottom line is to make candy you will buy, not on providing what's really the best. My full time job is to develop web sites and applications that use ProcessWire (rather than to sell you something), so I'm simply not interested in colorful gadgetry and instead want the best foundation of quality and substance, at least when it comes to the core. Matrix fields and repeaters are somewhat at odds with that goal (even ours to some extent). These types of fields should be used occasionally and sparingly, for specific purposes. As it is now, I don't personally use repeaters very often. Half the time that I see people using them, they are being used in situations when the person really would have been better off without them. So I'm not so enthusiastic about pushing the core further in encouraging use of repeater/matrix type fields, when I don't personally use them very often, nor do I often recommend them. Don't get me wrong though, I do like candy too (sparingly), but really want to limit it in our core. When you get down to the core, Craft doesn't hold a candle ProcessWire. But I'm always glad to support whatever people want to build as 3rd party modules, and ProcessWire is a good engine for this.1 point
-
If you are still looking for a nice solution. Let PHP do the work for you. Try this: PHP Tidy (its included in PHP5) Example: <?php $html = '<ul><li><h2>Chaos</h2><p>here comes the stuff</p><li><h2>Philosohie</h2><p>I love nice source code</p></li><li><h2>next Listpoint</h2><p>Help, got lost in indentation</p></ul>'; $tidy_options = array('indent' => 3,'output-xhtml' => true); $tidy = new tidy(); $tidy->parseString($html, $tidy_options); $tidy->cleanRepair(); $body = $tidy->body(); // Output echo $tidy; /* Output <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title></title> </head> <body> <ul> <li> <h2> Chaos </h2> <p> here comes the stuff </p> </li> <li> <h2> Philosohie </h2> <p> I love nice source code </p> </li> <li> <h2> next Listpoint </h2> <p> Help, got lost in indentation </p> </li> </ul> </body> </html> */ more Information: http://id1.php.net/manual/en/book.tidy.php http://tidy.sourceforge.net/docs/quickref.html#indent-attributes1 point
-
ProcessWire 2.4 (2.3 dev) also has the ability to install modules, check for updates, and and update modules individually, pulling from the modules directory. It uses the same method as ModulesManager (actually Soma's code for the most part). But ModulesManager has a nice advantage in that it can check for updates on all your installed modules at once.1 point
-
Hi tina, Sorry for the limited answer - was in a hurry. Actually looking at this module a little more, I realize that I have never used the built-in render, but rather just used it as a way to enter addresses in the admin. I have been using Ryan's RCDmap class: http://processwire.com/talk/topic/690-map-marker-fieldtype/?p=10667 Although I actually haven't hidden the poi in any PW sites yet, so I don't have a final code snippet for you. However, this is the code that I used on a mobile site I developed that made use of: https://code.google.com/p/jquery-ui-map/ var myStyles =[ { featureType: "poi", elementType: "labels", stylers: [ { visibility: "off" } ] } ]; $('#map_canvas').gmap('option', 'styles', myStyles); I wouldn't necessarily recommend jquery-ui-map - I thought it might be worth trying, but mostly just seemed to add another layer of complexity. I think I would stick with the standard gmaps api. Here is a relevant POI link from google: https://developers.google.com/maps/documentation/javascript/reference#MapTypeStyleFeatureType Hope that helps.1 point
-
Thanks adrian, The advantage of the javascript truncated option is a visual response for the editor. He can see how many characters he has left. I wanted this for a Meta Description field. Also used it in an intro text telling 400 characters gives the best visuals, but 500 are allowed. Then when there are 100 to go. The editor knows it's looking good. Truncate will truncate when the limit is reached, the unchecked option will revert to the old text previously inserted.1 point
-
Hi dazzyweb, This module should take care of your needs: http://modules.processwire.com/modules/textarea-counter/1 point
-
2.4 is not PHP name-spaced. I got started with it and realized it was going to create headaches for many web developers having to namespace all their template files (not to mention modules). This is extra baggage that most of our audience would not appreciate. So I've put it off to one of the next versions when I can find a way to do it that doesn't require gratuitous verbosity to people's template files. I think that's possible with a built-in template compiler, but that's a bit more work than I was looking to get into for 2.4. If for some reason that doesn't work out, then we'll pen the namespace change to PW 3.0 when a major version would be more amenable to an upgrade that may require changes to one's template files.1 point
-
That "$page->child->children->children" is the issue here; $page->child is a Page, $page->child->children is a PageArray and you can't ask for children of a PageArray. PageArray contains Pages, each of which has children -- PageArray itself doesn't have children. You'll have to iterate over all contained pages one by one and ask for their children <?php foreach ($page->child->children as $children) { foreach ($children->children as $child) { echo "<h1>{$child->url}</h1>"; } } ?> Does this make sense to you?1 point
-
I just thought of yet another approach to flexible page design: Repeaters and the new Field Dependencies. So you set up a couple of block types via a page select (text with image, three columns text, employee, gallery or whatever blocks you want to use), those options are available in each repeater item and according to what is selected you show and hide fields within the respective repeater item. Then in the template you can use the new option to pass alternative template files to a page to render the blocks: foreach ($page->repeater as $repeaterItem) { echo $repeaterItem->render("blocks/{$repeaterItem->type}.php"); } This might be closest to what I would expect from patching a flexible page layout together.1 point
-
Nice! Would you mind creating three other glyphs? It would be nice having "process" and "wire" as two seperate glyphs as they are often coloured differently. Also the "w" from wire would be a nice addition to do a "picture sign" for navigations.1 point
-
Thanks for the feedback. Yes I get that users like to see what they get, but you get it when viewing/editing the blocks (click on asm list label name) and on front-end when go preview the page (unpublished pages are viewable by editors). I think it would a small price to pay for blocks in a scalable manner, easy to deal with and sort them. And as said front-end editing is something that should be considered a lot since PW makes it so easy and clients usually like it. I have also mixed feelings and am somehow aware of drawbacks and issues to could lead to. Also misuse of this, either by the developer or by the user. At the end it all comes down to what do you need to solve with this? And does this lead to bad websites/Use of it (I think most of times yes!) Currently I see it like this: My module pros - minimal easy setup - scaleability - reuse fields and blocks (would requires some complex config setup but possible) - blocks are pages - can use repeaters ... cons - no direct inline editing (if a concern at all) - don't see a way to search via simple API selectors (would require special workarounds, a lot of work) - not easy to limit and reuse things, a lot of work would need to be put in module (grows complexity) ... Using repeaters with conditionals (if supported by PW at some point) pros - easily create different repeaters with different types - inline editing - able to use in simple search API selectors (repeater.field) - repeaters are pages ... cons - doesn't scale as good - some larger setup required - not able to reuse fields and sets created in a repeater - dependency on repeaters - can't use repeaters (inside repeaters) ... and not to leave out already possible approach Using child pages pros - straight forward adding them, almost no setup - preview and editing easy possible on front-end - no dependency - reuse fields, template, and content - they are pages ... cons - no inline editing, different approach (but clients usually get this easily) - could interfere with other child pages (although this can be solved if you put them in a global branch and append them using page selects) - needs workaround for searches using API (but easier as they're direct childs) ... somehow After all I'm looking also further and question things like: what about future major features PW maybe introduce and support in future? Import-Export, versioning, drafts etc. Ever thought of that? Currently I don't know where all this leads us. As said this current module only shows a proof of concept and it maybe one possible to further develop. But first I want to make sure it would be the way to go. I think to use pages in some or other way is a good way to go as you benefit from all features a page can have with all it's API, without relying on a new proprietary system. So this is maybe more what's behind it and more technical, but I think I would love to hear other developers to look and think about this.1 point
-
It's a leftover from the old admin theme (I didn't create these files from scratch). You are right, we can drop this left/right padding as there isn't any need for it. Also a leftover from the old admin theme. In 2009/2010 there was still a little bit of lingering IE6/IE7 bad habits–which meant using absolute positioning when floats were more appropriate largely because IE was not consistent with floats. Obviously that's not the case anymore. I think your suggestion to change these to floats makes sense. Though also not sure it really matters much in this case, but I do prefer floats from the responsive side, so that's a good enough reason. Your screenshot is too bold for my taste, but maybe it makes sense for one of the color themes to take a bold approach like this. I understand that very often what looks better depends somewhat on how the platform and hardware/screen render type, so it's good to provide options. I'm not familiar with the outline you are talking about (Chrome OS X), but will try it out and add it if it provides some benefit in Windows or another browser or something. Kind of depends on the screen, it's quite visible here. But I see no harm in increasing the value. It's preferable to do it with padding rather than line-height since it's possible for long titles to wrap, and we want wrapped titles to still look like a single item. But I am not a fan of increasing the padding or line height here, as it just means a lot more scrolling on the sites I work on (which tend to have lots of pages). Again though, I see no problem with providing this as an option in one of the color themes if people find it more attractive. I find it less attractive myself, but it's all subjective. I think a good goal here is to support a broader range of preferences by providing more options, and so this may be one of them. ProcessWire is not a corporation so we don't have corporate colors. But we do have brand colors, and I think we will stick to them for our branding and marketing. But I'm feeling like the application itself should be less branded... would rather have people think of it as a tool like their text editor. It bothers me that a seemingly large group of people have ignored ProcessWire largely because they don't like the way the admin looks. And the colors are one of the first things mentioned. Many of potential audience thinks they look childish: light blues and pink, which are also known as baby boy and baby girl colors. I like the colors myself (a lot), but have heard it enough objections to know it's not an isolated opinion. Those people aren't here to tell us about it in the forums because they were turned off by subjective things before they got to know why it would be a great tool for them. So I wonder if the admin needs to be more neutral and not defined by colors or brand, but by its usefulness as a tool. I want people to focus on the tool and not on the colors, because the colors really have nothing to do with the tool at all. While there has to be default, it should be fairly neutral and easy to change. Ideally it would be selectable from the installer so that it's clear from the beginning that it's a tool to get stuff done more than a brand to buy into. By the same token, I wonder if there shouldn't even be a PW logo in the admin, or if we should make it something the user can easily replace with their client's logo. With regard to color schemes, I'm also hoping some others here that are better at it than me will put some together. I think I've setup some good starting points that I like, but colors are always subjective. I think someone else can do better here, so I've tried to make it as easy as possible by isolating all the components of the color scheme in a separate file that can be changed easily. So if anyone is interested in experimenting with colors, please do and post your results when you've got something that you think looks good. These are standard jQuery ui-menus, which are meant to follow the scale of select boxes (I think that's what they were trying to do anyway). I'm not yet sure if I can make major adjustments to them without affecting other jQuery UI widgets that I don't want to, but I can experiment. However, the plan is that these will descend another level for templates and fields (which can potentially include a lot of nav items) so I think it has to be a careful balance. This is something that I can confirm is very much affected by your screen. I have two screens connected to my computer, and I can barely see the lines on one of them, while the lines are nearly too dark on the other. So what you see now is a compromise between the two in finding the right darkness level for them, based on my own screens. No doubt we'll want to provide higher contrast options here in one or more of the color themes, to account for these variations. But rather than basing it on my screens, it would be good to hear from more people to see where the right balance is for visibility of the box lines. I've tried it both ways. To my eyes it looks whiter, but not cleaner. It's subjective of course. My personal preference is to have a color, a line or something to make navigation part of an interface with visual hierarchy that rather than free floating. But I think it doesn't hurt to experiment here in one of the color options. I actually thought it worked ok that way when testing it in the Modern color theme. I don't think we can legally connect an admin theme with my TypeKit account. Maybe there is another resource we can use for this, but it's got to be something that doesn't require connecting to an outside service. The typeface also has to be one that is fairly generic. Arial is about perfect IMO due to it's anonymity... keeps the focus on the content without the type influencing the personality or suggesting style. The goals in the admin are entirely different from the goals on the marketing/brand site we're on now. Arial doesn't do anything for me (which is partly why I think it's a good fit in this case), but if we can find something that has similar characteristics while looking newer or more professional, I think that would be a desirable thing.1 point
-
@adamspruijt, yes please submit any feedback you'd like, that's what this thread is for. I would just request that any feedback be based on actual use/testing the theme itself rather than the screenshots, as the screenshots are fairly limited in scope relative to the theme. We may have to wait to act on some of the feedback until we approach the bigger admin-theme project in the future, but all feedback is appreciated either way. For instance, if there is a consensus that the page list actions are too small, I'll be glad to increase the default size of them. That's also a fairly simple thing to do. Chances are that the value in your session was already set to something, and the session value overrides the $config value. To resolve that, just set your session value to match the $config value, or clear out the session value by specifying an unknown color theme. /processwire/?colors=classic /processwire/?colors=poopst I'm not sure that I like the sound of that, but if you mean post a color theme file here that's great.1 point
-
For those interested for now, I created a github repo along with some description how to install and use it: https://github.com/somatonic/BlocksContent Thanks1 point
-
Coming back to this. As mentioned I'm hard thinking a brewing something since a long time, just haven't been able to pull it off yet. It's often good to wait and sometimes it just makes click, also growing with PW and it's ability can make a big difference. Yes even I am still learning, I got something I think would be a good way to build flexible content blocks, it's just not that far yet to really release it. What Ryan has proposed with iframes sound good in theory but I think would be not a good option at all. It could work but I'm not excited about it because of scalability in the admin, scrolling etc and it would be more of a mad hack with JS IMHO. But the idea with using a page field made sense to me and I was thinking a lot about how to bring the concept I have to the admin, so you can add and edit "blocks" on the page. Until now I only got a really rough proof of concept and was working on front-end only, and not at all complete so you could add blocks etc (I created them manually) After some more testing and coding: So far this is how I got it setup/working: (much like repeaters work) - you create templates for the blocks (partials kinda) - you create a template for the parent page of the blocks in the admin, where you also use family settings to restrict children template to the block templates you create Backend - the module creates a custom page field using the input ASM select multiple, you then add to templates you want to have those blocks - the module sets up a parent page in the admin branch for the page you create with this field - the module hooks into the ASM select to add a "+ Add new block", with a click you open a modal where you have the add page screen and template select. Once create you close the modal and the ASM select will have that new option added. You can sort them as usual - the module enables the editlink modal for the selected blocks (much like selected fields on template context) Front-end - the module uses Fredi and it's own script and markup you can use to render the blocks (simply: echo $blocks->render() - the partial templates are located in a subfolder /blocks where you script the output same as you would with a normal template - the blocks have a little toolbar you can move blocks up and down (saved on the fly via ajax), and a Fredi edit link that lets you open and edit the block in a modal - the idea is that you also could also output the blocks manually As said this is all still rough and slowly taking shape, and many details still need to be taken care of, but just wanted to mention. I think a alpha/beta testing is possible very soon but don't want to make it public until it's more marinated and stable. Also if somebody interested in helping out drop me a message.1 point
-
Like it - nice additions One thing I was thinking about a while back was being able to maybe use a colorpicker to select 3-4 primary colours and have a module save those to a CSS file so the admin colours could be changed easily. Might be something worth considering time-permitting? Obviously you can end up with some pretty garish colour schemes that way so would be one for superusers to control I think.1 point
-
I can donate a couple of hundred euros as an incentive, if someone will work on this. No specific requests from my part, just follow the PW philosophy.. and maybe research emerging solutions like Discourse and Moot for inspiration.1 point
-
Hi celfred, You could easily add the checkbox field to the page yourself. Create a new field called: "disable_comments". Choose checkbox as the fieldtype. Add this field to the required template. In your template have some code like this: if($page->disable_comments !== 1){ echo $page->comments->render() . $page->comments->renderForm(); } That should be close to what you need!1 point
-
Thanks kongondo, and to all those who monitor this forum and take the time to reply w/solutions.1 point
-
I think this type of thing would be a very different animal from a repeater. While there are similarities, I think the functionality would be a lot simpler to build as its own thing rather than extending repeaters. Not to mention, I'm not sure I'd want to add that complexity to repeaters either. I can't envision a use for this type of field in the sites that I build for my clients, so I'm not likely to build it. But I can see how others would find it useful, I do agree that the idea is fun and interesting. Here's how I think it could be built without getting too complex: The Fieldtype itself would basically just be a FieldtypePage and may not need to be anything more. The Inputfield would be where all the action would happen, and I think a lot of it would be JS fun more than PHP code. When you click "add", the Javascript would append an <iframe> with a "src" attribute pointing to /processwire/page/add/?parent_id=123&modal=1 where "123" represents the predefined parent_id where these pages would go. That "modal=1" in there tells PW's admin to just display the editor and no header/footer, etc., making it perfect for this particular Inputfield. The "add" screen would prompt them for the template, as it already does, and let them add the page there. You could of course restrict the allowed the templates the usual way in the template family settings. Some JS would also have to be used to communicate between the <iframes>s and the parent window. Specifically, when the Save button is pressed in the parent window, you'd have JS trigger the save buttons in the other iframes (which you might choose to hide with JS/CSS). Likewise, JS would need to be used from the parent frame to examine the ID of the iframe/repeater items so that it could be saved to the FieldtypePage. There wouldn't be any need to add new API level stuff, because I think that what's provided by FieldtypePage already provides what this field would need. There would be some other issues to resolve as well, but ultimately the whole thing would be simpler to build than the repeaters if the author is willing to take advantage of iframes.1 point
-
Being able to compose a page of individual blocks on the fly has been requested a couple of times now. I remember asking for something similar some time ago (click). I think the obvious and most comfortable solution would be that repeaters have no fields attached to them but rather templates, or only one template to have the same functionality as we have now. One step further would be that one is able to attach more than one template to the repeater, and then while creating content when you click add item a drop down appears with the template names you added. You choose a template and the next repeater item contains the fields of that chosen template. Next item could be another template and so on. This would be awesome. I would create this kind of behaviour with a module/fieldtype but my knowledge of pw module development and the related api work is not sufficient yet. Sure this kind of structure can now be created with subpages but this is not convenient for clients, since they don't have all the content on one page. One argument I've seen a lot is that there is too less of constraints for content creators/editors so they would mess up things or go nuts with laying out content. But the developer can exactly define which templates are assigned to that repeater. And those individual blocks/templates are very much under control of the dev so I strongly disagree with that argument.1 point
-
great, +1 stupid question for me thanks1 point
-
That's something that we already have, as the comments appear in the page editor for every page. The purpose of this module is to provide all the other possible views. Though it could be said that this interface is better for managing comments in general, so we may eventually make it the standard and keep them out of the page editor. This is in part because the page editor doesn't scale well to situations where you start having hundreds of comments on a page. It'll work, but it's not designed for pagination, whereas the Comments Manager is. So a page-level filter probably will be coming to the Comments Manager.1 point
-
@bcartier: The ImportPagesCSV-module can't do this as is. But I tried making a tiny addition to make it support FieldtypePage (those used to make page references) and it worked amazingly well. The only change needed was to add 'FieldtypePage' to $fieldtypes array (just before init() function if you take a look at the module file), like this: protected $fieldtypes = array( 'FieldtypePageTitle', 'FieldtypeText', 'FieldtypeTextarea', 'FieldtypeInteger', 'FieldtypeFloat', 'FieldtypeEmail', 'FieldtypeURL', 'FieldtypeCheckbox', 'FieldtypeFile', 'FieldtypePage', // add this line ); After that addition it's possible to choose a Page field when connecting the fields from the CSV to the ones in the chosen template. I had pre-populated categories at the target site and used their id's in the CSV file to reference those categories. Multiple categories worked like a charm as well, just use a pipe in between id's (123|456|789). Moreover, if you've got only one category per entry to reference, then you don't even need the id's of the categories - you can use paths as well. Here's a little example: cat.csv: title one two three four entries.csv: title,categories a,/cats/four/ b,/cats/three/ c,/cats/one/ d,/cats/two/ Import cat.csv using a template for categories with (at least) title field, under a page at /cats/. Then import entries.csv using a template for entries, having a title field and a page field. This should leave you with entries that are connected to categories. I hope this gets you somewhere. @ryan: Looks like page references could be supported very easily. I just used this successfully to import ~3500 pages with category references from an old site to a new PW one. But maybe there's still something else to be done before they're fully supported?1 point
-
Nice one Ryan - PW just keeps on getting better!1 point
-
Thanks guys! I started using thomas' suggestion when I read it, and it works great. It's not perfect but at least most of it is properly aligned. I guess I have to let it go and stop worrying about indentation. Although sometimes, I really have to, because I teach part-time and I want the students to be able to read my examples easily. And yes, I'm introducing processwire to my students, instead of joomla and drupal which other schools usually use to teach cms. So there's hope that future web developers would be using processwire more and more! Thanks again!1 point
-
I figured as much. I just thought you guys we're using an easier technique because most sources I've seen around are perfectly indented. Thanks! I'm new to processwire, barely 3weeks, and yet I've already used it for two websites. The only thing I love more than how powerful this CMS is, is how helpful and friendly the community is. I'll be sticking around for sure, and try to help whenever I can!1 point
-
Thanks for posting Soma, this is an interesting approach and not one I've seen before, but it looks great. The underlying concept and result is similar to the approach I usually use. Since you posted a good description, I'll try to do the same for mine. The only reason you see head/foot files in the default PW profile is because it seems to be simpler for new users to grasp. But I almost never use that approach in my own sites. Like your system, I have a main.php file which is my main markup file. But unlike your system, main.php is included from all the other template files (rather than main.php including them). The other template files focus on populating the key content areas of the site, specific to the needs of the template. Examples of key content areas might include "main" (for center column/bodycopy) and "side" (for sidebar/related info), though often includes several other identified areas. But I'll keep it simple in this case. Here's how it works: basic-page.php <?php $outMain = "<h2>{$page->subtitle}</h2>" . $page->body; if($page->numChildren) $outMain .= $page->children->render(); // list the children $outSide = $page->sidebar; include("./main.php"); main.php <html> <head> <title><?php echo $page->title; ?></title> </head> <body> <h1><?php echo $page->title; ?></h1> <div id='main'><?php echo $outMain; ?></div> <div id='side'><?php echo $outSide; ?></div> </body> </html> The benefit of this approach is that basic-page.php can setup whatever it wants in the key content areas ($main or $side) whether simple like in this example, or something much more complex. I actually prefer for the variables representing the key content areas to be optional. In the scenario above, $outMain and $outSide would have to be defined by every template or they would end up as uninitialized variables in main.php. As a result, I actually use $page as an anonymous placeholder for these variables (making sure they don't conflict with any existing field names) and then let main.php assign defaults if the calling template didn't specify one of them. For example: basic-page.php <?php $page->outMain = "<h2>{$page->subtitle}</h2>" . $page->body; if($page->numChildren) $page->outMain .= $page->children->render(); // list the children // note: no $outSide specified include("./main.php"); main.php <?php // setup defaults when none specified if(empty($page->outMain)) $page->outMain = $page->body; if(empty($page->outSide)) $page->outSide = $page->sidebar; ?> <html> <head> <title><?php echo $page->title; ?></title> </head> <body> <h1><?php echo $page->title; ?></h1> <div id='main'><?php echo $page->outMain; ?></div> <div id='side'><?php echo $page->outSide; ?></div> </body> </html> Final thing to point out here is that main.php is the only template actually outputting anything. Because basic-page.php (or any other template) is determining what's going to go in that output before it is actually sent, your template has the opportunity to modify stuff that you might not be able to with other methods. For instance, the <title> tag, what scripts and stylesheets are loaded, etc. Here's the example above carried further to demonstrate it: basic-page.php <?php // make a custom <title> tag $page->browserTitle = $page->rootParent->title . ": " . $page->title; $page->outMain = "<h2>{$page->subtitle}</h2>" . $page->body; if(count($page->images)) { // display a clickable lightbox gallery if this page has images on it $config->scripts->add($config->urls->templates . "scripts/lightbox.js"); $config->styles->add($config->urls->templates . "styles/gallery.css"); $page->outMain .= "<ul id='gallery'>"; foreach($page->images as $i) { $t = $i->size(100,100); $page->outMain .= "<li><a href='{$i->url}'><img src='{$t->url}' alt='{$t->description}' /></a></li>"; } $page->outMain .= "</ul>"; // add a note to $page->title to say how many photos are in the gallery $page->title .= " (with " . count($page->images) . " photos!)"; } if($page->numChildren) $page->outMain .= $page->children->render(); // list the children include("./main.php"); main.php <?php // if current template has it's own custom CSS file, then include it $file = "styles/{$page->template}.css"; if(is_file($config->paths->templates . $file)) $config->styles->add($config->urls->templates . $file); // if current template has it's own custom JS file, then include it $file = "scripts/{$page->template}.js"; if(is_file($config->paths->templates . $file)) $config->scripts->add($config->urls->templates . $file); ?> <html> <head> <title><?php echo $page->get('browserTitle|title'); // use browserTitle if there, otherwise title ?></title> <?php foreach($config->styles as $url) echo "<link rel='stylesheet' type='text/css' href='$url' />"; foreach($config->scripts as $url) echo "<script type='text/javascript' src='$url'></script>"; ?> </head> <body> <h1><?php echo $page->title; ?></h1> <div id='main'><?php echo $page->get('outMain|body'); // use outMain if there, or body otherwise ?></div> <div id='side'><?php echo $page->get('outSide|sidebar'); // use outSide if there, or sidebar otherwise ?></div> </body> </html> More than half the time, I'll actually just re-use page variables like $page->body and $page->sidebar rather than $page->outMain and $page->outSide. That way there's no need to consider defaults, since $page->body and $page->sidebar untouched technically are defaults. <?php $page->body = "<h2>{$page->subtitle}</h2>" . $page->body . $page->children->render(); But technically you've got a little more flexibility using your own self-assign anonymous variables like outMain and outSide, so figured I'd use that in the examples above. outMain and outSide are just example names I came up with for this example and you could of course name them whatever you want.1 point
