ryan

Unfortunately once you start on a PHP 5.3+ you can't migrate passwords back to a PHP 5.2 server. PHP 5.2 did not support blowfish, so it has no way to validate the password. The only solution is to do as you did, and reset your password.

Welcome Faisal, good to have you here, and thanks for the nice intro!

Davo, what you are doing there looks about right to me. Populating the $p->map->address should trigger the Google Geocoder into action. Just make sure you have a $p->save(); somewhere in there so that the coordinates get saved. I wonder why this is the case? I wonder if it's jQuery or google maps that's polluting the other (I'm guessing Google Maps). Can it be resolved by using jQuery() rather than $(), or is it something beyond this?

I used to use Transmit and honestly never had the syncing working quite right with it. Though this was years ago, and Transmit is pretty much the most popular FTP app in OS X. I would be surprised if it were still buggy in that respect. I personally use Yummy FTP now, but I generally try to avoid using any FTP for transferring files unless it's the only option. I have a strong preference for rsync.

I think you may be asking for something broader in scope than can be answered in a forum post. There are any number of ways to do it, but I would try and find a good jQuery table plugin (perhaps ajax driven) that provides some of what you already need and take it from there. Retrieving the data to display in your table from ProcessWire will be the easy part.

Nobody has added it to the modules page. This is up to the author of the module as to whether they want to add it to the modules directory or not. I also wanted to mention that the dev branch of PW has a "locked" option for inputs, which may produce a similar result. See the screenshot:

It seems like you might be asking the same question that's already been answered? Either that or I don't understand the question. I'll step back and assume that maybe you aren't talking about page relations. A best practice would be to make sure you aren't duplicating any data. Meaning, pull the data from the source. For instance, if you wanted to retrieve the first image from the homepage, regardless of what page you were actually on in your site, then retrieve the homepage and pull the value from it. Same goes for anything else. Every page and its data is accessible to you from the API. $homepage = $pages->get('/'); $image = $homepage->images->first();

You could retrieve the errors from the Inputfield, clear them out, and then replace with your own: $errors = $inputfield->getErrors(true); // true=clear the errors out // $errors is a plain PHP array of error messages... // ...if you want to iterate it or do anything with it $inputfield->error('Your custom error message');

The setMarkup() is just for adjusting the markup of Inputfield lists, not the markup of individual Inputfields. That markup is not currently changeable programatically. Your best bet would be to either: 1) the clean way would be to make a copy of InputfieldRadios => InputfieldRadiosCustom, install as a new module and make it produce the markup you want. 2) the quick n' dirty way would be to replace the <li>'s with <div>'s by hooking after InputfieldRadios::render wire()->addHookAfter('InputfieldRadios::render', function(HookEvent $e) { $e->return = str_replace( array('<li ', '</li>'), array('<div ', '</div>'), $e->return); });

Do you have the LanguageSupportFields module installed? If so, and if the language codes used in the filenames are consistent with the language names in your system, then it's assuming they are language-alternate fields.

Marco, I think the hook you might be looking for would be TemplateFile::render. The only issue is that this is used by many things, like rendering of partials and such. So you'd probably want to hook into just the instance used by Page::render. Not tested, but I think you could do this by checking for the presence of the $options array (and better yet a property we know would be there--I'll use $options['pageStack']), which would indicate it's the instance you want: public function init() { $this->addHookAfter('TemplateFile::render', $this, 'hookRender'); } public function hookRender(HookEvent $event) { $templateFile = $event->object; $options = $templateFile->options; // checking for $options, which we know is given to page renders // this is to make sure it's not some other use of TemplateFile if(is_array($options) && array_key_exists('pageStack', $options)) { // this is a page render, go ahead and process the output $output = $event->return; $page = $templateFile->page; // I'm assuming you want this $output = yourTwigStuff($output $page); // replace with your Twig code $event->return = $output; } }

Marco, your module is already approved in the directory. Once approved, your updates go in right away. You probably just saw the effect of a 1-day cache on the directory. However, the modules manager should pick it up more quickly than that since it's not on the same cache. Also, you don't have to update the version number manually. The modules directory picks this up automatically once per day by going to GitHub and looking at your module file. No need to edit your module listing unless you already need to change something else.

Glad you guys like it. Making a little progress with every update. They disable themselves if you get above 100 fields (or 100 templates, but that's less likely). So if you are dealing with that many fields, then you'll not have the drop-down menu option... it would just be too much. It might be that the limit should be lowered to 50 or something, I'm not sure. IMO the fewer scrollbars the better... I'd rather scroll the whole page than something within the page. But I haven't tried the alternative either. These are jQuery UI menus, and I'm not sure yet how to change that (I was trying to earlier). It may be that I just need to come back to it when I've got more time to explore it. But if you see any specific CSS tweaks I can make let me know and I will. Not positive I understand–might need a screenshot that points to exactly what you are talking about. At least, I'm not recognizing where the overlap is here. Theoretically I'm not sure they can be separated (space between them) and still maintain the mouseover state to keep the menus active. I'm not too worried about this, as the error message appear right under the masthead. Also, error messages in this environment are not life-threatening if they somehow miss it. I'll play with it though, as I'm not sure I've even seen the error message in Futura. jQuery UI is adding these button colors when active/click, and I'm not exactly sure how to get around it (I've been pressed for time this week, so haven't pursued these rabbit holes). If you manage to figure it out before I do, please let me know. I get the impression this is coming in from the JS side, since there seems to be a fade-on-click going on here. The yellows and blues that show up in there are not part of the color scheme and I don't know where they are coming from, yet. We probably will expand the scope of this button, but going to keep it simple for the first version. I'd love to see screenshots of these, as I can't see that here (Firefox 24 in OS X). I think the screenshots you attempted to post were probably not JPG/PNG/GIF, given the error message the forum gave you. Please convert them to one of those formats and post. Or if you don't want to convert, just email to me ryan at processwire dot com. Could I see a screenshot? I'm not seeing the jaggies here. Maybe there is something I need to adjust with this particular typeface. Based on what you are saying, I'm guessing the browser is fake-bolding the typeface rather than using the actual bold version of the typeface. Maybe there's something I can do from the CSS side to fix that, but I'd like to get a look at it first. I was trying to find something in-between the old theme's colored field headers and the new theme's non-colored headers... a gradient. But I think those gradients are a failed experiment.

Btw, forgot to mention, but these are all committed to the dev branch if anyone wants to try them out.

Here's the next iteration of updates which takes into account the comments above. The biggest changes are: Switch to Arimo for the font–thanks to Diogo for the suggestion. This font seems about perfect for our need here. It looks like the license for it wouldn't let us bundle it in the app, so we have to load from googlefonts... but I think that's okay. It'll continue to use Arial for people that are working offline. Got rid of the entire headline, per BartekG's comments above. The headline really doesn't seem necessary (regardless of how big or small it is), and his post made me realize that. The headline text is now just part of the breadcrumb trail. The drop down navigation now includes drilling down to individual fields and templates. ./colors=classic ./colors=modern ./colors=warm ./colors=futura Dropdown example: Not sure I understand–can you clarify which submenu items you are talking about (in the page list maybe)? Anyone else agree? What I was gathering from previous feedback was that folks wanted page list actions that were bigger and less subtle, so making them look a little more like buttons was the intent here. I just want to clarify that this is 1 theme, not 4. The color schemes are merely different SCSS variable files included at the top. Otherwise everything else is the same. There's no maintenance burden here. We are also in a spot where many like the classic color scheme, and it's kind of become our brand. But an equal number (or more) dislike the colors to the point where they see them as childish. So I think we have to answer that by having a variable palette / different options from the start. Good suggestion. I had started to think the title was more important than it was. I looked at several other CMSs to compare (Drupal, Joomla, Concrete5, EE, Craft) and noticed that this new admin theme started the content input before any of those–a good thing for sure. But then I got to WordPress, and noticed their content input is practically at the top of the screen! Granted WordPress uses sidebar navigation rather than header navigation, but it drove home your point for me. It's going to look like you've got a big footer if you have little content on the page and no scrollbar. That's because the <body> background color is the footer color. If you have a lot of content on the page, you will have a very small footer. The actual footer is actually very small / very little padding, but that may not be clear on some screenshots. I'm not sure I agree with this, but it doesn't matter now that the title is gone. Yes the forum may have a black title, but I believe that was a limitation of the IPBoard theming system. Notice the rest of the site (outside the forum) uses the pink titles. So the admin theme was trying to be consistent with that. I'm not against the idea, but since we already support custom icons there, I think it would be too much. Also, we already have visual cues that indicate whether an item is open, so additional icons/cues would be a form of double emphasis. Still, I think in the future, we will probably have default icons for when non are specified (like open and closed folder, triangles or something like that). Thanks–I will look into these. I don't think it should matter. Try hitting reload a couple times to make sure your cache is fresh. Also, your screenshots look to be the old admin theme rather than the one discussed in this thread? Though the icons should work in either, but just want to make sure I know which we're talking about.

Beautiful work! I'm currently over my head on client work, but just wanted to quickly drop in and thank you for your great work and thinking here. I'll come back with a better reply (and catch up with the rest of the forums) once I get through this marathon work week. I've been working on admin theme stuff a lot lately (before this week at least), so it's very fresh on the mind and I'd be happy to collaborate on the back-end side too.

Thanks Diogo, I'll try that out. Also, I forgot to commit that update that fixes the ?colors=[warm|classic|modern|futura] thing (it was previously keeping the color theme selection for only 1 page). Just committed that fix now.

I've pushed several updates consistent with the feedback above. This includes going a little more minimal on some things, converting absolutes to floats, making the lines more visible, and numerous other updates. I also added another color theme "futura", which is based on Nikola's Futura Remixed. With regard to typography, I'm going against my own preferences and making the type bigger, bolder (in Classic and Modern), and increasing the line height. These changes make it less usable to me personally, but my conclusion from previous feedback was that others may prefer bigger/bolder, more height, more room, etc... so just trying to find a balance. After all, the point here is to have a theme that appears to a broader group, rather than one that maximizes usability at scale. Or at least to find a balance. Regarding there being some redundancy or things that need cleaning in the CSS–I'm leaving a lot of extra stuff in there since I change my mind a lot. I'm not going to fully clean and remove redundancies until it's final. So please don't look for perfection here, this is a work in progress. I'm not going to vacuum this place until the work is done. Regarding use of Arial as the typeface: I tried switching to OpenSans, but there was just too much personality to it that I thought it was influencing the tone too much, and ultimately too distracting. If you guys can think of any other free, fairly neutral webfont typefaces worth trying, please let me know. I would love to find a better alternative to Arial. Edit: Almost forgot, here's the screenshots of the updates. ./?colors=classic ./?colors=modern ./?colors=futura ./?colors=warm

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.

One way to do it would be to create a new template called /site/templates/bookmark.php and give it a title and URL field called 'bookmark_url'. For the code in the file: <?php if($page->bookmark_url) $session->redirect($page->bookmark_url); Now add a new page in your admin where you want the bookmark to go (like in the top navigation or in Setup), and use your new bookmark template. Enter the title and the URL you want to bookmark to and save. This is the same approach used for a front-end redirect template. In this case, you could use the same template on the front-end for that too.

I'm not sure that you need to have that RewriteBase directive there. At least, I've never had to use it in any of the hosting environments I work on, regardless of whether the site is installed in a subdirectory. But I know it is required for some. However, I don't think that's what the issue is here. It sounds to me like you've got a corrupted file in there somehow or another, or that something is not working with your PHP. You might try installing the dev branch, just in case. But I think there might be something else going on with the server if a stock 2.3 install doesn't work. Let me know how the dev branch install goes. If still getting an error, please PM me a link to your phpinfo().

It turns out that the default spelling service used by TinyMCE's spellchecker, GoogleSpell, has been discontinued. That's why everyone's spellcheckers stopped working. You can fix it by editing the config.php file included in your /site/tinymce/spellchecker/config.php file. Comment out the line referring to GoogleSpell and uncomment the line referring to PSpell or PSpellShell: // General settings //$config['general.engine'] = 'GoogleSpell'; //$config['general.engine'] = 'PSpell'; $config['general.engine'] = 'PSpellShell'; Use PSpell if your PHP has the PSpell module installed (you can check from phpinfo). Mine did not have it installed, so I used PSpellShell. If using PSpellShell: Check that this line (also in the config.php) points to the location of your "aspell": $config['PSpellShell.aspell'] = '/usr/bin/aspell'; You can determine the location by typing this in the shell: which aspell It will return the path where it is installed. After updating your config.php, double check that aspell works by typing this in the shell: echo "This file has a misspellling can you tell which word it is?" > test.txt aspell -c test.txt In most cases it should work and your TinyMCE spellchecker should start working again. If you get an error, then you may need to do more, like install a language-specific dictionary file (which you may need to ask your webhost to do).

If using ProCache, it would be kind of defeating some of the benefit of it if you are still loading ProcessWire for every request to update a view counter. I'd think you might be better off using an external service like Google Analytics to keep track of this for you. It already does this if you are using it, but of course that's not data you can easily pull back in to sort pages, etc. (as far as I know)

Tested out and I was able to duplicate here. It looks like we had a 50 character max limit for queries sent to the fulltext index. I have updated this to be 500 (consistent with the selector engine's max value length) on the dev branch. That seems to fix it here.

I've not used fieldsets in repeaters before, but just tested it out here and they seem to be working for me. Can you post a screenshot of the effect you are getting? If you attempt to collapse the fieldset by clicking its header, what happens?