I just got some questions, maybe some of you can answer.
The benefit by Nextcloud / Owncloud and so on is more than just uploading taking files with you and so on.
It does version the files, make them downloadable - as well secure behind.
It would be benefitial for me and most everyone who is dealing with the Question:
"How to upload documents, link them in some kind of Database (which main purpose is to operate with information) and versioning, saving, editing and so on does not need to be implemented by me / others, because it is handled by Nextcloud (in my case prefered)?"
Is there any script outside, or maybe some kind of plugin to have that benefit?
In my vision I would need:
One "Drag and Drop" Area for Documents / Pictures etc.
This should have a hidden field, which is filled with a id, with which the system can identify the file.
a onetime Link (with retention of that link by one day or so) what is generated by php (could also be a script) and generates a share Link for given id.
(not needed since now, but nice to have:) some script as in 2, where versions of some given File should be viewed.
Some solution could be:
something similar to an "iframe" for a shared link with public upload.
But Im not very happy of using IFrames... Something better would be nice.
Drag & Drop is available in the Web UI. For additional meta data, use a hook mechanism on postCreate (\OCP\Files\Node $node) within a custom app/module you'd need to deploy. For hooks, see https://docs.nextcloud.com/server/12/developer_manual/app/hooks.html.
About meta data: you don't need to store them in a database necessarily, you can also use custom WebDav properties. I wrote a blog post about it recently: https://medium.com/#mathiasconradt/how-to-assign-custom-meta-data-to-your-documents-on-nextcloud-23356cf3f926
Links with a time limit to be valid can be generated manually via Web UI. If you need it automated on upload, use the same approach as in (1): hook mechanism that listens to file creations, as part of a custom app.
at the moment, you can only restore old versions. I think you cannot diff/view them. Would require a custom app.
General info on how to write your own module / app: https://docs.nextcloud.com/server/12/developer_manual/app/index.html
I'm working on a website I eventually plan on purchasing a domain for and having, hopefully, many users. Of course, a lot of people plan on that and it never comes true! Regardless, I'm progressing forward with the intent of having a good looking interface that's efficient in it's data usage.
One thing I would very much like to do is to have my banner / header and side-bars persist when they navigate to separate pages inside my site. My header contains the site-wide context menu as well as login and profile information, and the side-bars are currently undecided, but potentially just static images.
I don't know exactly how I would do it well. I could just use my PHP session object, but I'd like to be as efficient as possible.
I'm using a traditional LAMP stack, HTML, JS and CSS (using the Bootstrap library) on Ubuntu on an Amazon's EC2 service.
You could create a file with header and sidebar and then use this php code:
include("nameofthefile.php");
on every file of your site
I have a small project about a dynamic database driven website which is users can post, comment, like,... on it.
and I was thinking about creating html pages instead of php pages.
for example after someone posts sth a php code will create a html page for that post and people can comment on it. while submitting a comment, an ajax call to a php page will save comment data to database and write that comment to the html file.
I thought it could be a good way to reduce server load. and have advantages for SEO.
Does this technique have a name? and Does it have any more advantages or disadvantages?
Thanks in advance
There's a flat-file blogging engine called Kure. It's an open-source project so feel free to check it out. "Flat file system" would be the closest thing to a name for this technique.
I have to agree with my SO colleagues here. Servers and even personal computers are, for the most part, more than capable to handling what you're describing using a real database. Blogging engines such as Wordpress, are incredibly powerful and flexible and will save you a lot of hassle down the line.
That said, if you insist in creating your own flat-file system... more power to you. Good luck.
Yes, it is a known technique for optimizing serving of relatively static pages. By 'relatively static' I mean "dynamic, but update rarely".
For example, Yandex (a search engine) uses this to serve its main page. It's pretty rich page, and it would require significant resources to generate it on each request.
Also, there is (at least, there was) a plugin for Wordpress that does this.
You can't use this technique if your pages update often (it will not worth it).
You can't use this technique if your pages are personalized (that is, if you can't serve the very same page to all your visitors).
I don't know any name for this technique. I know it's already been used for some big sites in the past but I'm not sure it's still used because it's not always easy to handle and if a file is corrupted because of a script, other scripts working with the page can make it even worse.
I'm building a new website which has one core application and many content pages. Content pages are mostly dynamic and I require a way to manage this dynamic content on a regular basis. The core application's main functionality is a 3 step process or reading user data (input page), reading data from MySQL (product page) and submitting an application to an email address (application page).
Ideally I would like to build the core application in regular PHP and leverage Drupal for its content management capabilities. Can Drupal and regular PHP be integrated as I suggest easily? My feeling is that coding the core application as a Drupal module(s) will add layers of complexity that could be difficult to code from the outset and maintain later on as the system matures - so I would really like to just use regular PHP.
Let me explain where dynamic content (managed by the CMS) intersects with the core application:
Dynamic content such as FAQ data is used both on the 'normal' help pages and also within a mini-feed displayed within core application pages down a right hand side column. In this column, 3 random questions are pulled from the database and displayed as a feed. When users click on FAQ question they are not taken away from the core application product page but are instead shown data in a pop-up window displaying the question and answer. In addition, users can browse other questions and answers through a simple navigation menu within this popup. There are 3 such like feeds as I describe above that I require on the core application product page.
So, what is the ideal solution here in terms of 'keeping things simple' for both the management of dynamic content and the ease of coding the core application? Can 'regular PHP' and Drupal co-exist 'peacefully'? If so, how is this technically possible? Because there is some content managed by Drupal contained within core application pages, can the core application still be coded in regular PHP?
Any advice / suggestions?
Thank you!
Jim.
This is part of a post I submitted few years ago. Unfortunately the linked article is long gone, but it might still be relevant for your needs:
Importing old-style standalone PHP scripts into Drupal system
Drupal system is a very strong CMS, but taking an existing PHP site and trying to force it on Drupal might be a hard thing to do.
The "right" way to convert a site into Drupal is to "Drupalize" it, which means to do everything "the Drupal way", which is really the right thing to do - but is some cases not everybody agrees about that.
I had an example with a company that has many HTML/PHP based sites. They heard about the flexibility and strength of Drupal, and decided it is their choice for the revolution. But, on the other hand, they want not to change anything, and that I will do it as fast as possible.
The "right way" to do it was to break each PHP script they have to its pieces, find the commons, create the right methodology with existing Drupal modules, and finish the gaps with my own additional module.
But this is not what they asked me to do - instead, I looked for a way to just import the existing PHP script into Drupal environment.
Searching for am existing solution brought me to a proof-of-concept described by Dan Morrison. In the bottom line it uses PHP output buffering commands it order to collect everything the old script does, and then to display it as part of a Drupal module. In my case I had to make some small modifications (mainly to pass variables from the request to the PHP in the relevant scope), but in the bottom line it did exactly what I needed.
Well, almost... In other cases, in which I wanted to enjoy from Drupal's Form API, I handled it differently, as I will describe later on.
It sounds like you are asking about two things:
Including Drupal content in a custom-built PHP application.
Displaying Drupal content in a pop-up window from the PHP application.
There are a number of different levels of integration- if your need is as simple as pulling content into a page then you may be able to simply create a view (http://drupal.org/project/views) with that content from Drupal that you can make available to and then include it in your web app.
If you are looking for a tighter integration between the 2 including sharing of users, sessions, etc... then it is likely also "possible" but would take additional information to understand what you need.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
Could someone provide a architectural overview of the Drupal 7 control flow? Perhaps in the sense of a flowchart about how a page gets generated. What additional resources would you suggest consulting with regards to how Drupal works?
Drupal can be confusing on this front, partially because it has a relatively deep function stack. Although it's procedural PHP it's purely event/listener driven in its architecture, and there's no simple "flow" in the main PHP script for you to look though. I recently did a presentation on this very subject, and the slides are posted on slideshare, but a quick high-level summary may be useful.
Drupal's index.php file functions as a frontside controller. All page are piped through it, and the "actual" url/path the user requested is passed to index.php as a parameter.
Drupal's path router system (MenuAPI) is used to match the requested path to a given plugin module. That plugin module is responsible for building the "primary content" of the page.
Once the primary page content is built, index.php calls theme('page', $content), which hands off the content to Drupal's theming/skinning system. There, it's wrapped in sidebars/headers/widgets/etc..
The rendered page is then handed back to apache and it gets sent back to the user's browser.
During that entire process, Drupal and third-party plugin modules are firing off events, and listening for them to respond. Drupal calls this the 'hook' system, and it's implemented using function naming conventions. The 'blog' module, for example, can intercept 'user' related by implementing a function named blog_user(). In Drupal parlance, that's called hook_user().
It's a bit clunky, but due to a PHP quirk (it keeps an internal hashtable of all loaded functions), it allows Drupal to quickly check for listeners just by iterating over a list of installed plugins. For each plugin it can call function_exists() on the appropriately named pattern, and call the function if it exists. ("I'm firing the 'login' event. Does 'mymodule_login' function exist? I'll call it. Does 'yourmodule_login' exist? No? How about 'nextmodule_login'?" etc.) Again, a touch clunky but it works pretty well.
Everything that happens in Drupal happens because of one of those events being fired. The MenuAPI only knows about what urls/paths are handled by different plugin modules because it fires the 'menu' event (hook_menu) and gathers up all the metadata plugin modules respond with. ("I'll take care of the url 'news/recent', and here's the function to call when that page needs to be built...") Content only gets saved because Drupal's FormAPI is responsible for building a page, and fires the 'a form was submitted' event for a module to respond to. Hourly maintenance happens because hook_cron() is triggered, and any module with mymodulename_cron() as a function name will have its function called.
Everything else is ultimately just details -- important details, but variations on that theme. index.php is the controller, the menu system determins what the "current page" is, and lots of events get fired in the process of building that page. Plugin modules can hook into those events and change the workflow/supply additional information/etc. That's also part of the reason so many Drupal resources focus on making modules. Without modules, Drupal doesn't actually DO anything other than say, 'Someone asked for a page! Does it exist? No? OK, I'll serve up a 404.'
To understand how Drupal works, you need to understand Drupal's page serving mechanism.
In short, all the calls/urls/requests are served by index.php which loads Drupal by including various include files/modules and then calling the appropriate function, defined in module, to serve the request/url.
Here is the extract from the book, Pro Drupal Development, which explains the Drupal's bootstrap process,
The Bootstrap Process
Drupal bootstraps itself on every request by going through a series of bootstrap phases. These phases are defined in bootstrap.inc and proceed as described in the following sections.
Initialize Configuration
This phase populates Drupal’s internal configuration array and establishes the base URL
($base_url) of the site. The settings.php file is parsed via include_once(), and any variable or string overrides established there are applied. See the “Variable Overrides” and “String Overrides” sections of the file sites/all/default/default.settings.php for details.
Early Page Cache
In situations requiring a high level of scalability, a caching system may need to be
invoked before a database connection is even attempted. The early page cache phase lets
you include (with include()) a PHP file containing a function called page_cache_
fastpath(), which takes over and returns content to the browser. The early page cache
is enabled by setting the page_cache_fastpath variable to TRUE, and the file to be included
is defined by setting the cache_inc variable to the file’s path. See the chapter on caching
for an example.
Initialize Database
During the database phase, the type of database is determined, and an initial connection is
made that will be used for database queries.
Hostname/IP-Based Access Control
Drupal allows the banning of hosts on a per-hostname/IP address basis. In the access control
phase, a quick check is made to see if the request is coming from a banned host; if so,
access is denied.
Initialize Session Handling
Drupal takes advantage of PHP’s built-in session handling but overrides some of the handlers
with its own to implement database-backed session handling. Sessions are initialized
or reestablished in the session phase. The global $user object representing the current user
is also initialized here, though for efficiency not all properties are available (they are added by an explicit call to the user_load() function when needed).
Late Page Cache
In the late page cache phase, Drupal loads enough supporting code to determine whether or
not to serve a page from the page cache. This includes merging settings from the database into the array that was created during the initialize configuration phase and loading or parsing module code. If the session indicates that the request was issued by an anonymous user and page caching is enabled, the page is returned from the cache and execution stops.
Language Determination
At the language determination phase, Drupal’s multilingual support is initialized and a decision is made as to which language will be used to serve the current page based on site and user settings. Drupal supports several alternatives for determining language support, such as path prefix and domain-level language negotiation.
Path
At the path phase, code that handles paths and path aliasing is loaded. This phase enables
human-readable URLs to be resolved and handles internal Drupal path caching and
lookups.
Full
This phase completes the bootstrap process by loading a library of common functions, theme
support, and support for callback mapping, file handling, Unicode, PHP image toolkits, form
creation and processing, mail handling, automatically sortable tables, and result set paging. Drupal’s custom error handler is set, and all enabled modules are loaded. Finally, Drupal fires the init hook, so that modules have an opportunity to be notified before official processing of the request begins.
Once Drupal has completed bootstrapping, all components of the framework are available.
It is time to take the browser’s request and hand it off to the PHP function that will
handle it. The mapping between URLs and functions that handle them is accomplished using
a callback registry that takes care of both URL mapping and access control. Modules register
their callbacks using the menu hook (for more details, see Chapter 4).
When Drupal has determined that there exists a callback to which the URL of the browser
request successfully maps and that the user has permission to access that callback, control is handed to the callback function.
Processing a Request
The callback function does whatever work is required to process and accumulate data needed to fulfill the request. For example, if a request for content such as http://example.com/
q=node/3 is received, the URL is mapped to the function node_page_view() in node.module.
Further processing will retrieve the data for that node from the database and put it into a data structure. Then, it’s time for theming.
Theming the Data
Theming involves transforming the data that has been retrieved, manipulated, or created
into HTML (or XML or other output format). Drupal will use the theme the administrator
has selected to give the web page the correct look and feel. The resulting output is then sent to the web browser (or other HTTP client).
Eaton's answer provides a good overview. (I'm new here so I can't mod him up, thus the comment.)
The brutal "aha" moment for me was realizing everything happens through index.php, and then through the waterfall of modules (core first, then by site). To extend core functionality don't rewrite it. Instead copy the module into /sites/all/modules/ or /sites/[yoursite]/modules and extend THAT, or create a new module in those places. Same for themes. Module directories can contain display code as well, in the form of tpl, css etc.
If you're used to stricter MVC type frameworks like Rails, Django etc. all this gets a little confusing. Modules can mix in a lot of display code, and if you're looking at someone else's modules or templates you'll eventually wind up walking backwards through the stack. That's the beauty/pain of working in PHP.
Ironically, "just build an app" might be the worst way to learn this. Drupal does so much out of the box that's simply obscure until you figure out the control flow. There's nothing in a tpl file that tells you where a function with a fun name like l() comes from, for example.
It depends on how deep an understanding you're looking for; if you have a good knowledge of php, I would suggest reading through the code itself, starting with index.php, and then going on to the includes/bootstrap.inc, and then some of the other scripts in that directory.
The key include files:
menu.inc is very important to understanding how the overall system works, as it handles a lot of the implicit mapping of URLs to content.
common.inc has most of the otherwise-mysterious functions that form the basis of the API.
module.inc handles the hook invocations that Eaton mentioned
form.inc deals with form display, submission and processing
theme.inc handles presentation.
There's also some key functionality in the modules/ directory; in particular, modules/node/node.module forms the basis of the node system, which is in general what's used to encapsulate site content.
The code is, in general, very well-commented and clear. The use of Doxygen markup within the commenting means that the code effectively is the canonical documentation.
It also helps to do this using an editor that can quickly jump to the definition of a function. Using vim in combination with ctags works for me; you do have to tell ctags to index .inc, .module, etc. files as php files.
This (for Drupal 6) & this (for Drupal 7) is a pretty good architectural overview of drupal. If you want more detail then I would start writing something most of the documentation is good. Trying to learn it at a high level of detail without something concrete to achieve will be much more difficult that trying something out.
I learned loads by importing the drupal .php code into a NetBeans project.
You can then run the netbeans debugger and watch the different phases of the page come together.
The best books on the subject are "Pro Drupal Development" and "Using Drupal."
"Pro Drupal Development" includes several nice flowcharts and thorough summaries of each of Drupal's APIs (forms, theming, etc.). It's intended to be especially instructive to people making their own modules and themes, but has lots of value to the average PHP-savvy developer who wants to understand Drupal. Besides which, I've created a custom module for every site I've built, just to gain the extra control over things like selectively hiding fields on various forms (which you generally want to do for the sake of simplifying node forms for end-users), so it's good to have this knowledge under your hat.
"Using Drupal" is aimed at the site developer who wants to know how to build the good stuff like galleries, blogs, and social networking sites. It goes through several use-cases and shows how to configure existing modules to do each job. In the process it familiarizes you with the essential add-on modules "Content Construction Kit" (CCK) and "Views," how to make custom blocks and templates, and the ins-and-outs of maintaining a Drupal site. I recommend this book especially for those who want to get up to speed and actually USE Drupal right away. In the process you gain an understanding of the internal organization of Drupal.
New contributor here, 2 years late on the conversation ;-)
Replying to https://stackoverflow.com/a/1070325/1154755
To extend core functionality don't rewrite it. Instead copy the module
into /sites/all/modules/ or /sites/[yoursite]/modules and extend
THAT, or create a new module in those places. Same for themes.
Actually, I never had to copy a core module to update it. Drupal Hooks should be all you need.
For themes, yeah, sometimes it's the only way to go, but often, you can build a subtheme to get the result you need.