Just another WordPress.com site

  1. By Default WordPress displays the excerpt of the current post with the “[…]” text at the end, which is not a “read more” link. So to have a custom excerpt add following to the function.php

function new_excerpt_more($more) {
global $post;
return ‘<p><a href=”‘ . get_permalink($post->ID) . ‘”> Continue Reading</a></p>’;
}
add_filter(‘excerpt_more’, ‘new_excerpt_more’);

  1. To Enable Featured Image
  2. To Avoid Google Ranking please find detailed article at ecarobar.com

One thing that the CSV engine allows for is the instantaneous data transfer from flat files to information accessible via SQL in MySQL. For example, imagine having the need to load a file containing 5 million records into a MySQL table that uses the MyISAM storage engine:

mysql> desc client_detail;
+-----------------------+---------------+------+-----+---------+-------+
| Field                 | Type          | Null | Key | Default | Extra |
+-----------------------+---------------+------+-----+---------+-------+
| client_transaction_id | decimal(22,0) | YES  |     | NULL    |       |
| transaction_timestamp | datetime      | YES  |     | NULL    |       |
| transaction_comment   | varchar(30)   | YES  |     | NULL    |       |
+-----------------------+---------------+------+-----+---------+-------+
3 rows in set (0.02 sec)

mysql> load data infile '/usr/local/mysql519/data/gim/flatdata.dat' 
    ->  into table client_detail
    ->  fields terminated by ',';
Query OK, 5023575 rows affected, 0 warnings (27.38 sec)
Records: 5023575  Deleted: 0  Skipped: 0  Warnings: 0

While MyISAM accepts the data pretty quickly, you can make all the data in the flat file instantly available to MySQL in the following manner. First, create a CSV table that mirrors the format of the incoming flat file:

mysql> create table client_detail_csv (client_transaction_id decimal(22,0),
    -> transaction_timestamp datetime, transaction_comment varchar(30))
    -> engine=csv;
Query OK, 0 rows affected (0.01 sec)

Then, go to the operating system and simply rename the operating system flat file to the file MySQL created for the new CSV table:

[mysql@linux1 ~]$ cd /usr/local/mysql519/data/gim

[mysql@linux1 gim]$ ls -l
total 785848
-rw-rw----  1 mysql mysql        35 May  1 06:54 client_detail_csv.CSM
-rw-rw----  1 mysql mysql         0 May  1 06:54 client_detail_csv.CSV
-rw-rw----  1 mysql mysql      8718 May  1 06:54 client_detail_csv.frm
-rw-rw----  1 mysql mysql      8718 May  1 05:56 client_detail.frm
-rw-rw----  1 mysql mysql 221037300 May  1 06:00 client_detail.MYD
-rw-rw----  1 mysql mysql      1024 May  1 06:00 client_detail.MYI
-rw-rw----  1 mysql mysql 291367350 May  1 05:55 flatdata.dat

[mysql@linux1 gim]$ mv flatdata.dat client_detail_csv.CSV

The rename operation occurs instantly as nothing data-wise changes at the operating system level. At that point, MySQL has all the data available to it:

mysql> flush tables;
Query OK, 0 rows affected (0.00 sec)
mysql> select count(*) from client_detail_csv;
+----------+
| count(*) |
+----------+
|  5023575 |
+----------+
1 row in set (16.17 sec)

Thus, you’ve effectively loaded 5 million records instantaneously into MySQL. The great thing is the same effect would be experienced if the file contained 10 million, 20 million, or 100 million records.

A while back, I wrote a post detailing why it was a bad idea to generate Javascripts using PHP in WordPress plugins. In that post, I mentioned a couple of better ways to do it.

At the time, I didn’t know about the third, and best way, to accomplish this. Mike’s comment over there reminded me of it. WordPress has it built in.

If you already know about wp_localize_script, you can stop reading now.

The wp_localize_script function was made in order to allow for WordPress translations to be able to also translate some of the JS files inside WordPress. Thus the name “localize”. The way it works is to load up the translated versions of text from the translation files and then include them into the resulting HTML output as a Javascript object. The scripts then use that object to produce any text output they need to produce.

Turns out that’s really similar to our goal of sending arbitrary parameters from WordPress to be used by Javascript code.

How to do it:

1. Make your script static (instead of generated) and enqueue your script as per normal. Example:

1

wp_enqueue_script(\’my-script\’,\’/path/to/whatever.js\’,…);

No real changes there. You’ll have to come back and modify your script to use these parameters it’s getting passed, but we’ll get to that in a minute.

2. Build an array of your parameters that you want to send to the script.

1

2

3

4

$params = array(

  \’foo\’ => \’bar\’,

  \’setting\’ => 123,

);

Note that my parameters are simple examples, but this is PHP code. You can get your parameters however you like. Such as get_option to pull them from the database, perhaps.

3. Call wp_localize_script and give your parameters a unique name.

1

wp_localize_script( \’my-script\’, \’MyScriptParams\’, $params );

What this will do is make WordPress output an inline script with your parameters (properly encoded) just before the enqueue outputs the script tag that loads your script in the first place. So then those parameters will be available to your script as an instance of an object with “MyScriptParams” (from my example).

This means that Javascript code can now reference them as attributes of the name you gave.

So, step 4. Modify your script to use those parameters. In my example, I used “MyScriptParams” and the parameter names are “foo” and “setting”. In my Javascript code I can use them as “MyScriptParams.foo” and “MyScriptParams.setting”.

Much cleaner. One static and unchanging JS file to cache. Parameters get put into your HTML itself as a one-liner. You can deal with the parameters using a normal PHP array before passing them over. No need to screw around with generating Javascript from PHP or looking for wp-load or even messing with tricky actions.

Perfect.

via wp_localize_script » Otto on WordPress.

WordPress Plugins

Some Important WordPress plugin:

  • User Management

    • User Access Manager
    • Capability Manager Enhanced
    • Role Scoper (best combination to use with Capability Manager Enhanced)
  • Excerpt

    • Advanced Excerpt
  • Security

    • Better WP Security
    • Really Simple CAPTCHA
  • PDF

    • BSK PDF Manager
    • Print Friendly and PDF
  • Custom Post

  • Forms

  • Site Down/Maintenance

    • Maintenance Mode
  • Cross Platform/Cross CMS

    • Joomla/Mambo to WP Migrator
  • Social Media

    • Recent Tweets Widget
  • Slider/Carousel/Lightbox

A common need for a system like AjaXplorer is to let the users enter their own comments or remarks about the files they use. AjaXplorer lets you simply define as much metadata fields as you want, with various field types available, through this plugin meta.user.

This plugin requires a « metastore » plugin to be active to do the actual storing implementation. If you are not sure of what this mean, just read the previous section. Metastore will handle the actual storing of the metadata, where as the plugin will handle how it is displayed and other users interface.

Metadata is attached to a file, which means it is moved/copied/deleted between folders when such operations are applied on the files. The plugin provides a little editor for adding/modifying these properties as simple text lines, display them in both the file list and in the infoPanel, and the added metadata is also searchable.

To add some metadata fields, simply follow the steps :

In the « Repository Features » of a workspace configuration panel, make sure a MetaStore is defined, and add a « Text Metadata » plugin to the stack.

You can see a replicable set of three fiels :

Meta Field: a technical name for the field. Please use only alphanumerical characters. See below for specific keywords.

Meta Label: will be displayed to the user

Column visibility: can be « visible » or « hidden » (without quotes). This defines whether in List mode, the associated will be visible by default or not.

Some special keywords can be used to name metadata fields, that will behave specially in terms of GUI :

stars_rate : the field automatically turns into a 5-stars rating system for the files. View and edit the rating directly in the InfoPanel, in the FilesList (in list mode only for the moment), and in the « File Meta Data » form.

css_label : the field turns into a labeling system that will apply a given css class to either the table row when in list mode, or the thumbnail cell when in thumb mode. The css classes are defined in plugins/meta.serial/css and by default they define 5 levels of priority with associated background colors. Use png transparent images as background colors, that way the user can still notice when a row is selected or not.

area_XXX : Prepending « area_ » to a field name will create a textarea field.

For example, here is below a correspondance between a set of configuration and the result for the end user :

 

via User-editable text metadata | Pydio, formerly AjaXplorer.

As explained in the previous chapter, a workspace is mainly configured by 1/ its access driver (how do I access the actual data?) and 2/ additional plugins (enriching the data & features). This second part is handled by various plugins that are all of a specific type : metastore, meta,  and index. This order is not a random one : when adding a plugin you will notice that AjaXplorer will always reorder them like that. All these aspects will generally handle not the « data » itself (your files, their content), but « metadata », that is additionnal data describing the files. This data can be inherent to the files (e.g., the filesize can actually be seen as a metadata), or external, generated by the users (user-defined metadata) or by any system (a revision number from a versioning system).

So to take them in the order :

Metastore:

Defines how the metadata will be stored for the current workspace.  This can be linked to the underlying access driver but not necessarily.

Always the first in the stack, as meta & index plugins will often actually depend on a metastore.  Other features (like sharing and bookmarks) makes use of this feature to provide a better user experience as well. It it thus always recommanded to add at least a metastore to each workspace.

Current implementations include metastore.serial (stores files metadata on local filesystem, inside hidden files), metastore.s3 (to be used with access.s3, uses Amazon metadata capabilities) and metastore.xattr (uses file system Extended attributes, still experimental).

Generally if you are not sure, metastore.serial will do the job.

Meta:

One or many meta plugins can be added, they will actually implement the real features, and generally will require a metastore to be present for storing/retrieving their custom metadata.

Can go from user-defined metadata to quota implementation or versionning. See following sections of this manual.

Index

Indexation plugins, only Lucene is currently bundled by default, should be sufficient.

Always appears at the end of the stack, as other plugins can register metadata to be indexed by the search engine.

In the next sections, we will go through the common features one wants to implement on the workspaces. Please check the plugins documentations for detailed instruction and additional available features.

via Metastore, meta & index plugins | Pydio, formerly AjaXplorer.

P5.0.4 / WP3.6.1 Tutorial Recently Tested With

Contents

  1. Basic installation
  2. WordPress Side
  3. Pydio Side
  4. Result

Basic installation

  1. First install WordPress
  2. Install pydio with Mysql database
  3. Check both Wp and pydio has admin login.(Same admin username is preferred)
  4. I do not know what is the exact problem but I had some problems with different admin usernames maybe some browser cache problems.

WordPress Side

  1. Login to admin panel in WordPress and install pydio_cms_4.0.1 via Plugins/Addnew option
  2. Be aware that the original file you downloaded from sourceforge.net has all the cms plugins.So extract that file and select the directory wordpress/ajaxplorer only.You can either zip it again and upload to wordpress or copy the whole directory (only AjaXplorer in the wordpress dir) to wp-content/plugins directory.Warning !!! Be sure that there is no recurring directories otherwise the plugin install will return with error.
  3. Activate the plugin.
  4. On the dashboard select Settings/AjaXplorer
  5. In the Ajaxplorer path enter the full installation path something like : /home/user/public_html/ajaxplorer
  6. Choose a secret key
  7. Be sure that Auto Create (Create Ajxp users when they login) option is Checked to Yes.And do not forget to save changes.
  8. We finished the WordPress side.Now it’s time for Pydio part.

To Avoid Google’s duplicate Policy Please visit the complete tutorial at http://ecarobar.com/p5-0-4-wp3-6-1-tutorial-pydio-formerly-ajaxplorer-2/

%d bloggers like this: