Leaderboard

…and another update, the default admin theme is now responsive. Though I'm sure I'll be tweaking details on this for awhile.

The field and template tags features are now active on the dev branch for anyone that wants to try them out.

For those that wanted field/template categorization, I've got them implemented for fields and now development the same for templates. This is one of those features that don't take effect until you use it. The hope is that it won't add any complexity for those that don't need it. There is now a "tags" field on the 'advanced' menu of any field: You can populate that field with one or more tags. Read the description in the screenshot. When you populate that tags field, suddenly the fields list starts grouping them by tag, like this: You can make a tag group appear collapsed by default by prepending a "-" to the tag. Any field can have multiple tags. It'll appear in as many groups as it's defined in. This isn't yet on the dev branch -- I will push it tomorrow after finishing up the Template tags. Can anyone else duplicate in 2.2.10 dev branch, DB session support module installed? I've never been able to duplicate it, but followed the official instructions on the solution to this issue so afraid to change much more until it's repeatable.

I like the save button! It is a nice positive button with some pretty solid features that has got me out or trouble lots of times.... But I am wondering whether it is a bit lonely and could do with some bed-fellows? I am thinking of these few cousins: Save and Close (returns you to the page list, field list ,,,) Save and New (Saves the current doc and creates a new one of the same type - child of the same parent, for instance, with the same template enabled) Duplicate - literally creates a new whatever with everything the same, including the content. Very useful in SEO heavy sites where you want lots of similar pages with just some localisation changes. Cancel - closes without saving, maybe with an alert. This is a bit of a Joomla inspired list, but it can really speed things up when getting down to the content filling bit of a site, or mass producing fields. Display wise, I would suggest a button dropdown, like you can create thanks to those nice people at Bootstrap So, you would still have your sweet little save button, but with a down arrow next to it that revealed the other options, rather than have a long list of buttons. This has probably been suggested loads of times before, but I thought I would just nudge it into the list, just in case. Joss

Oh, a note to Ryan: This site is interesting because it is a direct rebuild, almost word for word, of a Joomla website. Doing some very rough tests this morning, it is MUCH faster than the Joomla version. So, plaudits to you for your core software. Joss

It depends. If the file is placed in a non-web accessible quarantine area and the download link runs through a passthrough script that eliminates possibility of file execution or unsafe mime type, then yes, it would be more secure. If that's not an option, then emailing may be more secure so long as the file size is kept small, and the file never exists in a publicly accessible URL on the server. Keep in mind anything sent through email is going to have to be base64 encoded, so the file will suddenly become a lot larger once it's encoded for email. Have the file send to gmail or some other service that has a strong filter for malicious stuff. Keep in mind that it's limiting the file extension, not necessarily the file format. One thing I see through my public upload forms is a lot of files like c99.php.jpg where the person uploading is hoping that there's a bug somewhere down the line. If there are any files involved, there are additional dangers in having it create a page at form submission time. Not saying it can't be done safely, but just saying it starts getting more scary to a security paranoid person like myself. If the files involved are images, I would only add images to the page that were confirmed to be actual images. One way to do this would be to use PW's ImageSizer() class to create another size variation of the image, and add that one instead of the original. This is what just about any social network does when you upload photos to it. Here's a stab at some validation. Not suggesting this is everything you'd need to do, but just attempting to cover most bases while thinking here in the browser: // $filename = the file that was uploaded $pathinfo = pathinfo($filename); if(!in_array(strtolower($pathinfo['extension']), array('jpg', 'jpeg', 'gif', 'png'))) throw new WireException("Invalid"); $info = getimagesize($filename); if($info === false) throw new WireException("Invalid"); list($width, $height, $type) = $info; if(!in_array($type, array(IMAGETYPE_GIF, IMAGETYPE_PNG, IMAGETYPE_JPEG)) throw new WireException("Invalid"); $targetWidth = 200; if($width == $targetWidth) $targetWidth++; // forced resize $sizer = new ImageSizer($filename); if(!$sizer->resize($targetWidth)) throw new WireException("Invalid"); Everything that FormBuilder does is meant to save you time. The default embed methods isolate the form from the rest of your site so that [unlike FormTemplateProcessor] you don't have to get involved with the CSS part at all if you don't want to. Meaning, it'll exist in your site without any effect or requirements on your site's stylesheets. That's assuming you utilize the default embed methods. But if you love having control over your own markup (even if it's isolated from that of your site's) then Form Builder will not be as much of a time saver just because writing markup takes time... especially form markup. Half the benefit of a form builder is that it takes care of the output for you. The other half of the benefit is that it takes care of the processing for you. The most time savings come when you let it take care of both for you. Though it'll do just one or the other if you want it to. There isn't currently a means by which to inject custom attributes into the actual markup. You'd have to do this with jQuery. Though this would be a fine way to go given that the data attributes are intended for javascript use in the first place. Each Form Builder theme has the ability to specify a custom JS file (like you can with a custom CSS file). So you'd do it like this: $(document).ready(function() { $("#your-input-id").attr('data-something', 'Something'); });

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.

We'll use this thread to discuss PW 2.3 features as they are being worked on. I've just added one of the first components. This is the "Page Path History" module. It's now in the PW core as a beta module (uninstalled by default). If you are interested in helping to test, just install the module from Admin > Modules > Page > Page Path History (after doing 'Check for new Modules'). The Page Path History module keeps track of the previous URLs for any pages that have been moved or renamed. It then sets up automatic redirects (301, permanent) to ensure the old URLs redirect to the new ones. This is best demonstrated by a few examples: Lets say you had the page /about/contact/ and you moved it to /contact/. With the Page Path History module installed, anyone accessing /about/contact/ will get redirected to /contact/. You had a page called /our-products/ and you renamed it to be /products/. Any accesses to /our-products/ will now get redirected to /products/. Those are simple examples, but this module can handle more complex situations too: Lets say you had the page /our-products/furniture/whoopie-cushion/ and you did like in the previous example and renamed /our-products/ to be /products/. The /our-products/furniture/whoopie-cushion/ URL will now redirect to /products/furniture/whoopie-cushion/ Later on you decide to rename /products/ to just /inventory/. All the /our-products/ and /products/ URLs will continue to work with redirects. You decide that whoopie-cushion really belongs in /services/ rather than /inventory/, so you drag it to /services/whoopie-cushion/. It's old URL in /inventory/furniture/whoopie-cushion/ redirects to it's new URL. TL;DR (am I doing this right) -- you can move or rename any pages and all the old URLs will redirect to the new, automated behind the scenes, without any thinking on your part.

This module enables you to limit edit access (by role) to any field in the page editor. This essentially provides field level access control on top of the existing access control system. It removes access to fields within a template, which is something that the built-in access control does not currently do in ProcessWire. This gives you a nice and simple granular control of fields. For instance, you might have two users (with different roles) that have access to edit a page, but only one of them could edit a particular field you had limited access to. Another example might be if you (the superuser) wanted to keep a notes field that only you would see in the page editor. But those are just simple examples, and the possibilities are quite broad. I've been wanting to find a way to provide field-level access for awhile, so this module has been on my mind for a bit. But what motivated me to finish it was a need that came up earlier today by Raymond Geerts in this thread where he needed the ability to limit access to fields on the page's settings tab... this module would do that quite nicely. http://modules.processwire.com/modules/page-edit-field-permission/ https://github.com/ryancramerdesign/PageEditFieldPermission How it works This module hooks in to modify the behavior of Page::editable, which is used throughout ProcessWire, but most notably by Page Edit. This module looks for permissions in the system that follow the name format of page-edit-[field] where [field] is the name of an existing field in the system. When it finds such a permission during a Page::editable call, it checks to see if the roles from the current user have this permission assigned. If they do not, then permission to the relevant field is refused, thereby preventing edit access to the field. This module also hooks into the Page Edit process and simply removes fields that the user doesn't have access to edit, before the form is rendered or processed. How to use it Once the module is installed, you get a set of checkboxes on the module configuration screen. Check the boxes next to each field that you would like it to create permissions for. (Alternatively, you can create the permissions yourself, so this is just a shortcut). You should only create permissions for fields that you intend to limit access to. Once your new page-edit-[field] permissions are created, any non-superuser roles that previously had access to edit those fields will no longer have access to edit them. To give them access, you must edit a role and check the box for the relevant permission.

I was just reading this post on how to make breadcrumbs in ExpressionEngine (http://bit.ly/hello_crumbly) and how you basically have to resort to a plugin to do it for you. It reminded me of some of the problems I had with EE when I was trying to use it and develop in it awhile back. One being that URLs aren't a primary/unique key to a page, natively in the system. Imagine ProcessWire with only it's root level pages and url segments, and that gives you an approximation of what you have to deal with in EE. I'm not saying it's wrong, but it's a different approach, and one that I found frustrating to work with. The post also made me realize I didn't have anything on the site demonstrating how you might make a breadcrumb trail (other than in the default site profile). It's really a simple thing (at least, relative to EE), so figured I'd post here. : <?php foreach($page->parents() as $parent) { echo "<a href='{$parent->url}'>{$parent->title}</a> "; } You may want to output those as list items or add some >> signs between items, but as far as code goes, the above is all there is to it. What it's doing is just cycling through the current page's parents till it reaches the homepage. Lets say that you also wanted to include the current page in your breadcrumb trail (which is probably redundant, but some sites do it). What you'd do is just append it to the list of parents that gets cycled through: <?php foreach($page->parents()->append($page) as $parent) { echo "<a href='{$parent->url}'>{$parent->title}</a> "; } The reason this is so simple is because every page is anchored to a specific URL and those URLs are representative of the site's actual structure. Pages in PW are actually uniform resource locators (URLs) whether on the front end or the back end. Because of that, there's no guesswork or interpretation to be done. In EE and Drupal (as examples) that data does not natively live at a specific URL. Instead that data is off in a separate container and the ultimate URL (or URLs plural) where it lives–and will be presented by default–are not as cut and dry. Yes, you can install plugins or go through strange taxonomic/channelistic/cryptic trials to approximate the behavior in other systems. And yes you can use url segments and pull/render any other pages you want in ProcessWire according to your own needs. But I'm talking about the fundamental and core system differences. This difference goes far beyond simplicity of generating breadcrumbs–it is a factor that translates to simplicity throughout the API.

Not sure if this has already been suggested, but for the less php literate among us it would be great to have some sort of repository of php scripts on the PW website for formatting template data, i.e. the php snippets for outputting different kinds of menus, breadcrumbs, bloglists, etc. Similar to a database or list of modules, but specifically for the templating side of things, where you don't require a full-on module. Right now you have to scour the forums (or write your own code) if you're looking to do something beyond the basics that are included in the default templates.

This case study relates to the topic here: http://processwire.c...ndpost__p__8988 about creating an archive of 'stories' about how PW has helped in relevant real life scenarios. Website: http://www.ray-dale.com RayDale Multimedia Ray Dale is a multimedia designer. His portfolio website was 2 years old as of March 2012 and in need of a refresh. He found that the content management for his website was more time consuming than he wanted and the website was generally slow in performance and complex to update. Ray needed: A website that could showcase his latest work with separate portfolio content types The ability to show lots of images and videos in each section Complex interlinking between each portfolio item - where each item would belong to a number of simultaneous categories To be able to publish a number of pages under various sections on the website To have a condensed navigation structure - not over-facing the user with navigation A blogging space that was easy to update To gain complete control over the HTML, CSS & JS markup and therefore the design of the website The ability to take more control over the admin experience - without using a host of plugins - so that the CMS could be used for clients to make their lives easier Speedy performance - even if a shared hosting platform were used Good site security The previous solutions Ray was previously using Drupal as a content management system. Drupal is a great system, it’s incredibly flexible, it can be made faster and using template overrides, almost complete control can be taken of the HTML and CSS output. However, the process to achieve any of this is time consuming and clunky from a web designer / front end developer perspective. Drupal was also going to require a number of plugins to be installed to achieve a lot of the required functionality. Ray tested migrating his website over to WordPress. WordPress is another fantastic blogging system with light CMS functionalities. WordPress is generally easier to use than Drupal and a lot of control over the HTML & CSS markup can be delivered - in a much easier manner than Drupal. However, WordPress is still light on CMS features in the admin system. This means that it is difficult without either using a lot of plugins or custom php development (using the WordPress API) to have custom content types and fields. The decision to use ProcessWire Having searched around for an alternative to Drupal and WordPress - revisiting other CMSs that Ray had also previously used - Ray eventually landed on ProcessWire having read about it on a forum. Right from watching the initial video produced by Ryan Cramer (the creator of ProcessWire) Ray was intrigued by the possibilities that ProcessWire seemed to offer - effectively solving all of the issues currently faced. To summarise ProcessWire offered: Custom content types in the admin Custom field types in the admin Good control over media uploads A simple to use admin system A neat and simple API for custom frontend / backend development A customisable admin experience The ability to have a custom admin url Complete control over HTML markup Good security with flood control A powerful and flexible templating system (that was also simple) Ray was extremely impressed by the features that ProcessWire offered, however, many CMSs look great until you actually start using them - where the unnecessary complexities, weak architecture and terrible, bloated functionality often start to appear. The functionality seemed so promising that a gamble was taken to build the Ray Dale Multimedia website - with very little time now available - to ProcessWire and test how it performed. Building the website Having built the original Ray Dale Multimedia website in Drupal, then converted to WordPress before deciding to gamble on ProcessWire - Ray now had very little time left to build his portfolio website. As a testament to the ease and speed of using ProcessWire - he was able (with a little help from articles in the forum) to rebuild the Ray Dale Multimedia website in two days of effective full time development. This included all of the content creation and learning the new system - with the inevitable (but surprisingly smooth) learning curve. Enabling complete control over output ProcessWire allowed Ray to write HTML and CSS without any of the interference you get from other CMS systems. So, Ray was able to use the following frameworks of his choosing: HTML5 boilerplate jQuery Modernizr Masonry A customised version of the 960 fluid grid system PrettyPhoto for lightbox images Less - to create minified CSS Though it must be said that literally anything can be used as ProcessWire makes no assumptions on the frontend - even on the Javascript framework. Quick and easy API One really pleasant surprise was the jQuery influenced API that ProcessWire offered. For example you can use php queries such as: $pages->find("selector"); $pages->get("selector, path or ID"); to find content in the system - you can even filter your queries by template type, fields attached to that item, etc. You can even use a range of selector operators. The API effectively works as a super powered and infinitely more flexible alternative to the WordPress loop. Cross referencing pages easily Complex cross-linking between portfolio items was needed so that capabilities, technologies and services could be linked to each item. It was easy to create a taxonomy system that worked the exact way required once the fundamental concept of how pages work in ProcessWire was understood. Building navigation that works Unlike a lot of CMSs that work effectively as ‘bucket systems’ - meaning that content is separate from any kind of structure or hierarchy by default in the system - whereas everything in ProcessWire is a page and arranged hierarchically. Whilst this may seem strange and restrictive to some used to the aforementioned ‘bucket systems’ - it works incredibly well and enables you to build navigational structures that are easy to plot a current location in. It is also something easy enough to break away from if you want a more ‘bucket’ type system. For example, in Drupal and WordPress it can be very difficult to highlight the navigation on a website if you are using custom content types. Try using custom post types in WordPress and keeping your navigation tracking which page the user has landed on - it’s extremely difficult without a fair bit of custom development (this is true as of the time of writing - WordPress 3.3.1). Because ProcessWire uses a structure and hierarchy by default - this structure makes building navigation that can track the current page very simple. Easy / flexible admin system The admin system in ProcessWire was easy and fluid to use, logical and stable. The admin system can also be overridden with templates (there are already some great community contributed templates). Modules used Whilst ProcessWire has a number of contributed modules from a thriving and helpful community - absolutely no additional modules were needed. All functionality on the website was achieved from a vanilla version of ProcessWire. Performance Another area of importance was the performance of ProcessWire. Again, Ray found this aspect to be well covered with built in caching capabilities that were thoughtfully included ‘out of the box’. The caching was simple to enable on templates and fields. The memory footprint of the Ray Dale Multimedia website was a third of that of Drupal on the same website without using addon caching plugins. Challenges The only real challenge faced was understanding that ‘pages are everything’ in ProcessWire. You build categories, taxonomy, articles, blog systems with the ‘page’ (and any fields it contains) being the basic building block for all of this. ‘Pages’ in ProcessWire can be attached to templates and injected with fields to enable the creation of literally anything conceivable. However, understanding this concept takes a little work for people used to other CMSs such as Drupal, WordPress and Joomla. However, in context - and compared to other systems - this learning curve is still fairly easy. There are so many other time savers that this learning curve becomes negligible. The other area that Ray had to understand about ProcessWire was that there aren’t any template system paradigms that exist in Drupal and WordPress. Other systems have parent and child templating systems with default parent templates that can be leveraged, however, because ProcessWire makes no assumptions on how you are going to build a project (being a true framework) you currently need to create your own template files. This is made easy by good documentation on the ProcessWire website and a decent set of ‘starter’ template files that come as part of the default install. Conclusion ProcessWire was an absolute dream to work with. Ray found it to be very stable, well thought out and hugely flexible. So much so in fact, that Ray has decided to standardise on using ProcessWire for upcoming web design projects. The flexibility and simplicity of the admin system, combined with power in frontend development that ProcessWire provides is something that Ray found to be liberating and more importantly ‘best in its class’.

I have just finished (ish) my first Processwire website: http://www.stonywebsites.co.uk/ It is a very basic site, but it uses Twitter Boostrap for the framework and also the Bootstrap Carousel on the front page. Graphics are all mine, though I am no artist, I am a writer and composer, so be kind. This was a rebuild of a site that was originally on Joomla with Seblod, but I decided to move to PW. One Problem: I used the Profile Exporter to move the site from development. But I had one issue - the paths to the images were wrong. The site was developed in a sub-directory on my local machine, and the image paths had that sub-directory as part of their address. I assume that on the dev site I had something wrong somewhere - what should I have done to stop this happening? Joss

I came back to this thread because of this other one http://processwire.c...portfolio-site/. As I remember, the need of adding extra information to the images and files fields was already mentioned some times. Ryan, are you still planning to extend the core fields with this? It would be actually a great feature to do this in the field config options!!

Create the page and save it, (your page is now ready to receive images) then loop through the uploaded images and add the images one by one to the $page variable you created before. don't forget to "$createdPage->setOutputFormatting(false);" each time before saving the page.

I did forget to update this: there was an actual issue that is fixed now on latest commit. Thanks Arjen for finding and Teppo for fixing!

FANTASTIC theme! Really love the color scheme, it's very soothing Mr. Nikola. I made a few minor changes to 'main.css'. #latest { text-transform: capitalize; } #latest-updates ul { width: 240px; } #latest-updates ul li { margin: 0 0 0 20px; } #latest-updates ul li a { display: block; } #latest-updates ul li a:hover { border-right: 5px solid #0fa8da; padding-right: 5px; } I just like having the Latest Update post links as blocks. It makes for easier clicking

Hey marcin, there's some threads already about it.

Late to the party, though I am, just read this and booked marked it as a really useful reference. For a newcomer like me, trying to work out a) what I can do with processwire and b) how I should do it is difficult. Processwire is so basic when you first install it that it really looks like it cannot do much more than sew a few pages together - even though that is, of course, what most websites are! Reading properly written case studies that demonstrate not just what problems were posed but how they were addressed is invaluable and can help others think out of the box and take on the truly bendy nature of PW properly. Thanks Joss

+1, think this has been mentioned a few times, would help with the workflow (only saves a few seconds each time but it adds up)

Wow, 2.3 is getting some seriously powerful new features. (I already sneakily grabbed the new version of the Comments Module and it's great.)

If you create a template without a file they won't be accessible on the site or search engines, they will only exist as database content. You're safe to just leave them like this.

Great!

The problem is source control - if it's data in a database, there is no file you can check in, compare version history or review changes made by other team members. Automated deployment becomes harder. You could dump SQL statements and check those in, but auto-increment keys make it extremely difficult to integrate, say, two different newly added fields or templates from different developers, since they will have the same primary keys. Just one example of many. Because metadata in nature is closer to code than it is to data, the metadata usually needs to be kept strictly in sync with the code - you usually have code that depends on the metadata, because the metadata "implements" (or at least strictly defines) the model. As opposed to data, which is usually less vulnerable to asynchronous deployment. I don't know if source-control and automated deployment are very important to most people - perhaps not a big concern for most smaller websites?

I don't think it's possible with a selector to recieve pages that have one specific month (across years). Your solution is the only I can think of. However you could write an helper function to just be able to use $pages->findPeopleBorn(9); to keep template code thin. A module with a hook $this->addHook("Pages::findPeopleBorn",$this,"findPeopleBorn"); which then has a public method findPeopleBorn($event) that returns results would be a good way to do this. See "HelloWorld.module" for example. One way to archive it without going through all users would be to separate day,month,year into their own fields. This would be easy to then query all pages with a specific month via a simple find(selector). Or a custom mysql sql query to recieve the id's and load the pages from that. Assuming the date field is called "birthdate": $tmplID = $templates->get("people")->id; $month = 8; $query = " SELECT field_birthdate.data,field_birthdate.pages_id FROM field_birthdate LEFT JOIN pages ON (field_birthdate.pages_id=pages.id) WHERE (EXTRACT(MONTH FROM field_birthdate.data) = $month) AND pages.status < 2048 AND pages.templates_id=$tmplID ORDER BY pages_id"; $res = $db->query($query); if($res->num_rows){ $ids = array(); while($u = $res->fetch_array()) $ids[] = $u['pages_id']; } $ids = implode("|",$ids); $people = $pages->find("id=$ids"); foreach($people as $p){ echo "<p>$p->title</p>"; }

Hi This is probably me being idiotic! I have created a template that has one area where I want to import the content from another page - in this case a Bootstrap Carousel. I have added a "page" field to select the carousel and that works - I have called the field "import_page" In my template, I have put <?php echo $page->import_page; ?> That, I have discovered, displays the ID of the page, 1018. It looks a very nice number and quite pretty on the page, but I would rather have the actual carousel! So, how do I now render the actual contents of that page in full? All the best Joss

I've completed the plugin, you can see the demo here and download it here. What's new compared to v1.3.4 mobile & tablet support (iPhone, iPod, iPad, Android, BlackBerry) CSS3 optimizations iframe fix dropped IE6-7 support for shadows & opacity. Usage Check out the API at official site. There is a new option showIframeLoading (true/false; default:true) that shows loading indicator (spinner) while loading iframes. You can use plugin as standalone, these optimizations are not tied to ProcessWire CMS (but are implemented for it). Meta Don't forget to put: <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0" /> in the HEAD of the document to make it work on mobiles & tablets.

Charliez, I think SiNNuT has pretty much answered your questions. I would add: Custom admin URL - SiNNuT is spot on here. It may seem like a small point, however, if you are training and documenting the cms for a client it is often useful to state that the 'backend' system in ProcessWire is the 'admin' area. Therefore, it can be extremely useful to have them login and manage their content from a 'domain.com/admin' style url. Flood control - again SiNNuT is accurate here. To add more information - if you login to ProcessWire and go to your 'Modules' section you will see 'Session Login Throttle' there. The description to this module states: 'Throttles the fequency of logins for a given account, helps to reduce dictionary attacks by introducing an exponential delay between logins'. This is often referred to as 'flood control' with other CMSs and is usually NOT built into the system - instead being offered as an addon module. PW makes this sort of basic protection simple by being built into the system and enabled by default. Templating system - to my mind there is a templating system in PW. Yes, it is very 'light' and gets out of your way by not assuming you want to work any particular way. However, the fact that you setup 'templates' in the PW admin and then the system finds those php files carrying a predefined template name from the 'site/templates' folder suggests that there is some sort of automatic templating sytem. Guys, as stated elsewhere I am also a bit of a noob when it comes to ProcessWire and this case study is very much from that perspective. Some of the language I use may be at odds to the vision and communication intended here. So, this is a good discussion - I think - as I am approaching PW from more of an enthusiastic outsiders perspective. I can change any of the case study to better reflect a desired approach if needs be.

It's a good read My thought though would be to make it personal if these end up on the new PW site - write them as customer succes stories rather than 3rd person case studies (which would just mean re-wording it to the 1st person in this case). What do you guys think?