Category Archives: webme

update: CMS design with jQuery and PHP

June 16, 2010 10:22 am 2 Comments

I got an “urgent” email recently from my Packt coordinator – she told me that if I kept writing my book at the rate I was writing, then it would end up being about 500 pages.

Thing is, though – it would be tricky to reduce the chapters I’ve already done, as a half explanation is as good as no explanation at all.

So, I looked over the planned chapters again, and saw that the final three could probably be dropped without affecting the core content of the book – they were just more example plugins showing how to integrate various things with the CMS.

The book itself is on how to build a CMS in PHP, that uses jQuery to make administration easier. That has been accomplished already in the existing chapters (1-7).

I suggested to Packt that I would drop the final three chapters and rework the earlier chapters so the book was more easily read (a 40-page chapter is /not/ easy to read).

Got an email back from them yesterday saying that the plan sounded good.

So the current plan is:

  • Finish chapter 8, which is on panels and widgets.
  • Write chapter 9, which will build a plugin demonstrating panels and widgets.
  • Try to break the earlier chapters apart so that there are more chapters, with less pages per chapter.
  • …
  • profit

I think I’ll be finished the current chapters within three weeks, then take a week or two to rework the earlier chapters, then another month for rewrites, and finally the book will be published 2/3 weeks later.

So, the book may be out within two months.

After this, I’m taking a break from modern technology to write about baroque technology – I’ll be writing a book on how to build a cheap clavichord.

Filed Under: book, javascript, jquery, packt, php, programming, web development, webme

closing a filament-group menu on mouseout

May 7, 2010 1:05 pm 1 Comment

The filament group menu plugin is one of the better ones out there.

But it has a few flaws. One of the major ones is that they’re not developing it anymore, leaving that to the jQuery UI team. But, development on that is really painfully slow… I don’t expect to see a working menu for months. Even the demos linking from the jQuery UI Menu page are hardly inspiring – they’ve got practically no functionality at all. Hardly useful.

For that reason, I’m okay with taking the current fgmenu code and extending it.

Here’s a simple fix, which has been asked for on their blog. I can’t comment on it because comments are closed.

To close menus onmouseout, all you need to do is to add a mouseout to all menu items, and if it’s triggered, then a second or so later, close all menus.

Obviously there’s a little more to it than just that. Read the code if you want the full details.

Just add this bit to your fg.menu.js file:

$('.fg-menu,.fg-menu-top-level')
  .live('mouseover',function(){
    this.mouse_is_over=true;
    clearTimeout(window.fgmenu_mouseout_timer);
  })
  .live('mouseout',function(){
    this.mouse_is_over=false;
    window.fgmenu_mouseout_timer=setTimeout(function(){
      var o=0;
      $('.fg-menu,.fg-menu-top-level').each(function(){
        if (this.mouse_is_over) o++;
      });
      if(!o){
        $.each(allUIMenus, function(i){
          if (allUIMenus[i].menuOpen) { allUIMenus[i].kill(); };
        });
      }
    },2000);
  });
Filed Under: javascript, jquery, programming, web development, webme

what I'm up to

May 3, 2010 11:54 am 2 Comments

As usual, I’m behind on stuff.

I just submitted chapter 3 of my upcoming book “CMS Design with PHP and jQuery”, and chapter 4 was due to be complete and sent two days ago.

My clavichord project stalled when the cumulative number of mistakes made it incredibly unlikely I’ll complete it in a usable fashion.

In work, I’m behind on a pretty large online-store project, but in that case I’m okay with it – I wasn’t slacking; things are just very busy at the moment.

My piano playing has also stalled – I’ve been trying to learn The Heart Asks Its Pleasure First for the last month. I’m stuck on the final page, where the left hand is all over the place and the right has an intricate tune to play. Its all in my head, but I just can’t play it smoothly. Thinking of putting that on the back-burner and going onto Bach’s 2-part inventions instead.

upcoming

Packt have asked me to review Expert PHP5 Tools. Looking forward to it. It’s got some stuff in it which I’ve read about but never tried. Including: UML design of applications, incorporating tests into subversion submissions, and automated documentation of source (among other things).

My piano teacher found an examiner who will be testing in Monaghan next month, so I’ll finally be able to get grade 2 out of the way. I’ve been practicing grade 2 and 3 tunes for months. Playing 6 tunes every day before I do anything else has been reducing th amount of time I have for the rest of my practice, so I’ll be glad to get this one passed as well.

I’m trying to push myself to get the current book finished as soon as possible. This is difficult as writing a CMS is a much more complex job than writing a cookbook of techniques. The chapter I just finished had 40 pages in it. By the 40th page of the previous book I was already into chapter 3. Chapter 2 wasn’t much smaller either!

When this book is finished, I’ll be starting a new one, on building a clavichord as cheaply as possible. Because I failed with the current one, but learned quite a lot from it, I feel I’ll get it right this time, and would like to document it as I go. There’s a lot of math involved in building a clavichord, and I think I may even get a good programming application out of it!

After that, I’m thinking of starting up contact juggling again, and completing the book, this time with videos.

When I get the time, I’d also like to get back into building robots. I think the gardening robot is a bit beyond me at the moment (involves some very complex AI), but I thought I’d try build a digger bot. You tell it what you want dug, where to put the debris, etc., and it gets to work.

Filed Under: book, clavichord, javascript, jquery, life, music, packt, php, piano, programming, web development, webme

optional columns using the css adjacent combinator

April 27, 2010 2:25 pm Leave a Comment

We’ve started a blog at webwork. We will be adding to it periodically when we think of cool things.

To start, I’ve written a small tutorial on how to make different column layouts without having to use different classes and IDs to indicate which layout to use.

creating optional columns in website layouts

Filed Under: css, web development, webme

CMS Design with jQuery and PHP: moving a recaptcha form

April 10, 2010 3:08 pm 4 Comments

reCAPTCHA is a free captcha service which lets you use their captchas for your programs.

I wanted to create a login/password-reminder page, with recaptcha used in both forms.

Unfortunately, you can’t have two recaptcha images on the same page, as every time the image is displayed, it is a new image and the old one is no longer valid (which means that if it’s used in two forms, you can only ever submit the second one.)

A solution that came to me is to “move” the captcha from one form to the other, so you’re only ever actually using one recaptcha.

So how is it done?

demo

In the demo, I’m using jQuery UI to separate the forms into two tabs.

If you look at the source, you will see there is one recaptcha object, in the first table. The table row has the ID “captcha”.

The entire JavaScript used in the demo is this:

$(function(){
	// remove the captcha's script element
	$('#captcha script').remove();
	// set up tabs
	$('.tabs').tabs({
		show:function(event,ui){
			// if the captcha is already here, return
			if($('#captcha',ui.panel).length)return;
			// move the captcha into this panel
			$('table tr:last',ui.panel).before($('#captcha'));
		}
	});
});

The first thing that’s done is that the captcha’s <script> element is removed. If you don’t remove it, then when the table row is moved, the script will be re-interpreted, causing breakage.

Now, the tabs are initialised. We set the show event to run a little function. That function checks to see if the captcha row is contained in the newly-shown panel. If it’s not, then it’s moved there using this line:

$('table tr:last',ui.panel).before($('#captcha'));

The above line means “insert/move the #captcha element in front of the last tr in the table contained in ui.panel“.

This is part of the User Management And Access Control chapter of the up-coming book “CMS Design using jQuery and PHP” ( a sequel, sort-of, to my jQuery 1.3 with PHP).

Filed Under: book, javascript, jquery, packt, php, programming, web development, webme

CMS Design using jQuery and PHP: the core

March 19, 2010 9:50 am 4 Comments

I submitted chapter 1 of “cms design using jquery and php” yesterday.

I’ve been building and using CMSes for over ten years, and the more I do it, the more I realise that “less is more”.

In the beginning, I was writing CMSes that had absolutely every aspect of the requirements hard-coded. That made the system fast but inflexible.

Over the years, though, I started figuring ways of breaking the system up into more modular bits and pieces, that could be enabled/disabled depending on the job.

This is the essence of what “plugins” are about – you have a single core system which includes only the absolute essentials, and into that, you put whatever plugins you find necessary for the job you’re doing.

The trick, though, is in deciding what is a plugin and what is not. This is very important to figure out – if something should be a plugin, it should not be in the core, thus making he core more stable and manageable. Conversely, if you make something into a plugin which is necessary for normal use of the CMS, then it makes the system less stable.

An example of this dilemma is user logins. Obviously, you need to have user logins for the admin area to work, but you don’t need user logins on the front end of the site.

So, should user-logins be a plugin or core functionality? The solution is a mix of both – you need to create a hard-coded user login specifically for the admin area, and if you want users logging in to the front end, that is a plugin, even though they both use the same database. The difference is that the admin login area is at a defined point (when you access the admin area), while making the frontend login into a plugin allows you to place a login anywhere you want.

Anyway – over the years, I’ve whittled away at my own CMSes until I realised that the core functionality of a CMS consists of just three things:

  1. display and editing of “normal” pages
  2. user and role administration
  3. plugin management

It’s impossible to cover those three items in just one chapter, but once they are covered, that basically completes the CMS!

When you have the above three items completed in your CMS, you can then work completely on plugins, making the system stable and yet flexible.

Of course, there are some fine details (templates, UI, optimisation, DB structure, etc.) that go into completing those three items, but that’s basically it.

Filed Under: book, packt, php, programming, web development, webme

CMS Design with jQuery and PHP: postage and packaging prices

March 9, 2010 5:07 pm Leave a Comment

This article is based on work which will be expanded more fully in the book, when I get to that chapter.

Every time we do an online store here in webworks, the postage/packaging is different. In one case, for example, postage is free over €50 euro, in another, it depends on where it’s going, and in the latest, it depends on a load of factors including where it’s going, what the weight of the products is, and what delivery option was chosen.

Up until now, hand-coded the postage rules. Everything else was handled by user-friendly parts of our CMS, but postage was such a random thing that we couldn’t find anything common enough that we could make a generic P&P handler.

The finished product is more complex than this example, but I’ll describe a cut-down version of what we’ve done, with countries and parcel-types removed.

admin demo – demo of UI for generating P&P rules

The first demo shows how the postage-and-packaging rule-set is created, using an “if-else” flow generator to build up the logic of the thing, and after each major action, convert the current state into a JSON string which can be saved.

The PHP is not really important in this one. The JavaScript handles everything. It translates a “seed” JSON string into a graphical representation of the rules, which can then be manipulated and finally translated back (automatically) into a JSON string to be saved in a DB (or session in this case). source for the PHP, source for the JS.

The frontend does its work in the background:

frontend demo – using those rules to evaluate P&P (visit admin first).

In this case, we enter values – total, weight – and run through the rule-set to find out what the P&P ends up as.

The source is suprisingly small, using a small recursive function to dig through the rules, no matter how deep and complex they go.

Here’s the recursive function (see source for rest of file):

function os_getPostageAndPackagingSubtotal($cstrs,$total,$weight){
  foreach($cstrs as $cstr){
    if($cstr->type=='total_weight_less_than_or_equal_to' && $weight<=$cstr->value)return os_getPostageAndPackagingSubtotal($cstr->constraints,$total,$weight);
    if($cstr->type=='total_weight_more_than_or_equal_to' && $weight>=$cstr->value)return os_getPostageAndPackagingSubtotal($cstr->constraints,$total,$weight);
    if($cstr->type=='total_less_than_or_equal_to' && $total<=$cstr->value)return os_getPostageAndPackagingSubtotal($cstr->constraints,$total,$weight);
    if($cstr->type=='total_more_than_or_equal_to' && $total>=$cstr->value)return os_getPostageAndPackagingSubtotal($cstr->constraints,$total,$weight);
  }
  $val=str_replace('weight',$weight,$cstr->value);
  $val=str_replace('total',$total,$val);
  $val=preg_replace('#[^0-9*/\-+.\(\)]#','',$val);
  if(preg_match('/[^0-9.]/',$val))eval('$val=('.$val.');');
  return (float)$val;
}

The switch block goes through the various “if” types that can exist in the flow model, handling each of them recursively and return their values to the caller.

If no “if”s are encountered, then the ruleset has found an answer, and we return that answer.

Before returning it, though, we parse the value of the answer. This is in case the answer is a math formula to do with the weight or total of the item.

For example, An Post have definite prices for packets to Europe up to 2kg (which is 10.75), and beyond that, it’s 3 euro extra for every extra kg.

That translates to a load of definite “if” statements, and an end value of “(weight-2)*3+10.75″ for the final “else”.

So, we convert recognisable words such as “weight” or “total” to numbers, make sure that we’re only left with parseable characters (and not something that can be used to hack), and eval it to produce the result.

Obviously, the full product is more complete than this, with safeguards against faulty formulas, extras to handle countries and envelope types (parcel/packet/envelope), but this example should give you a few ideas if you’re building your own P&P handler.

Filed Under: ajax, book, javascript, jquery, packt, php, programming, web development, webme

CMS Design using PHP and jQuery

February 1, 2010 11:55 am 2 Comments

I’m happy this week. Last week, I spent some time and organised myself a bit more. In work, things are going smoothly – managed to get over a tricky piece of work and the rest is simply a list of small tasks.

For the last few weeks, I’ve been emailing and messaging Darshana at Packt Publishing, about writing a second book (jQuery 1.3 with PHP is going very well – list of reviews).

I initially wanted to write about file management, to explain how KFM works, and to help force me to improve on it. But there’s just not enough of an interested market in that – it’s too specialised.

So instead, I’ll be writing about CMS design using PHP and jQuery.

We (webworks.ie) have a CMS engine which we’ve written and improved for the last 6 or so years. We’ve open-sourced it a number of times, but never managed to generate much interest in it. We never had the time to spend on publicising it.

The book will not be specifically about that engine, but rather about the concepts that went into creating it – how a CMS works, how to manage plugins, administration, user management, and all the other little bits and pieces that every PHP developer needs to eventually address.

By way of explanation, I will be demonstrating various parts of our CMS, and explaining how and why it was built that way. I will be closely examining the other major CMSes as well, and giving alternative methods where good ones exist.

The proposed chapter list is:

  1. Introduction
  2. CMS core design
  3. User management and access control
  4. Page creation and Navigation
  5. Template Management
  6. Plugins
  7. Form creation
  8. Image Gallery
  9. Panels
  10. Search and Polls
  11. RSS and News
  12. Online Store
  13. Products

I’m really excited about this project!

Filed Under: book, databases, javascript, jquery, mysql, packt, php, programming, web development, webme

php.ie slowly upgrading

December 7, 2009 10:49 pm 3 Comments

It’s been a while since I wrote anything vaguely technical. I guess it’s because I like to write only when there’s something new to say, and usually only if I have some new code to give away.

No new code today, but I can describe the recent work on php.ie (I’m the secretary of the Irish PHP Users’ Group).

So firstly, it was basically a static/brochure site for about a year, until we installed WebME (written by me!) as the CMS and created a skin for it so there’s only a tiny design difference. If you want to try out WebME, then download the SVN version from the google code site, or create a test site here (uses a really old version of WebME – you’re better off using the SVN version).

Then, I started rewriting the right panel. Beforehand, it displayed recent twitter messages, but they’re not often put out so it was a bit of a wasted space.

The panel now uses a WebME widget which displays recent Twitter messages, emails from the mailing list, and posts from the forum.

Over the next few days, I’ll be adding a new News section to the site, and the message widget will be able to show new articles from planet php.ie and new jobs from the jobs page.

I’m currently reading through Ken’s linux.ie todo list to see what I can appropriate for php.ie for its ongoing development.

Big thanks go to Michele and the team at blacknight for hosting the site.

Oh! Just a reminder, buy my book! JQuery 1.3 with PHP – hasn’t been reviewed by anyone yet, as far as I know, but my own opinion is that it is worth having on your shelf if you are a PHP developer that wants to step into jQuery.

Filed Under: book, linux, php, programming, web development, webme, webworks

KFM2: the beginning

September 30, 2009 11:11 pm 6 Comments

KFM 1.x has reached the end of its development. It has fulfilled its original purpose; to improve on the default file-manager for FCKeditor, and well-exceeded it.

From my records, I can see that KFM has been installed on over 9000 separate domains. That is quite a lot of sites, and says quite loudly how important it is that KFM2 is at least as good as KFM1 (we all know about the KDE4.0 fiasco…).

KFM2 will blow KFM1 well out of the water. It will do everything that KFM1 does, but much quicker, and with a much less monolithic architecture, allowing it to be hugely flexible. I am planning on creating a download section similar to jQuery UI’s, where you can choose the components that you want in the system, and it will be built up and configured for you, ready for download.

See, KFM 2 will be modular. If you just want a simple upload/download facility, then you will only need the core, and plugins to handle uploads and downloads. If you want the whole shebang, you will find plugins for various ways of selecting files and directories, full-on graphical UIs such as the existing KFM1 forces on the user, plugins for hooking into external file systems using FTP or whatever other method people can imagine, plugins for multi-media, file editing, databases, user authentication, search, RSS, and so on.

Basically everything that KFM1 already does, but with the option to easily remove/add bits that you want. Make it as fast or as “bling” as you want.

KFM2 will have a number of new things which are not available in any other online file-systems, that I know of.

new file-system things

The file system will be modular. You will be able to attach symbolic links to any part of the file system, linking to other external systems.

As an example, let’s look at a URL: http://example.com/kfm/get/images/site1/logo.jpg.

One of the new ideas is that this will not necessarily be located on the server named example.com.

If you are running a very busy website, you might prefer to delegate image management to a different machine deeper in your network, so you add a symbolic link /images/ linking to the image-management machine. This causes the server to issue a redirect to the browser, redirecting it to http://images.example.com/kfm/get/site1/logo.jpg.

Now, imagine that the image management server doesn’t host the logo.jpg file on itself. Maybe it’s one of a number of images.example.com servers in a load-balancing cluster, and the file is actually located on a file-server accessible only by FTP. So, we add a symbolic link in the server’s KFM, telling it how to connect to the FTP server. The image server does this, gets the required file, and sends it to the browser.

This sounds a bit complex, but at least it’s possible with the new system. The old system simply would not be able to handle that at all.

API

At the moment, if you want to select a file or directory, you fire up KFM1, wait 15 seconds for it to finish booting itself up, and select the file or directory. That’s way too long. Really, you should only need to load up a tiny widget that’s designed specifically for picking a file.

The new system will have a simple core with an API that can be connected to by little JavaScript widgets. As an example, let’s say you just want to get the file-listing for the foo directory.

At the moment, you need to go through the whole business of booting up KFM’s GUI, navigating to the right directory, then waiting for the server to connect to the database, generate thumbnails and other unnecessary stuff.

You should just have to do something simple like load up http://example.com/kfm/rpc.php?a=get_file_listing&v=/foo through jQuery’s $.get() function. The RPC script does exactly what was asked, and nothing more.

This should allow us to write some incredibly fast and tiny scripts for all the file manipulation things you could possibly want.

Think of it as the “gnu” way of doing KFM – many small tools, each of which is designed to do one task well.

Of course, you will still be able to use the original GUI with this, after it’s been re-engineered to hook into the new RPC system.

Or, you can write your own – the RPC’s API will be well-documented, and will use simple HTTP parameters, so you can write your widgets in whatever language you want – JavaScript is what I will be writing in, but there’s no reason why you’re confined to that – write a GUI in Python, C, Flash – whatever you’re comfortable with.

plugins

I think the new plugin architecture will make this profoundly extensible. I’m writing the core to be as flexible and stable as possible. You will be able to write a plugin to just about anything:

  • authenticate a user before serving a file.
  • change a user’s root directory based on the server-name or the user’s authentication.
  • the entire system is held on a different machine accessible only by FTP? fine – let’s change how files are accessed.
  • record all files and directories in a database, allowing searches to be done.
  • manipulate files online – edit text files, rotate or crop or resize images, move or rename or delete, etc. standard KFM1 stuff, these.
  • create a log plugin, so all access is recorded.
  • create a quota plugin, for denying uploads or downloads when the quota is exceeded.

It was possible for us (Benjamin and myself) to write all of these into KFM1, but as we are only two people, and very busy people at that, it’s never been the absolute top priority to get all these things done.

But, when KFM2 is released, you won’t have to wait for us anymore. You will be able to write plugins, or download plugins created by other people, which do all of the above and I’m sure there will be plugins that I simply have not imagined yet, that inventive people will come up with (Conor, I’m sure you’ll be one of those!)

languages

Languages have always been one of the cool things about KFM. Version 1.3 was released in about 13 languages in total. Unfortunately, the code got too complex in 1.4 to easily add more, but KFM2 is starting from scratch with the learning-curve of KFM1 well behind me. I’ve already made most of the big mistakes I’m likely to make, so from now on, things should be much easier.

How languages will work is that a website will be created which allows people to help out open-source projects, not just KFM by providing translations of words and sentences.

The programmer will create a screen-shot showing the text in use, and will provide the untranslated text in a format such as .po. Translators will translate the text on-line, and the translation will be available to download by the programmer as soon as it’s done.

To ensure good translation, each line will be presented to a number of different translators. The translations which agree the most with each other, will be considered the “right” one.

Using this, it will be possible for KFM to organically add languages with no interaction from myself or any other programmers. When first loaded, a plugin would try to translate messages into the user’s language. Finding that it doesn’t have the language in its database, it will try downloading it from the language translation website. If it’s not available, a request will be added that it be created. When translators that speak that language come to the website, they will be automatically given the KFM text to translate to that language. The next time the plugin checks, the translation might be done, and it will be added to the KFM instance’s local language database.

Of course, people don’t just do this stuff for the hell of it. It’s more fun if there’s a competition or reward. It would be nice if I could get a few paying customers to add their own translation requests to the website – that way I could offer a reward to the best translators (those that do the most work, or are the most consistent).

The competition aspect comes in, where you give people points for every translation they do that is matched by someone else’s translation of the same text.

Google does a similar thing, for example, where it shows images to people and asks them to come up with keywords describing the image – the commonest keywords are considered to be correct. Same trick, different target.

Anyway! Without further ado, I have a core to design, and tests to create. I was going to talk about testing with PHPUnit, automatic upgrades, and the like, but to hell with ye all – I’ve work to do ;-)

Filed Under: ajax, databases, fckeditor, javascript, jquery, kfm, php, programming, web development, webme
1 2 3 4 … 8